You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
228 lines
6.2 KiB
228 lines
6.2 KiB
git-rebase(1) |
|
============= |
|
|
|
NAME |
|
---- |
|
git-rebase - Forward-port local commits to the updated upstream head |
|
|
|
SYNOPSIS |
|
-------- |
|
'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>] |
|
|
|
'git-rebase' --continue | --skip | --abort |
|
|
|
DESCRIPTION |
|
----------- |
|
git-rebase replaces <branch> with a new branch of the same name. When |
|
the --onto option is provided the new branch starts out with a HEAD equal |
|
to <newbase>, otherwise it is equal to <upstream>. It then attempts to |
|
create a new commit for each commit from the original <branch> that does |
|
not exist in the <upstream> branch. |
|
|
|
It is possible that a merge failure will prevent this process from being |
|
completely automatic. You will have to resolve any such merge failure |
|
and run `git rebase --continue`. Another option is to bypass the commit |
|
that caused the merge failure with `git rebase --skip`. To restore the |
|
original <branch> and remove the .dotest working files, use the command |
|
`git rebase --abort` instead. |
|
|
|
Note that if <branch> is not specified on the command line, the currently |
|
checked out branch is used. |
|
|
|
Assume the following history exists and the current branch is "topic": |
|
|
|
------------ |
|
A---B---C topic |
|
/ |
|
D---E---F---G master |
|
------------ |
|
|
|
From this point, the result of either of the following commands: |
|
|
|
|
|
git-rebase master |
|
git-rebase master topic |
|
|
|
would be: |
|
|
|
------------ |
|
A'--B'--C' topic |
|
/ |
|
D---E---F---G master |
|
------------ |
|
|
|
The latter form is just a short-hand of `git checkout topic` |
|
followed by `git rebase master`. |
|
|
|
Here is how you would transplant a topic branch based on one |
|
branch to another, to pretend that you forked the topic branch |
|
from the latter branch, using `rebase --onto`. |
|
|
|
First let's assume your 'topic' is based on branch 'next'. |
|
For example feature developed in 'topic' depends on some |
|
functionality which is found in 'next'. |
|
|
|
------------ |
|
o---o---o---o---o master |
|
\ |
|
o---o---o---o---o next |
|
\ |
|
o---o---o topic |
|
------------ |
|
|
|
We would want to make 'topic' forked from branch 'master', |
|
for example because the functionality 'topic' branch depend on |
|
got merged into more stable 'master' branch, like this: |
|
|
|
------------ |
|
o---o---o---o---o master |
|
| \ |
|
| o'--o'--o' topic |
|
\ |
|
o---o---o---o---o next |
|
------------ |
|
|
|
We can get this using the following command: |
|
|
|
git-rebase --onto master next topic |
|
|
|
|
|
Another example of --onto option is to rebase part of a |
|
branch. If we have the following situation: |
|
|
|
------------ |
|
H---I---J topicB |
|
/ |
|
E---F---G topicA |
|
/ |
|
A---B---C---D master |
|
------------ |
|
|
|
then the command |
|
|
|
git-rebase --onto master topicA topicB |
|
|
|
would result in: |
|
|
|
------------ |
|
H'--I'--J' topicB |
|
/ |
|
| E---F---G topicA |
|
|/ |
|
A---B---C---D master |
|
------------ |
|
|
|
This is useful when topicB does not depend on topicA. |
|
|
|
A range of commits could also be removed with rebase. If we have |
|
the following situation: |
|
|
|
------------ |
|
E---F---G---H---I---J topicA |
|
------------ |
|
|
|
then the command |
|
|
|
git-rebase --onto topicA~5 topicA~2 topicA |
|
|
|
would result in the removal of commits F and G: |
|
|
|
------------ |
|
E---H'---I'---J' topicA |
|
------------ |
|
|
|
This is useful if F and G were flawed in some way, or should not be |
|
part of topicA. Note that the argument to --onto and the <upstream> |
|
parameter can be any valid commit-ish. |
|
|
|
In case of conflict, git-rebase will stop at the first problematic commit |
|
and leave conflict markers in the tree. You can use git diff to locate |
|
the markers (<<<<<<) and make edits to resolve the conflict. For each |
|
file you edit, you need to tell git that the conflict has been resolved, |
|
typically this would be done with |
|
|
|
|
|
git update-index <filename> |
|
|
|
|
|
After resolving the conflict manually and updating the index with the |
|
desired resolution, you can continue the rebasing process with |
|
|
|
|
|
git rebase --continue |
|
|
|
|
|
Alternatively, you can undo the git-rebase with |
|
|
|
|
|
git rebase --abort |
|
|
|
OPTIONS |
|
------- |
|
<newbase>:: |
|
Starting point at which to create the new commits. If the |
|
--onto option is not specified, the starting point is |
|
<upstream>. May be any valid commit, and not just an |
|
existing branch name. |
|
|
|
<upstream>:: |
|
Upstream branch to compare against. May be any valid commit, |
|
not just an existing branch name. |
|
|
|
<branch>:: |
|
Working branch; defaults to HEAD. |
|
|
|
--continue:: |
|
Restart the rebasing process after having resolved a merge conflict. |
|
|
|
--abort:: |
|
Restore the original branch and abort the rebase operation. |
|
|
|
--skip:: |
|
Restart the rebasing process by skipping the current patch. |
|
|
|
--merge:: |
|
Use merging strategies to rebase. When the recursive (default) merge |
|
strategy is used, this allows rebase to be aware of renames on the |
|
upstream side. |
|
|
|
-s <strategy>, \--strategy=<strategy>:: |
|
Use the given merge strategy; can be supplied more than |
|
once to specify them in the order they should be tried. |
|
If there is no `-s` option, a built-in list of strategies |
|
is used instead (`git-merge-recursive` when merging a single |
|
head, `git-merge-octopus` otherwise). This implies --merge. |
|
|
|
-v, \--verbose:: |
|
Display a diffstat of what changed upstream since the last rebase. |
|
|
|
include::merge-strategies.txt[] |
|
|
|
NOTES |
|
----- |
|
When you rebase a branch, you are changing its history in a way that |
|
will cause problems for anyone who already has a copy of the branch |
|
in their repository and tries to pull updates from you. You should |
|
understand the implications of using 'git rebase' on a repository that |
|
you share. |
|
|
|
When the git rebase command is run, it will first execute a "pre-rebase" |
|
hook if one exists. You can use this hook to do sanity checks and |
|
reject the rebase if it isn't appropriate. Please see the template |
|
pre-rebase hook script for an example. |
|
|
|
You must be in the top directory of your project to start (or continue) |
|
a rebase. Upon completion, <branch> will be the current branch. |
|
|
|
Author |
|
------ |
|
Written by Junio C Hamano <junkio@cox.net> |
|
|
|
Documentation |
|
-------------- |
|
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. |
|
|
|
GIT |
|
--- |
|
Part of the gitlink:git[7] suite |
|
|
|
|