Moving forward with Git
Scott Hardin <
scott@...>
2011-09-29 14:18:19 GMT
Hi,
After using Git for the past few years, I have stumbled a few times when dealing with my own workflow. A common
situation has been for me to be working concurrently on multiple features and have them slowly depend on
each other to the point that it was sort of "all or nothing" regarding getting a release ready. This often
resulted in messy branches with lots of conflicts. I realized that my own habits were sometimes counter-productive.
Martin and I have been using a new development workflow model for our work in our internal project and have
been very pleased with it so far. A nicely-illustrated description has been published at
http://nvie.com/posts/a-successful-git-branching-model/ and it seems to be well praised by the community.
We would like to adopt this model for OpenXPKI development in the Git repository on SF. In short, the
following git branches will be visible on SF:
master Currently corresponds to SVN should produce stable builds
develop Integration branch for stuff being prepared for next release
The remaining branches described in the model above should only be in your local repository. If, for
example, you are working on a feature and want to share your commits with other developers, you can easily
exchange via github. By doing this, the repository on SF should stay nice and tidy. This also means that a
developer doesn't need write access to SF in order to easily contribute to the project. He or she just
creates a branch with the commits directly off of the HEAD of the develop branch pushes this new branch to
Github and requests another developer to pull the commits and push them to SF.
There is also a nice add-on for Git that supports this workflow model called git-flow. This is available at
https://github.com/nvie/gitflow and there is a spiffy screencast for it from Dave Bock at http://codesherpas.com/screencasts/on_the_path_gitflow.mov.
Martin has asked me to mention an issue regarding the current Git and SVN repositories: he made a mistake
when synchronizing them and we didn't notice the mistake until after the commits were published to SF. The
problem is mostly cosmetic regarding how the branch history appears in Git, but it prevents anyone but
Martin from keeping both Git and SVN automatically synchronized. For his sin, he has been flogged with a
wet WLAN cable.
Until the SVN repository has been retired, Martin has offered to keep the master branch in Git synchronized
with SVN. So there are currently three options for publishing commits:
- Git users: Push your commits to your own repository on github using git and send a pull-request to one of the
developers with write access to Git on SF and familiar with integrating commits (currently Martin or me)
- For master branch only, Git users with write access to Git on SF: Push your commits to both Git and SVN on SF
(you'll want a separate tracking branch for SVN, though).
- SVN users: Push your commits to SVN on SF and have Martin sync to the master branch in git
As a side effect, the history for the Git master branch and SVN will diverge, but only the Git users that try to
track both Git and SVN repositories would notice. If you switch "cold turkey" to Git, you won't have any problems.
For those still not familiar/comfortable with Git, take a look at Github and the book "Version Control with
Git" from O'Reilly. It may seem daunting at first, but Git will grow on you quickly.
With best regards,
Scott
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
RSS Feed