Reputation: 618
Given:
Scenario: Code can be added to a new feature branch (feat2) and at the same time it can be kept up to date with feat1 using rebase. The problem will come when feat1 merges in to main. At that point feat2 will need to be rebased with main which will create rebase conflicts.
Question:
Is there a way to create the branch feat2 from un-merged feat1 and main, such that when the merge happens at some point, rebasing with main won't create conflicts? I am thinking that when the feat3 is created the feat1 "squash and merge commit" (the SHA of this commit will be the same as the SHA that will be generated when the actual merge happens) should be applied to main so as to prevent any conflicts as mentioned in the scenario.
Is there a way to keep the feat2 branch updated, with changes from both main and feat1, after it has been created as discussed in 1?
P.S: This question is not concerned about the public nature of the feature branches and how rebasing negatively affects other developers' work.
Upvotes: 1
Views: 301
Reputation: 30156
You can avoid conflicts with a little extra work when calling rebase. Say feat2 is 2 revisions:
git rebase --onto origin/main feat2~2 feat2
Then it doesn't matter that feat1 was squashed when merging. You can also use the old unsquashed tip of feat1 or its last revision below feat2 instead of feat2~2
.
Upvotes: 3