robert mena <robert.mena@xxxxxxxxx> writes: > 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 :) The "Version Control by Example" by Eric Sink, http://www.ericsink.com/vcbe/ contains chapter about workflows, including feature branch workflow. Junio Hamano blog (the old version) included a few articles about using feature-branch workflow too. HTH. -- Jakub Narębski -- 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