At the moment when rebasing a branch (eg a feature branch before merging into master ) I have to manually look up when the branch was created to tell git rebase
the start-point for rebase
.
I have the strong feeling that this can be automated — is there a way to tell git rebase
to start when the branch was created?
Assuming you are working on the branch feature/foo
which is based on the master
branch.
F--J--K--|feature/baz|
/
A--B--D--G--|master|
\
C--E--H--|feature/foo|HEAD|
In order to rebase
the work onto master
there are different options:
As explained by remram you can explicitly name the target commit using the --onto
:
// 1.1. Will move the flag `feature/foo` git rebase --onto master B feature/foo // 1.2. Will not move the flag `feature/foo` git rebase --onto master BH // 1.3. If the HEAD is at H git rebase --onto master B
Since the --onto
lets you define the target commit it is useful if you want to rebase feature/foo
onto feature/baz
which do not share a common branch base.
// 1.4. Will rebase `feature/foo` onto `feature/baz` git rebase --onto feature/baz B feature/foo /--|feature/baz| / F--J--K--C'--E'--H'--|feature/foo|HEAD| / A--B--D--G--|master|
As explained by Stefan Fleiter you do not have to name the ancestor if feature/foo
is based on master
:
// 2.1. Explicitly naming feature/foo as the branch to be rebased onto master git rebase master feature/foo // 2.2. Assuming that feature/foo is currently checked out aka. HEAD git checkout feature/foo git rebase master
If you do not feel comfortable with the rebase
process since your former branch feature/foo
"disappears" cherry-pick
might be a feel-good alternative for you. The command allows to specify a range of commits and behaves very similar to rebase --onto
. The difference is that the branch you are cherry-picking from will remain untouched.
// 3.1.1. Start by creating a new branch where master is git checkout master git checkout -b feature/foo-cherried F--J--K--|feature/baz| / A--B--D--G \\ \\ \\ \\-|master|feature/foo-cherried|HEAD| \\ C--E--H--|feature/foo| // 3.1.2. Pick a range starting at the common branch base git cherry-pick B..H F--J--K--|feature/baz| / A--B--D--G--C'--E'--H'--|feature/foo-cherried|HEAD| \\ \\ \\ \\-|master| \\ C--E--H--|feature/foo| // 3.1.3. Later on if everything worked fine you can // delete the unmerged branch feature/foo git branch -D feature/foo F--J--K--|feature/baz| / A--B--D--G--C'--E'--H'--|feature/foo-cherried|HEAD| \\ \\-|master|
For more information about git rebase --onto
I recommend a blog post here:
The full rebase syntax is git rebase --onto target starting-point mybranch
. If mybranch
is omitted, the current one will be used.
In most cases, you can just do git rebase target
. In this case, the last common ancestor of the current branch ( mybranch
) and target
will be used (see merge-base ). So, if you're rebasing a feature branch on the branch it was based on, this last form should work.
See also the page on rebase from the Git book .
When rebasing a feature branch with git you do not have to know the common ancestor. Simply switch to your feature branch
git checkout my-feature-branch
rebase to master or some other branch you like
git rebase master
switch back to master
git checkout master
and (fast-forward) merge the feature branch to set HEAD in the master branch to the latest rebased commit.
git merge my-feature-branch
For more details please have a look at the detailed explanation in the Pro Git book. I hope this answers your question.
What worked very well for me was to just git rebase master -i
.
This assumes you're 1) standing on the branch you want to rebase and 2) rebase onto master. It will also allow me to edit each committ if neccessary.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.