Hi Mark, On Fri, Mar 9, 2012 at 9:20 AM, Mark H. Wood <mw...@iupui.edu> wrote: > While reviewing the IRC discussion, I came across something that > seemed to want comment. > [..]
Good post. I was glad to see that the vote to move DSpace code to GitHub was a landslide. Although the tools should not dictate the workflow, they can certainly nudge us in certain directions. So it seems appropriate to step back and consider workflow on the cusp of a VCS migration. I've also been thinking about my preferred workflow with Git in recent weeks (after using it for about a year), and ended up putting together a writeup that may interest you: https://wiki.duraspace.org/display/~cwilper/How+I+Use+Git Regarding the granularity of commits, I completely agree that committing large changesets in one go can be problematic for your fellow developers. But the other extreme (many small changesets) can be equally hard to decipher. Finding the right balance is about considering your audience and the state of your work. The workflow I like to follow is: While the work is in a local branch, commit early and often so I can rollback easily if I do something dumb a couple hours from now. Then, before pushing to origin, do surgery on the commits via "git rebase -i' so they're: a) in good-sized, meaningful chunks for other people to grok. Ideally each chunk adds something useful and is well-tested, especially if you're merging to master. This is the point where you can 'squash' all those 'minor tweak' commits so people reviewing your changes or browsing the repo history down the road don't have to wade through all of them. b) using commit messages that other people can understand. Ideally, mentioning or linking to relevant tracker issues or other documentation, if available. > Committing code to a repo. does three good things: (1) your work is > protected from mishap; (2) you can easily roll back changes that > didn't work out; (3) anyone with access to the repo. can start to > review, use, and build on your work. I see a potential for Git to > facilitate a workflow that denies us early profit from (3), because > you get (1) and (2) by committing locally without sharing. Very true. And I think it would be a mistake to miss out on (3) as well. People should be encouraged to push their more significant work (in a branch, of course) up to origin frequently so others can see what they're up to. Besides getting early feedback, it's a cheap way to protect against a local data loss event. - Chris ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
