Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What's the correct way to merge a branch and its dependent branch back to master?
In git I branched feature-A from master. To reduce eventual merge conflicts later, I branched feature-B, which heavily overlaps and depends on A, from feature-A. A build of the feature-B branch shows both sets of changes, as expected. (There have been no further commits on feature-A after this branch.)
What is the best way to land both features back on master? If I just merge feature-B, will it bring along its feature-A baseline, or just the feature-B-specific changes? I think a branch is a set of commits and a commit is a set of deltas, so my concern is that merging feature-B to master would reflect only the work that is unique to feature-B, and without feature-A it would break. But my mental model of git might not be correct.
Alternatively, I could merge feature-A first and then feature-B. That seems safe, but I don't know if it's the best way.
A third approach would be to merge feature-B back into feature-A and then merge feature-A, which came from master originally, back to master. I'm reluctant to do that because that breaks the isolation between feature-A and feature-B; if in the future I need to backport feature-A but not feature-B, I'm not sure how I would do that.
Goals:
- feature-A and feature-B are both on master and arrive in that order (or together)
- it remains possible to backport feature-A without bringing along feature-B in the future (I do not have to support the reverse)
In order to provide more details, that's what my repository looks like:
$ git log --graph --format="%ad %h [%p] %d"
Fri Jul 23 10:42:47 2021 -0400 725d9d1c11 [ca99f826dc] (HEAD -> feature/ct-comparisons-VER-75425, origin/feature/ct-comparisons-VER-75425)
Thu Jul 22 16:27:48 2021 -0400 ca99f826dc [6498847a48]
Thu Jul 22 11:05:17 2021 -0400 6498847a48 [9b2ddff48d] (origin/feature/null-rows-VER-74021-VER-75002, feature/null-rows-VER-74021-VER-75002)
Thu Jul 22 11:02:59 2021 -0400 9b2ddff48d [37329f2ec7]
...
feature/null-rows-VER-74021-VER-75002 is branch A and feature/ct-comparisons-VER-75425 is branch B, and I want to merge both to master.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
I think a branch is a set of commits
Well, technically no, it's not. But first things first.
DAG (Directed Acyclic Graph)
Personally, Git became much more easier to understand after I've read things like this. The "whoa" moment was when it compares Git to a DAG (Directed Acyclic Graph). I'm not going into all the math theory, but just think of a Git repository as a series of nodes pointing to each other.
Each commit is a node in the graph, which points to other nodes: some are the data (folders/files), and some are the parent commits (the commits that "came before").
And a branch is just a pointer to one specific commit.[1]
When you init a Git repository and create the first commit, Git by default creates the master branch (or, for versions after October 2020, the main branch) and makes it point to that commit:
+--------------+
| first commit | <-- master
+--------------+
When you create another commit, Git creates another node for it, makes it point to the previous one and updates the master branch to point to the newer commit:
+--------------+ +---------------+
| first commit | <-- | second commit | <-- master
+--------------+ +---------------+
When you create a new branch, Git simply creates another pointer, with a different name. Let's say my repo contains the two commits above and I do git branch new_branch. The result is:
+--------------+ +---------------+
| first commit | <-- | second commit | <-- master
+--------------+ +---------------+
↑
new_branch
Git created the branch, by simply creating another pointer to the same commit. Now let's suppose I do git checkout new_branch (to actually "switch" to that branch) and create a new commit in it. The repo will be like this:
+--------------+ +---------------+
| first commit | <-- | second commit | <-- master
+--------------+ +---------------+
↑
+---------------+
| new commit in | <-- new_branch
| new_branch |
+---------------+
And what if I create another branch from new_branch? It'll simply create another pointer to the same commit:
+--------------+ +---------------+
| first commit | <-- | second commit | <-- master
+--------------+ +---------------+
↑
+---------------+
| new commit in | <-- new_branch
| new_branch | <-- another_branch
+---------------+
And adding a new commit to another_branch will be like:
+--------------+ +---------------+
| first commit | <-- | second commit | <-- master
+--------------+ +---------------+
↑
+---------------+
| new commit in | <-- new_branch
| new_branch |
+---------------+
↑
+----------------+
| new commit in |
| another_branch | <-- another_branch
+----------------+
Now, if I want to merge all changes from both new_branch and another_branch onto master, I just need to merge another_branch, because it already "contains" the changes from new_branch.
A merge basically finds the common ancestor between the 2 commits and apply all the changes, starting from this common ancestor and ending in the target branch. In the example above, if I switch to master and do a git merge another_branch, it'll also apply the new_branch changes, because their commits are also part of the chain.
Based on the output provided in the comments:
Fri Jul 23 10:42:47 2021 -0400 725d9d1c11 [ca99f826dc] (HEAD -> feature/ct-comparisons-VER-75425, origin/feature/ct-comparisons-VER-75425)
Thu Jul 22 16:27:48 2021 -0400 ca99f826dc [6498847a48]
Thu Jul 22 11:05:17 2021 -0400 6498847a48 [9b2ddff48d] (origin/feature/null-rows-VER-74021-VER-75002, feature/null-rows-VER-74021-VER-75002)
Thu Jul 22 11:02:59 2021 -0400 9b2ddff48d [37329f2ec7]
Just to explain this output, in the first line 725d9d1c11 is the commit hash (actually just part of it), and ca99f826dc is the parent commit hash.
Hence, your case seems to be exactly the one described above. In general terms, it's something like this:
A <- B <- C <-- master
↑
D <- E <-- branch_A
↑
F <- G <-- branch_B
Therefore, if you merge branch_B onto master, you'll end up merging branch_A as well (or, in other words, the commits from branch A will also be included in the merge).
If master has no other commits after C, the merge will be made using a simple fast-forward, and the repo will be like this:
A <- B <- C
↑
D <- E <-- branch_A
↑
F <- G <-- branch_B, master
-
Well, we could say that a branch is the set of all commits reachable from the commit it points to. But technically it's just a pointer to a commit. ↩︎
0 comment threads
I think a branch is a set of commits and a commit is a set of deltas, so my concern is that merging feature-B to master would reflect only the work that is unique to feature-B
Not quite: a branch is a pointer to the state of a repository at a particular point in time (as represented by the commit that created that state).
Merging branch X onto a branch Y proceeds by
- finding the common ancestor in the histories of X and Y
- create a merge commit pointing to the last commits in both branches (or reuse the last commit from X if there has been no other commit in Y, and fast forward is enabled)
- update Y to point to this commit
That is, merging a branch will merge the entire history of that branch (that the target branch doesn't have yet) regardless of which branch the changes were originally committed to.
In your case, this means that merging B will also merge all changes done in A, because they are part of the history of B, and not on master yet. If you were to later merge A, git would realize that all commits are already on master, and merge nothing.
This can be a blessing or a curse. A blessing, because it ensures that prior work is automatically merged; a curse, because that work may not be ready for release yet.
feature-A and feature-B are both on master and arrive in that order (or together)
To achieve this, you can merge A and then merge B, or just merge B. Either way, git will apply the commits of both branches in the proper order.
The only difference is the commit message of the merge commit (if one is created), which mentions the name of the branch being merged. If it is important to note for posterity which work was done in branch A, it may be preferable to merge A before merging B (without fast forward), so separate merge commits are created, with the merge commit for A separating the commits done A from those done in B even if the branches themselves should later be deleted.
it remains possible to backport feature-A without bringing along feature-B in the future
Don't merge B onto A, then (even if you did, you could still backport by resetting the A branch to the commit before the merge, but its easier to not merge B into A to begin with).
0 comment threads
1 comment thread