Home > OS >  Procedure for developing on top of feature branch when original feature branch is merged with a squa
Procedure for developing on top of feature branch when original feature branch is merged with a squa

Time:03-05

It's not that uncommon when I find myself:

  • needing to work on the next feature
  • before the latest work is integrated to the main branch
  • and new work requires code from the previous branch
  • and the merge into main is a squash.

When this happens, merging is painful.

The scenario:

git checkout develop
git checkout -b feature/A

git commit -am "A1" 
git commit -am "A2" 

git push //   start a pull request

//Before the pull request is finished 

git checkout -b feature/B
git commit -am "B1" 

// Pull request is accepted and merged as a squash

// Other pull requests 

git fetch origin develop
git merge origin/develop
(conflicts)

Now:

  • feature/B has A1, A2, B1
  • and develop has a commit D1 that has the changes from A1 and A2
  • and git cannot know that D1 is A1 A2
  • and it rightly marks places where feature/B touches code changed by feature/A as conflicts.

Ideally I would love to be able to:

  1. not have conflicts where what's coming in from develop to feature/B came from feature/A and
  2. have conflicts if the change came from another branch (or not from commits A1 and A2.

Is that possible?

CodePudding user response:

So You have

feature A:

O---A1---A2

feature B:

O---A1---A2--B1

Then

O---A1---A2--B1 <--featureB
 \
  \--D1 <-- develop

You try to merge,

O---A1---A2---B1--XX Conflict
 \               /
  \--D1---------/

You need to rebase B1 on D1, not a merge

git rebase --onto develop featureA featureB

will do

O---A1---A2
 \         
  \--D1--B1

CodePudding user response:

The simplest solution is don't squash. A squash is not a merge at all. It makes working very difficult (as you've discovered) by causing conflicts and throwing away history, and it brings no benefits. Try to get your organization to change to doing a true merge when accepting a PR.

If you do that, this situation becomes trivially easy, because you can just build feature2 directly off of feature1 and keep working. After feature1 is merged, you just rebase feature2 onto develop. If you're using GitHub, and if you've already submitted feature2 into its own PR, the rebase is done for you automatically when feature1 is merged!

  •  Tags:  
  • git
  • Related