Answers.Body: <p>While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like <a href="https://trello.com/" rel="nofollow noreferrer">Trello</a> which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.</p>
  
  <p>An issue with managing the actual project files within source control is around the format of them - some file types work better than others when it comes to source control, and some formats of those types work better than others as well.</p>
  
  <p>Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy. If the tool you choose stores projects in binary files, Git is probably not the best option.</p>
  
  <p>I would strongly recommend that you consider a <strong>Centralised Version Control System</strong> such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.</p>
  
  <p>Sadly for you, most developers have moved to Git based source control, as it's very good at dealing with code files, and generally much quicker when working locally, allows for "offline" working, etc. and solves the problem of people working on different parts of the same file or project simultaneously, so most of the free options (GitHub, GitLab, etc.) focus on that. You might be able to use the free options within <a href="https://dev.azure.com/" rel="nofollow noreferrer">Azure DevOps</a> to create a TFS based project, or find another SVN host for your project. Most of these also offer "Work Item" tracking for task planning and management.</p>
  
  <p>In terms of the current software for building your MoC, the likely contenders are:</p>
  
  <ol>
  <li><strong>Stud.io</strong> - <a href="https://rebrickable.com/help/guide-to-stud-io/" rel="nofollow noreferrer">uses a binary (.zip) format</a>. This doesn't play well in Git. Furthermore it's a password protected archive, so you can't easily extract the underlying .ldr files.</li>
  <li><strong>LDraw</strong> - uses a <a href="https://www.ldraw.org/article/218.html" rel="nofollow noreferrer">text based format</a>. Potentially a better fit for Git, however the format itself would be very easy to mess up in merges if two people work on the same model files at the same time.</li>
  <li><strong>LEGO Digital Designer</strong> - uses a <a href="https://bricks.stackexchange.com/a/4391/56">text (XML) based format</a>. Potentially a good fit for Git. While XML can get messed up in merges, it's usually easier to see in merge tools where the changes should belong, and so easier to correct/adjust if two people work on the same model file. However, this is likely end-of-life now, especially with the <a href="https://www.bricklink.com/message.asp?ID=1167349" rel="nofollow noreferrer">announced purchase of BrickLink by The LEGO Group</a>.  
  
  <blockquote>
    <p><strong>What about Studio and LEGO Digital Designer – what will happen with the
    two digital building experiences since they’re quite similar?</strong><br>
    The LEGO Group is planning to support and evolve Studio and will review opportunities
    for both services following the closing of the deal.</p>
  </blockquote></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-10T21:22:54.427Z
Answers.Text: I would say that regardless of the file format, text merges do not make sense for a Lego model and even a human readable format should be treated as a black box.  Sure a merge might handle a color change correctly, but even if one piece is swapped out I bet any idea of a "merge" would be impossible.
Answers.UserDisplayName: JPhi1618
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-11T10:25:07.197Z
Answers.Text: @JPhi1618 agreed - it would be unpleasant to say the least, which further reinforces my recommendation for a centralised system.
Answers.UserDisplayName: Zhaph - Ben Duguid
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-10T12:51:26.810Z
Answers.LastActivityDate: 2019-12-11T10:27:17.240Z
Answers.LastEditDate: 2019-12-11T10:27:17.240Z
Answers.UserDisplayName: Zhaph - Ben Duguid
Answers.Body: <p>I'll address some points from <a href="https://bricks.stackexchange.com/a/12898/13374">Zhaph - Ben Duguid's answer</a>:</p>
  
  <blockquote>
    <p>While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like Trello which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.</p>
  </blockquote>
  
  <p>Github actually has this as well in the form of <a href="https://help.github.com/en/github/managing-your-work-on-github/about-project-boards" rel="nofollow noreferrer">Project Boards</a>. They integrate with the rest of the GitHub ecosystem, so you can reference issues, pull requests, assign milestones and labels, etc.</p>
  
  <p><a href="https://i.sstatic.net/oMfah.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/oMfah.png" alt="project-board"></a></p>
  
  <blockquote>
    <p>Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy.</p>
  </blockquote>
  
  <p>This was a painful point for a long while. However, git now supports <a href="https://git-lfs.github.com/" rel="nofollow noreferrer">Large File Storage</a>. It stores references to the files, so checking changes between commits would show that a file was updated and not waste space trying to calculate diffs. I have used this for images and other binary files and it works well, though it does add a small extra step to upload or download the files when pushing or pulling.</p>
  
  <p>You could easily use LFS for the various binary files the programs use for creating.</p>
  
  <p><strong>Edit: File locking</strong> </p>
  
  <blockquote>
    <p>I would strongly recommend that you consider a Centralised Version Control System such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.</p>
  </blockquote>
  
  <p>Git LFS also has <a href="https://github.com/git-lfs/git-lfs/wiki/File-Locking" rel="nofollow noreferrer">file locking</a> (Since 2.0, March 2017). I do agree that it is more complicated than SVN. I do not know if the web platforms or desktop apps (<a href="https://desktop.github.com/" rel="nofollow noreferrer">GitHub Desktop</a>) show locks, but I do know that you can lock and manage locks via the command line:</p>
  
  
  
  <pre><code>git lfs lock file.ext    # lock file
  git lfs locks            # show locked files
  git lfs unlock file.ext  # unlock file
  </code></pre>
  
  <p>You can enable locking for an extension across a repo by adding <code>*.[extension] lockable</code> to your <code>.gitattributes</code> file, and if a user has locked a file and disappeared someone with the proper permissions can unlock the file with <code>git lfs unlock file.ext --force</code>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-11T10:24:11.053Z
Answers.Text: Good point on the GitHub's boards and integrations, however that might still be overkill for the project, and more confusing, especially if most of the contributors aren't used to all that ceremony. I also agree that LFS is a possible option, but that's more to work around the file size limits (100MB) and performance impact of working with those files. You'll still be unable to review any changes to binary files in any meaningful way. Hence my suggestion of a centralised system that allows users to lock the file centrally to say "I'm working on this" and (generally) avoid these issues.
Answers.UserDisplayName: Zhaph - Ben Duguid
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-11T15:24:38.747Z
Answers.Text: @Zhaph-BenDuguid I'm not sure how GitHub's projects would be confusing, since you can use it exactly like Trello if you want. I do agree that locking is the better method for editing binary files, git LFS even supports [locking files](https://github.com/git-lfs/git-lfs/wiki/File-Locking)!
Answers.UserDisplayName: GammaGames
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-11T17:55:17.857Z
Answers.Text: I meant that throwing in references to pull requests and milestones might be confusing ;). Good to know about locking in LFS - feel free to update your answer with the steps required to enable that for `.io` files across all instances of the repo and the on going use, it's more complicated than SVN or TFS if you've got to fetch and then lock, and remember to unlock after a push... As is the nature of open-source, who knows if the 2.5 year old documentation is out of date, or whether LFS 2.9.1 has a less "early release" version of locking?
Answers.UserDisplayName: Zhaph - Ben Duguid
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-11T18:21:10.650Z
Answers.Text: @Zhaph-BenDuguid Good point about updating my answer, done! It does seem more complicated than SVN and I haven't been able to find if it is supported in the various web interfaces, but it seems like a handful of the most popular git platforms do support the feature. I also haven't found anything else about updates to the locking, so it might have been "good enough" in 2017 and hasn't needed any more attention since then.
Answers.UserDisplayName: GammaGames
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-10T20:08:32.633Z
Answers.LastActivityDate: 2019-12-11T18:24:27.997Z
Answers.LastEditDate: 2019-12-11T18:24:27.997Z
Answers.UserDisplayName: GammaGames
Body: <p>I have the idea to host, plan and maintain a LEGO project (building a MOC in several steps with different functionalities) like a software in GitHub. The project should have forks, pull requests and version tracking.</p>
  
  <ol>
  <li>Is there a possibility to do this with existing software? LDD, Leocad, Stud.io in combination with GitHub or similar?</li>
  <li>How to realize a crowd/community project that builds on a LEGO model? What functionality might be needed?</li>
  </ol>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-10T18:45:48.443Z
Comments.Text: https://github.com/chicks-net/lego-business-card-holder is my example of what you're talking about.  I wasn't expecting much collaboration, but I like github for publishing things and showing the history of the project.
Comments.UserDisplayName: chicks
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-10T20:23:51.830Z
Comments.Text: Can you export it to a data plan like JSON or XML? Those are versionable, with a bit of work.
Comments.UserDisplayName: Mast
Tags: <technic><lego-group><afol>
Title: Is there a way to plan and organize your LEGO project like a GitHub hosted software?
UserDisplayName: kamton
ThreadText: # Is there a way to plan and organize your LEGO project like a GitHub hosted software?
  
  (Asked by: username_0 on 2019-12-10)
  
  I have the idea to host, plan and maintain a LEGO project (building a MOC in several steps with different functionalities) like a software in GitHub. The project should have forks, pull requests and version tracking.
  
  1. Is there a possibility to do this with existing software? LDD, Leocad, Stud.io in combination with GitHub or similar?
  2. How to realize a crowd/community project that builds on a LEGO model? What functionality might be needed?
  
  **Tags:** technic, lego-group, afol
  
  > **Comments:**
  > **username_1**: https://github.com/username_1-net/lego-business-card-holder is my example of what you're talking about.  I wasn't expecting much collaboration, but I like github for publishing things and showing the history of the project.  
  > **username_2**: Can you export it to a data plan like JSON or XML? Those are versionable, with a bit of work.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2019-12-10. Score: 9
  
  While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like [Trello](https://trello.com/) which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.
  
  An issue with managing the actual project files within source control is around the format of them - some file types work better than others when it comes to source control, and some formats of those types work better than others as well.
  
  Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy. If the tool you choose stores projects in binary files, Git is probably not the best option.
  
  I would strongly recommend that you consider a **Centralised Version Control System** such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.
  
  Sadly for you, most developers have moved to Git based source control, as it's very good at dealing with code files, and generally much quicker when working locally, allows for "offline" working, etc. and solves the problem of people working on different parts of the same file or project simultaneously, so most of the free options (GitHub, GitLab, etc.) focus on that. You might be able to use the free options within [Azure DevOps](https://dev.azure.com/) to create a TFS based project, or find another SVN host for your project. Most of these also offer "Work Item" tracking for task planning and management.
  
  In terms of the current software for building your MoC, the likely contenders are:
  
  1. **Stud.io** - [uses a binary (.zip) format](https://rebrickable.com/help/guide-to-stud-io/). This doesn't play well in Git. Furthermore it's a password protected archive, so you can't easily extract the underlying .ldr files.
  2. **LDraw** - uses a [text based format](https://www.ldraw.org/article/218.html). Potentially a better fit for Git, however the format itself would be very easy to mess up in merges if two people work on the same model files at the same time.
  3. **LEGO Digital Designer** - uses a [text (XML) based format](https://bricks.stackexchange.com/a/4391/56). Potentially a good fit for Git. While XML can get messed up in merges, it's usually easier to see in merge tools where the changes should belong, and so easier to correct/adjust if two people work on the same model file. However, this is likely end-of-life now, especially with the [announced purchase of BrickLink by The LEGO Group](https://www.bricklink.com/message.asp?ID=1167349).
     > **What about Studio and LEGO Digital Designer – what will happen with the
     > two digital building experiences since they’re quite similar?**  
     > The LEGO Group is planning to support and evolve Studio and will review opportunities
     > for both services following the closing of the deal.
  
  > **Comments:**
  > **username_4**: I would say that regardless of the file format, text merges do not make sense for a Lego model and even a human readable format should be treated as a black box.  Sure a merge might handle a color change correctly, but even if one piece is swapped out I bet any idea of a "merge" would be impossible.  
  > **username_3**: @username_4 agreed - it would be unpleasant to say the least, which further reinforces my recommendation for a centralised system.  
  
  ---
  
  ### Answer by username_5 on 2019-12-10. Score: 7
  
  I'll address some points from [username_3's answer](https://bricks.stackexchange.com/a/12898/13374):
  
  > While you could indeed manage the project with a tool like GitHub (using the Issues feature), you might be better off initially managing the tasks through a tool like Trello which allows you to create tasks and move them through various status (i.e. Planned, In Progress, Review, Complete) in a fairly simple, intuitive user interface.
  
  Github actually has this as well in the form of [Project Boards](https://help.github.com/en/github/managing-your-work-on-github/about-project-boards). They integrate with the rest of the GitHub ecosystem, so you can reference issues, pull requests, assign milestones and labels, etc.
  
  [![project-board](https://i.sstatic.net/oMfah.png)](https://i.sstatic.net/oMfah.png)
  
  > Git is a "Distributed Version Control System", which means that anyone can work on any file in the repository on their local machine - this is usually fine when working with text based files, but is not so good when you have binary files, because understanding the differences between two versions is often not easy.
  
  This was a painful point for a long while. However, git now supports [Large File Storage](https://git-lfs.github.com/). It stores references to the files, so checking changes between commits would show that a file was updated and not waste space trying to calculate diffs. I have used this for images and other binary files and it works well, though it does add a small extra step to upload or download the files when pushing or pulling.
  
  You could easily use LFS for the various binary files the programs use for creating.
  
  **Edit: File locking**
  
  > I would strongly recommend that you consider a Centralised Version Control System such as Subversion (SVN) or Team Foundation Version Control (TFVC or TFS) as this allows your collaborators to "checkout" or "lock" a specific file to say they are working on it, and then when they've updated it, "check-in" their changes - this will (hopefully) get around the main pain points of trying to merge changes in these files, albeit with the caveat that you might still have people check-out a file and then "go dark" and forget to check it back in for a long time.
  
  Git LFS also has [file locking](https://github.com/git-lfs/git-lfs/wiki/File-Locking) (Since 2.0, March 2017). I do agree that it is more complicated than SVN. I do not know if the web platforms or desktop apps ([GitHub Desktop](https://desktop.github.com/)) show locks, but I do know that you can lock and manage locks via the command line:
  
  ```
  git lfs lock file.ext    # lock file
  git lfs locks            # show locked files
  git lfs unlock file.ext  # unlock file
  
  ```
  
  You can enable locking for an extension across a repo by adding `*.[extension] lockable` to your `.gitattributes` file, and if a user has locked a file and disappeared someone with the proper permissions can unlock the file with `git lfs unlock file.ext --force`.
  
  > **Comments:**
  > **username_3**: Good point on the GitHub's boards and integrations, however that might still be overkill for the project, and more confusing, especially if most of the contributors aren't used to all that ceremony. I also agree that LFS is a possible option, but that's more to work around the file size limits (100MB) and performance impact of working with those files. You'll still be unable to review any changes to binary files in any meaningful way. Hence my suggestion of a centralised system that allows users to lock the file centrally to say "I'm working on this" and (generally) avoid these issues.  
  > **username_5**: @username_3-BenDuguid I'm not sure how GitHub's projects would be confusing, since you can use it exactly like Trello if you want. I do agree that locking is the better method for editing binary files, git LFS even supports [locking files](https://github.com/git-lfs/git-lfs/wiki/File-Locking)!  
  > **username_3**: I meant that throwing in references to pull requests and milestones might be confusing ;). Good to know about locking in LFS - feel free to update your answer with the steps required to enable that for `.io` files across all instances of the repo and the on going use, it's more complicated than SVN or TFS if you've got to fetch and then lock, and remember to unlock after a push... As is the nature of open-source, who knows if the 2.5 year old documentation is out of date, or whether LFS 2.9.1 has a less "early release" version of locking?  
  > **username_5**: @username_3-BenDuguid Good point about updating my answer, done! It does seem more complicated than SVN and I haven't been able to find if it is supported in the various web interfaces, but it seems like a handful of the most popular git platforms do support the feature. I also haven't found anything else about updates to the locking, so it might have been "good enough" in 2017 and hasn't needed any more attention since then.  
  
  ---
  
  