On 10 September 2011 09:01, robert mena <robert.mena@xxxxxxxxx> wrote: > Hi, > > I have a project where I have to do a continuous integration, adding > features/making changes on a daily basis. Some changes are one liners > with no functionality just, for example, textual changes or a new > button. Some are actual features or bug fixes. > > So today my developers do their business and publish the changes in a > beta site where the customer or the qa takes a look. The problem is > a standard one. Sometimes features stay already developed (waiting > for review) for a long time and other changes/features get approved > first. > > Since some of those can touch the same files how can I make this a > little bit better (manageable)? > > I am considering doing feature branches. The customer requests to > add feature A I open a bug tracking issue and create a branch 1276 > corresponding to the bug id. > > In my simply view I'd have a master/live branch and every time I need > to create a new branch I do it from here. When the developer is happy > he merges his branch with a beta branch where the Q&A/customer review > is done. > > When this review gets an OK he merges his feature branch with the live > one, redo the tests and publish. > > I'd really appreciate feedback for this specially for the weak points > and known problems of my approach with alternatives :) > 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. Another interesting read is the maintainer's notes from the git project. The branching strategy is a little different then the previous one, and will perhaps give you a better understanding of the practicalities of such a strategy. They normally can be found at https://git.wiki.kernel.org/index.php/MaintNotes but kernel.org is down at the moment so try http://code.google.com/p/git-mirror/source/browse/MaintNotes?name=todo You can also look at http://git-blame.blogspot.com/p/note-from-maintainer.html and in the source repository at Documentation/howto/maintain-git.txt Hope that helps a little. Regards, 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