I whipped up some diagrams to help explain it. I will generally advise the second option as it keeps things clear (at the cost of some branch juggling), unless the A and B features are very small and can easily cohabitate in a single branch. Having a single AB branch that has further sub-branches for A and B individually (as I suggesting in the previous chapter).Having a single AB branch that contains both features (which is what you would've ended up with if you merged A into B, the way your question suggests).due to a deadline), you're going to have to handle them as if they're one big feature. In cases where you must develop A and B concurrently (e.g. They are not separate features at this point. This means that, as far as the master branch is concerned, you are merging "AB" into the master using a single commit. This means that your shared logic is already in the master when you branch.Īlternatively, you could branch A off of the master, then branch B off of A, and when A and B are done, merge B into A before merging A into the master. When A and B depend on the same (partial) feature, it's usually a lot easier to first develop A, merge it back into master, and only then branch B off from the master. It's usually better to divide the tasks so that the two features can be developed fully independently, as this makes things notably easier to manage. It's viable, but it takes some careful planning and consideration. Keeping it simpleĭoes the above approach seem like a lot of juggling? Yes it does. In this scenario, branch A acts as a "mini master" branch that coordinates the shared logic between its sub (feature) branches. When that is done, you can merge A back into the actual master.When A1 and A2 are done, you merge them back into A, resolving any conflicts.If it turns out that the shared logic needs to be fixed/adjusted, then you commit changes to A, and then merge A back into A1 and A2.Then, you branch off of A into specific feature branches (A1 and A2), and develop them separately.First, you branch off the master (let's call it A), in which you develop the share logic.If you intend to keep the feature branches separate even though they share some logic, there's a better way of doing it. Mini master branch for shared feature logic If you intend to work on the merged AB feature, instead of on A and B separately, then merging A and B is actually okay. To be fair, merging B into A can be acceptable, if and only if these features themselves are now intended to share a single life cycle. Worse still, it's possible that when you merged B, B's feature was incomplete, and now you've merged a half-implemented B feature in master by merging A into the master. When A gets merged into master, that also entails B's features (which are now in A) being merged into master. This means that you no longer have two separate feature branches with individual lifecycles. If you merge feature branch B into feature branch A, then A contains both the features of A and B.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |