Consider the following practice:
main
and creates as many commits as needed in a feature branchmain
branch (for instance, think of a GitHub's "Squash and merge" button)And now this is a use case that interests me:
feature1
branchfeature2
branch starting from the last commit of the feature1
branch (see the C
commit in the image below)feature1
into main
(see the commit G
)G
into the feature2
branchfeature2
branchIn other words, the merge of G
into the feature2
branch in step 4 looks like this:
user@host:~/repo (main)$ git checkout feature2
user@host:~/repo (feature2)$ git merge main # merge G into feature2
Often, this merge (see the commit H
) results in a number of merge conflicts.
How to completely eliminate these conflicts?
The easiest solution I can think of is the following (see the image below):
user@host:~/repo (main)$ git checkout feature1
user@host:~/repo (feature1)$ git merge main # merge G into feature1; essentially, an empty commit
user@host:~/repo (feature1)$ git checkout feature2
user@host:~/repo (feature2)$ git merge feature1 # merge G' into feature2
To put it another way, instead of merging G
into feature2
directly, we first merge G
into feature1
and then merge feature1
into feature2
.
Is there a simpler approach?
I would rebase feature2
onto main
just after that feature1
has been squashed and merged.
Something like:
git checkout feature2
git rebase --onto main C feature2
This will rebase commits from C
(exclusive) to feature2
(inclusive) on top of main
.
So instead of merging main into feature2(red), feature2 moves to be on top of main(green).
However I'm not sure it qualifies as simpler. And one drawback is that you will get commits of main
in the resulting branch (but that's what you want ultimately I guess).
Personal opinion: do not use squash in the first place if the branch is used by other people as reference.