Mark, Thanks for beginning this Git Workflow discussion! From all I've read, it seems like one of the first decisions we need to make is which "collaboration model" we'd like to use.
Namely, GitHub suggests there are two main Collaborative models they've seen (described at: http://help.github.com/send-pull-requests/) 1. "Fork & Pull" Model In this model, all developers (including Committers) create a personal public fork of the main repository & do the majority of their development in their own public fork (creating their own branches as they see fit, etc.). Once they feel they have something worth adding to DSpace, they would submit a "Pull Request" to the main repository. That "Pull Request" would need to be approved/accepted by one of the Committers. This model seems to also be described as the "Integration-Manager Workflow" in "Pro Git", chapter 5: http://progit.org/book/ch5-1.html To me, one of the benefits here seem to be that all code changes would receive a review (by whomever reviews the 'pull request'). A "con" may be that it'd always be a two step process to commit to the shared/main repository (first commit to your public repo, then make a pull request). Obviously though, if we went this route, there may also be exceptions (typos, minor changes) which can just be pushed directly to the shared main repository. 2. "Shared Repository" Model In this model, Committers develop directly in the main repository itself, and make heavy use of branches to isolate individual changes. (However, non-Committers would likely still need to perform a "Fork & Pull" as their work would require Committer review.) This model seems to also be described as the "Centralized Workflow" in "Pro Git", chapter 5: http://progit.org/book/ch5-1.html This seems to be the model that Fedora Committers have decided upon in their "Git Best Practices" (https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices). You'll notice they describe how they always create a branch of the master repository for individual changes. Chris can likely comment on this more. This model seems to have the benefit of being "SVN like" -- everyone is working in the same repository (albeit in separate small branches). So, there's only one repository to 'watch'. --- In yesterday's DSpace Developers Meeting, those in attendance seemed to lean slightly towards the "Fork & Pull" model (#1 above). http://irclogs.duraspace.org/index.php?date=2012-03-14 However, it'd be wonderful to hear from others who have tried either of the above GitHub collaboration models. What has worked well? What has been a pain point? Any advice? - Tim ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
