| git-rebase(1) |
| ============= |
| |
| NAME |
| ---- |
| git-rebase - Rebase local commits to a new head |
| |
| SYNOPSIS |
| -------- |
| 'git-rebase' [--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 |
| ------------ |
| |
| While, starting from the same point, the result of either of the following |
| commands: |
| |
| git-rebase --onto master~1 master |
| git-rebase --onto master~1 master topic |
| |
| would be: |
| |
| ------------ |
| A'--B'--C' topic |
| / |
| D---E---F---G master |
| ------------ |
| |
| 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>. |
| |
| <upstream>:: |
| Upstream branch to compare against. |
| |
| <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. |
| |
| 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 |
| |