On 20 September 2011 04:51, gitlist <gitlist@xxxxxxxxxxxx> wrote: >> A very interesting read is >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> It may not be perfect for you, however it does discuss some very >> interesting issues, particularly how workflow is just as important as >> the branching model. > > > I came across the nvie post some time and it was very useful, but it doesn't > address handling of feature branches, especially where there is overlap. > > I have a website where people can register. They can also buy things. If > they haven't registered when they come to checkout, the checkout process > includes registration. Users can also create "sponsorship" pages where they > ask friends to sponsor them in a marathon etc. If someone setting up a > sponsorship page is not already registered, it's included in the process. > > So there are three strands (to avoid using the word "branch") - > registration, buying, and sponsorship - which end up affecting the same bits > of code. Registration was done a year ago but recently needed updating; > buying was started some months ago but got held up; sponsorship started > recently, has been completed, and has "overtaken" buying. > > How should I use branches in this scenario? Or if I've got the concept > wrong, how should I change my workflow? > > Thanks > > Roddie Grant The concept of 'feature branches' apply primarily to development.They allow you to build individual features for your system independently of one another, and concurrently. Further, they provide a history of commits that detail the effort that went in to creating that feature. Once the feature is completed however, typically it will get merged with a given release of the system. If further work is to be done on that feature, either a new feature branch is created for the 'improvement', or a similar hot-fix/bug-fix branch is created. When that work is done it gets merged either back on to the same release or into a future release. These feature branches do not host the separate functionality of the system, but instead reveal the history of their development. I have not heard of any intelligent way to use just an SCM to partition and keep separate the different functional aspects of a system; developing modules is generally achieved by writing modular code. If you do have a number of modules you can track each of them individually. Write version-dependencies into the modules, and you can develop on them individually, updating them to depend on the latest version as appropriate. If you are not using well separated modules, and the development of each 'thread' affects the same 'core' files, you need to migrate changes to these core files between threads when appropriate. For example, if you are working on the sponsorship thread, and develop a paypal integration that you now want to include in the buying thread (and can't continue developing it until you do), you should identify the commits that entail that change and merge them into the buying thread branch. Better than retrospectively trying to dig out features and bug-fixes, however, is ensuring a clean separation of thread code and core code. Thankfully, since git has such good merging ability, you can often merge a feature branch which is miles behind the latest release and it will slot in flawlessly. There are many different aspects to this sort of work, but the best thing to do is to keep the future in mind, and try to do things that will make life easier down the track. The great thing about git is that it offers many tools that make things easier later on even when you didn't plan for them - but that is no excuse for poor planning! Hope that helps somewhat, Andrew -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html