git自创建以来一个分支

Question

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?

Answer 1

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:

1. 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| 

2. 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 

3. 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:

• Git: How to copy a range of commits from one branch to another?

Answer 2

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 .

Answer 3

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.

Answer 4

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.