Menu
My git branches look like this:
master-*-*-*-*-*-*-implement_x
\ \-*-further_foo_fixes_that_depend_on_x
\ \-*-*-further_bar_fixes_that_depend_on_x
\
\-implement_x_rebased
It ended this way, because I thought my branch implement_x would be merged upstream as it is, but I was asked to squash it to a single commit, thus implement_x_rebased. However, I already started several branches for further fixing and developing that depend on my work, while waiting for the implement_x to get merged.
Now I'd like to rebase the further work on implement_x_rebased. I thought this was a no-op, since implement_x and implement_x_rebased were in the exactly same state - there would be no merge conflicts, just applying the changes between implement_x and further_foo_fixes_that_depend_on_x etc. on top of implement_x_rebased. However, it seems that git isn't that smart, and it tries to rebase all the way from the base - introducing needless merge conflicts.
I thought that the easy way out is rebase&squash the further fixes on implement_x and then stash them, and apply the stashes to implement_x_rebased, but I'm curious whether there is any proper way to make git realise that implement_x and implement_x_rebased are actually in the same state?
840
The solution is to use git rebase --onto after rebasing the first branch. This will rebase all commits of feature2 that follow the old head of feature1 (i.e. F ) onto the new head of feature1 (i.e. F' ).
From merge to rebaseCreate a new “feature” branch called `my-new-feature` from a base branch, such as `master` or `develop` Do some work and commit the changes to the feature branch. Push the feature branch to the centralized shared repo. Open a new Pull Request for `my-new-feature`
With the rebase command, you can take all the changes that were committed on one branch and replay them on a different branch.
Rebase with the command line. The rebase command takes a target branch to replay the current branch's commits onto. After the rebase finishes, your current branch will have the commit history from the target branch. > git checkout feature1 > git rebase main. First, rewinding head to replay your work on top of it...
In Git, this is called rebasing . With the rebase command, you can take all the changes that were committed on one branch and replay them on a different branch. For this example, you would check out the experiment branch, and then rebase it onto the master branch as follows: $ git checkout experiment $ git rebase master First, ...
The rebase command takes a target branch to replay the current branch's commits onto. After the rebase finishes, your current branch will have the commit history from the target branch.
The following command rebase the current branch from master (or choose any other branch like develop, suppose, the name of remote is origin, which is by default): After git rebase, conflicts may occur. You should resolve them and add your changes by running git add command: git add . Do not run git commit after git add .
This seems to be a task for the --onto option of git rebase.
git rebase --onto implement_x_rebased implement_x further_bar_fixes_that_depend_on_x
You may want to have look at the --onto example in the git rebase manual.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
