> I'm curious, how are the workflows different? First of all, I'm far from a git expert, so I'm going to keep this pretty wide-open and apologize in advance if I slip any inaccuracies in here.
With that caveat, it's mostly a distinction in permissions and branch utilization. The most apparent distinction will be commit rights. Often times a new supporter of an existing open source project will have read-only permissions on a repository. Getting started with the project will follow the same general technique regardless of commit rights: clone/pull, then add/edit and commit locally. After your changes are complete, however, read-only users will need to submit patches. Patch submission is something that is often lacking in VCS tutorials, particularly for git (I may just be reading the wrong tutorials...). For privately hosted git repositories, often each user has commit rights, meaning that patches are rarely necessary. In this case you make your edits, commit locally, and push to the origin. In addition to the patch/push distinction, each project will tend to have its own specific workflow that *should* denote procedures and nomenclature for branching, tagging, commits, and merging. If they don't, they'll soon regret it. I personally like nvie's ( http://nvie.com/posts/a-successful-git-branching-model/), which may seem like overkill for small projects, but makes growth much more straight-forward. Many organizations have more haphazard git workflows; some prefer it this way, others encounter administrative pains as a result. IMO git has immense strength in its flexibility. This flexibility is a double-edged sword, because it makes it that much harder to guarantee that everyone who uses git knows how to use it the way your organization does. -- Nicholas
_______________________________________________ tos mailing list tos@teachingopensource.org http://teachingopensource.org/mailman/listinfo/tos
