3 ms·

The ease of branching has people treat branches as if they were cookies. You cannot possibly have too many of them. But, actually, branches make refactoring mor

by cjfd 6y ago

The ease of branching has people treat branches as if they were cookies. You cannot possibly have too many of them. But, actually, branches make refactoring more difficult. What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. The KISS principle that is the corner stone of all software development would dictate that you should have the smallest number of branches possible so everyone gets the latest code as soon as possible and conflicts get minimized. For unfinished features one can have feature flags. While there are cases where one needs a feature branch I think it is best to only make feature branches if they are necessary and most development does not need to be on a feature branch. The git flow also features a development branch besides the master branch. This also seems an unneeded complication for most projects. If you have specialized testers you probably do need release branches for every release that you make but then again if you don't have specialized testers you probably don't. Here is a good talk about the harmful nature of feature branches. https://www.youtube.com/watch?v=h7LeD7VevyI https://www.youtube.com/watch?v=h7LeD7VevyI

berbc 6y ago
As said in one of the YouTube comments for the video you linked here, it's not so much feature branches that are the problem, but long-lived feature branches. If you want to add a complex feature to a project, you could do it via several branches, one after the other. For instance, the first branch could introduce a feature flag and the second branch implement part of the new feature, and so on.
- cjfd 6y ago
  This is more of a semantic quibble than anything else. Yes, long-lived branches are not just a problem but absolutely terrible. I have seen one that lived for some 4 years or so. They are a problem to the extend that they live long. The shorter they live the less of a problem they are. So, take this to its conclusion and conclude that the best feature branch is one that is only one small commit long. And now the feature branch is completely redundant....
linuxftw 6y ago
> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. If you're working in a large codebase and the function in question is part of your API, don't mutate it, add another function and deprecate the older function. In any case, either developer A or developer B has to pay the cost of mutating the function at some point.
- cjfd 6y ago
  The point is that the problem is the smallest if the times between the point where A and Bs changes get into the mainline is the smallest. If A adds his parameter on Monday and B adds that same day three new calls and on Tuesday both merge their changes three calls need to be adjusted. If they merge on Friday and B has added three more calls on every day before Friday they have to adjust 12 function calls. Also, when B does not agree that the addition of a parameter is a good idea they can discuss this on Tuesday but otherwise they may wait doing this until Friday. It is also good to get this discussion out of the way as soon as possible. What if they decide that indeed the parameter that B added was good as such but actually needs to be of a different type? In the meantime B also has perhaps also added 12 calls to the function. These 12 calls now also have to be adjusted alongside with the 12 calls in the code of A. The general idea is that one wants to diverge from mainline for the shortest amount of time possible. I think the optimal amount of time for diverging from the main line is one day. If it becomes shorter the problem becomes that one would also need code reviews more then once a day and that becomes a bit burdensome too but code review every day generally sounds like a good idea. Preferably one should also pick a fixed time of the day for the code review. At my previous job I would do this and produce perhaps 10 small commits a day that would all get into the main line the next morning. If everybody does that one minimizes the size of possible conflicts.

by cjfd 6y ago

berbc 6y ago

As said in one of the YouTube comments for the video you linked here, it's not so much feature branches that are the problem, but long-lived feature branches. If you want to add a complex feature to a project, you could do it via several branches, one after the other. For instance, the first branch could introduce a feature flag and the second branch implement part of the new feature, and so on.

cjfd 6y ago
This is more of a semantic quibble than anything else. Yes, long-lived branches are not just a problem but absolutely terrible. I have seen one that lived for some 4 years or so. They are a problem to the extend that they live long. The shorter they live the less of a problem they are. So, take this to its conclusion and conclude that the best feature branch is one that is only one small commit long. And now the feature branch is completely redundant....

linuxftw 6y ago

> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. If you're working in a large codebase and the function in question is part of your API, don't mutate it, add another function and deprecate the older function. In any case, either developer A or developer B has to pay the cost of mutating the function at some point.

cjfd 6y ago
The point is that the problem is the smallest if the times between the point where A and Bs changes get into the mainline is the smallest. If A adds his parameter on Monday and B adds that same day three new calls and on Tuesday both merge their changes three calls need to be adjusted. If they merge on Friday and B has added three more calls on every day before Friday they have to adjust 12 function calls. Also, when B does not agree that the addition of a parameter is a good idea they can discuss this on Tuesday but otherwise they may wait doing this until Friday. It is also good to get this discussion out of the way as soon as possible. What if they decide that indeed the parameter that B added was good as such but actually needs to be of a different type? In the meantime B also has perhaps also added 12 calls to the function. These 12 calls now also have to be adjusted alongside with the 12 calls in the code of A. The general idea is that one wants to diverge from mainline for the shortest amount of time possible. I think the optimal amount of time for diverging from the main line is one day. If it becomes shorter the problem becomes that one would also need code reviews more then once a day and that becomes a bit burdensome too but code review every day generally sounds like a good idea. Preferably one should also pick a fixed time of the day for the code review. At my previous job I would do this and produce perhaps 10 small commits a day that would all get into the main line the next morning. If everybody does that one minimizes the size of possible conflicts.