.\"Generated by db2man.xsl. Don't modify this, modify the source.
.de Sh \" Subsection
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Ip \" List item
.br
.ie \\n(.$>=3 .ne \\$3
.el .ne 3
.IP "\\$1" \\$2
..
.TH "GIT-REBASE" 1 "" "" ""
.SH NAME
git-rebase \- Rebase local commits to a new head
.SH "SYNOPSIS"


\fIgit\-rebase\fR [\-\-onto <newbase>] <upstream> [<branch>]


\fIgit\-rebase\fR \-\-continue


\fIgit\-rebase\fR \-\-abort

.SH "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\&. 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\&.


Assume the following history exists and the current branch is "topic":

.nf
          A\-\-\-B\-\-\-C topic
         /
    D\-\-\-E\-\-\-F\-\-\-G master
.fi


From this point, the result of either of the following commands:

.nf
git\-rebase master
git\-rebase master topic
.fi


would be:

.nf
                  A'\-\-B'\-\-C' topic
                 /
    D\-\-\-E\-\-\-F\-\-\-G master
.fi


While, starting from the same point, the result of either of the following commands:

.nf
git\-rebase \-\-onto master~1 master
git\-rebase \-\-onto master~1 master topic
.fi


would be:

.nf
              A'\-\-B'\-\-C' topic
             /
    D\-\-\-E\-\-\-F\-\-\-G master
.fi


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

.nf
git update\-index <filename>
.fi


After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with

.nf
git rebase \-\-continue
.fi


Alternatively, you can undo the git\-rebase with

.nf
git rebase \-\-abort
.fi

.SH "OPTIONS"

.TP
<newbase>
Starting point at which to create the new commits\&. If the \-\-onto option is not specified, the starting point is <upstream>\&.

.TP
<upstream>
Upstream branch to compare against\&.

.TP
<branch>
Working branch; defaults to HEAD\&.

.TP
\-\-continue
Restart the rebasing process after having resolved a merge conflict\&.

.TP
\-\-abort
Restore the original branch and abort the rebase operation\&.

.SH "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 \fIgit rebase\fR 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\&.

.SH "AUTHOR"


Written by Junio C Hamano <junkio@cox\&.net>

.SH "DOCUMENTATION"


Documentation by Junio C Hamano and the git\-list <git@vger\&.kernel\&.org>\&.

.SH "GIT"


Part of the \fBgit\fR(7) suite