Version control concepts - a branch for each function, a tag for checking in

Question

I read this post about the branch for each function, "and this one too , and I wondered how many people use this concept? I am all for continuous integration and marking each check. And at the end of the iteration I create a special tag set to identify the sprint result. I never needed this, creating a special branch to develop each function.

Question: Does anyone give their own code to develop each function in their code base? If so, why are you doing this and what are the benefits that you have seen in this process? Aren't the non-process-oriented developers in your team buying this approach?

Answer 1

I have not heard of this. It seems like overuse of the branch. I think it depends on what we mean by the word "feature." Is this a precedent? User story? Whole iteration?

Branches suggest parallel development. If you do not develop in parallel, why the industry?

Some good SCM links from our host, Jeff Atwood:

• Eric Sink
• Branching and Merging Primer

And, of course, the red book SVN bean:

http://svnbook.red-bean.com/

I also like that "Pragmatic Version Control" should talk about branching and tags.

Answer 2

For me, branching by attribute makes sense only when you have a sufficiently large project that you can reasonably talk about the “functional team” of X as an independent unit.

In addition, there are certain size criteria (admittedly, fuzzy). If you have 10 developers, you have only one team of functions, as far as I know - it doesn’t matter if two of them are “guys with widgets” or “database guys”. You may need> 1 development branch if someone does a lot of refactoring by making changes to the API, changing the expected behavior, so many BVTs won't work, etc. But this is not a function branch.

If you have 100 developers, you might need function branches. It depends on how closely your functions are related and how disciplined your SCM process as a whole is, especially with regard to build quality. Even if you do not have function branches, you will surely have some sort of branch hierarchy.

If you work with Windows, layers and layers of function branches are a godsend. If the shell command cannot be productive because the kernel command introduced an error, this is a big problem.

Of course, there is a balancing act. Some large organizations take too much branching of features. When it starts to take months before the code blessed by functional team X turns it into team Y, the pain of merging + integration testing outweighs the stability of the code that you tried to get in the first place. (hence the phrase "your tree depth from MAIN is inversely proportional to your sanity"). And in each case, the tree for version N should narrow down as its release approaches, eventually folding to the point where only checks directly in this connecting line will be and each branch of the function effectively targets N + 1.

Answer 3

I would even go further and implement "branch for task" , where you use a branch for each problem in your problem tracking system (you know bugzilla, JIRA, etc.).

It may sound a little "extreme", but it is very easy to follow if you use SCM-capable branches like Git, Mercurial or Plastic (and I'm biased towards plastic, of course: P)

Answer 4

Function separators work well with Scrum when occasionally the backlog element is not ready for release at the end of the sprint. You hope to avoid this situation, but it will happen from time to time. When this happens, you simply combine the remaining elements that are not filled, and do not combine those that are not. Unfinished units can be transferred to the next sprint, if necessary, or returned to the backlog and will work later. In any case, you still have a branch, so you do not need to throw away the code that you have already completed.