2005-09-08 04:26:23 +04:00
|
|
|
git-rebase(1)
|
|
|
|
=============
|
2005-08-23 12:49:47 +04:00
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2006-04-26 18:49:38 +04:00
|
|
|
git-rebase - Rebase local commits to a new head
|
2005-08-23 12:49:47 +04:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2006-02-22 04:10:12 +03:00
|
|
|
'git-rebase' [--onto <newbase>] <upstream> [<branch>]
|
2005-08-23 12:49:47 +04:00
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
'git-rebase' --continue
|
|
|
|
|
|
|
|
'git-rebase' --abort
|
|
|
|
|
2005-08-23 12:49:47 +04:00
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2006-04-26 18:49:38 +04:00
|
|
|
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.
|
2006-02-22 04:10:12 +03:00
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
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`. If you can not resolve the merge
|
|
|
|
failure, running `git rebase --abort` will restore the original <branch>
|
|
|
|
and remove the working files found in the .dotest directory.
|
|
|
|
|
|
|
|
Note that if <branch> is not specified on the command line, the currently
|
|
|
|
checked out branch is used.
|
2006-02-22 04:10:12 +03:00
|
|
|
|
|
|
|
Assume the following history exists and the current branch is "topic":
|
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2006-02-22 04:10:12 +03:00
|
|
|
A---B---C topic
|
|
|
|
/
|
|
|
|
D---E---F---G master
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2006-02-22 04:10:12 +03:00
|
|
|
|
2006-03-18 03:25:30 +03:00
|
|
|
From this point, the result of either of the following commands:
|
2006-02-22 04:10:12 +03:00
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
|
2006-02-22 04:10:12 +03:00
|
|
|
git-rebase master
|
|
|
|
git-rebase master topic
|
|
|
|
|
|
|
|
would be:
|
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2006-02-22 04:10:12 +03:00
|
|
|
A'--B'--C' topic
|
|
|
|
/
|
|
|
|
D---E---F---G master
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2006-02-22 04:10:12 +03:00
|
|
|
|
2006-03-18 03:25:30 +03:00
|
|
|
While, starting from the same point, the result of either of the following
|
2006-02-22 04:10:12 +03:00
|
|
|
commands:
|
|
|
|
|
|
|
|
git-rebase --onto master~1 master
|
|
|
|
git-rebase --onto master~1 master topic
|
|
|
|
|
|
|
|
would be:
|
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2006-02-22 04:10:12 +03:00
|
|
|
A'--B'--C' topic
|
|
|
|
/
|
|
|
|
D---E---F---G master
|
2006-04-26 18:49:38 +04:00
|
|
|
------------
|
2005-08-23 12:49:47 +04:00
|
|
|
|
2006-03-27 00:29:28 +04:00
|
|
|
In case of conflict, git-rebase will stop at the first problematic commit
|
2006-04-26 18:49:38 +04:00
|
|
|
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
|
2006-03-27 00:29:28 +04:00
|
|
|
|
|
|
|
|
|
|
|
Alternatively, you can undo the git-rebase with
|
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
|
|
|
|
git rebase --abort
|
2006-03-27 00:29:28 +04:00
|
|
|
|
2005-08-23 12:49:47 +04:00
|
|
|
OPTIONS
|
|
|
|
-------
|
2006-02-22 04:10:12 +03:00
|
|
|
<newbase>::
|
|
|
|
Starting point at which to create the new commits. If the
|
|
|
|
--onto option is not specified, the starting point is
|
|
|
|
<upstream>.
|
|
|
|
|
2005-08-27 05:18:48 +04:00
|
|
|
<upstream>::
|
|
|
|
Upstream branch to compare against.
|
2005-08-23 12:49:47 +04:00
|
|
|
|
2006-03-18 03:25:30 +03:00
|
|
|
<branch>::
|
2005-08-27 05:18:48 +04:00
|
|
|
Working branch; defaults to HEAD.
|
2005-08-23 12:49:47 +04:00
|
|
|
|
2006-04-26 18:49:38 +04:00
|
|
|
--continue::
|
|
|
|
Restart the rebasing process after having resolved a merge conflict.
|
|
|
|
|
|
|
|
--abort::
|
|
|
|
Restore the original branch and abort the rebase operation.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
2005-08-23 12:49:47 +04:00
|
|
|
Author
|
|
|
|
------
|
|
|
|
Written by Junio C Hamano <junkio@cox.net>
|
|
|
|
|
|
|
|
Documentation
|
|
|
|
--------------
|
|
|
|
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
|
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
2005-09-19 14:10:51 +04:00
|
|
|
Part of the gitlink:git[7] suite
|
2005-08-23 12:49:47 +04:00
|
|
|
|