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 _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
