3 ms·

But how does ongoing development work? You have changes, now you need to merge them into every branch. How do you know which ones are going to break the build,

But how does ongoing development work? You have changes, now you need to merge them into every branch. How do you know which ones are going to break the build, how do you know which ones just aren't going to merge due to divergence? I have a horror of this due to having experienced a strategy where the team took a new (subversion) branch every time they started a new project (i.e. were building a new device in the same family). You had multiple branches with divergent development but lots of common functionality. If you wanted to fix a bug common to all the systems you had to fix it 4 times. I absolutely believe that there are better ways of implementing that approach than they used, but I also am convinced through experience that you should have one single line of development and everything else is just 'views' on that (e.g. point release branch is just a view master that is frozen, plus some filtered recent history). To take your Linux kernel example - the various forks (I'm working with the Xilinx Petalinux Kernel now) don't really fit into the normal model. They're a combination of a release branch and a feature branch - they take the Linux Kernel at a certain time, then add some patches on top. Those patches then usually get submitted (indirectly) back to Linus so that they join the master path of development. That means that other people benefit from them, and refactor them when appropriate.

Silhouette 6y ago
But how does ongoing development work? You have changes, now you need to merge them into every branch. Yes. That is exactly what you do. How do you know which ones are going to break the build, how do you know which ones just aren't going to merge due to divergence? You use tools like unit testing and continuous integration running on all of your key branches, just like you would on a single-master project. I have a horror of this due to having experienced a strategy where the team took a new (subversion) branch every time they started a new project That brings back painful memories. I think it's fair to say that in the area of branch management, modern VCSes are much easier to use than Subversion. Even if you're not using them as physically distributed, the same tools for readily transferring work across branches and tracking what has gone where are also useful in other scenarios such as the one we're talking about here. I also am convinced through experience that you should have one single line of development I guess this is just a case of everyone's experience being different. My experience has been that projects that try to keep everything on a single branch when the reality is that you will be making several significantly different types of build over the long term can become prohibitively expensive to manage. You don't necessarily have to use a multiple branch strategy to deal with that, or that strategy alone; I mentioned a couple of other useful options earlier on. But trying to use a single master and then make multiple types of build regularly using just informal processes or ad-hoc changes on release branches is a recipe for human error IME. Something has to systematically track and control the divergence or things get really messy. They're a combination of a release branch and a feature branch - they take the Linux Kernel at a certain time, then add some patches on top. Those patches then usually get submitted (indirectly) back to Linus so that they join the master path of development. This is exactly what typically happens in the situation I was describing as well. You would presumably have some root with the common code, and then you maintain your per-target branches off that. Most development work still gets pushed to the common root as usual, and then all targets benefit unless they're specifically overriding the default code in that area (which is handled at the point of merging into the target-specific branch). Any changes first made on target-specific branches can also be passed up and then back down onto other targets if it turns out that they are more widely useful, or transferred directly to one or more of the other target-specific branches but without applying the change to the common root. However, typically you would do anything like this via some sort of cherry-picking process; you would never normally transfer all of your changes back up by merging a target-specific branch back into the shared root.

Silhouette 6y ago

But how does ongoing development work? You have changes, now you need to merge them into every branch. Yes. That is exactly what you do. How do you know which ones are going to break the build, how do you know which ones just aren't going to merge due to divergence? You use tools like unit testing and continuous integration running on all of your key branches, just like you would on a single-master project. I have a horror of this due to having experienced a strategy where the team took a new (subversion) branch every time they started a new project That brings back painful memories. I think it's fair to say that in the area of branch management, modern VCSes are much easier to use than Subversion. Even if you're not using them as physically distributed, the same tools for readily transferring work across branches and tracking what has gone where are also useful in other scenarios such as the one we're talking about here. I also am convinced through experience that you should have one single line of development I guess this is just a case of everyone's experience being different. My experience has been that projects that try to keep everything on a single branch when the reality is that you will be making several significantly different types of build over the long term can become prohibitively expensive to manage. You don't necessarily have to use a multiple branch strategy to deal with that, or that strategy alone; I mentioned a couple of other useful options earlier on. But trying to use a single master and then make multiple types of build regularly using just informal processes or ad-hoc changes on release branches is a recipe for human error IME. Something has to systematically track and control the divergence or things get really messy. They're a combination of a release branch and a feature branch - they take the Linux Kernel at a certain time, then add some patches on top. Those patches then usually get submitted (indirectly) back to Linus so that they join the master path of development. This is exactly what typically happens in the situation I was describing as well. You would presumably have some root with the common code, and then you maintain your per-target branches off that. Most development work still gets pushed to the common root as usual, and then all targets benefit unless they're specifically overriding the default code in that area (which is handled at the point of merging into the target-specific branch). Any changes first made on target-specific branches can also be passed up and then back down onto other targets if it turns out that they are more widely useful, or transferred directly to one or more of the other target-specific branches but without applying the change to the common root. However, typically you would do anything like this via some sort of cherry-picking process; you would never normally transfer all of your changes back up by merging a target-specific branch back into the shared root.