1git-rebase(1) 2============= 3 4NAME 5---- 6git-rebase - Rebase local commits to a new head 7 8SYNOPSIS 9-------- 10'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>] 11 12'git-rebase' --continue | --skip | --abort 13 14DESCRIPTION 15----------- 16git-rebase replaces <branch> with a new branch of the same name. When 17the --onto option is provided the new branch starts out with a HEAD equal 18to <newbase>, otherwise it is equal to <upstream>. It then attempts to 19create a new commit for each commit from the original <branch> that does 20not exist in the <upstream> branch. 21 22It is possible that a merge failure will prevent this process from being 23completely automatic. You will have to resolve any such merge failure 24and run `git rebase --continue`. Another option is to bypass the commit 25that caused the merge failure with `git rebase --skip`. To restore the 26original <branch> and remove the .dotest working files, use the command 27`git rebase --abort` instead. 28 29Note that if <branch> is not specified on the command line, the currently 30checked out branch is used. 31 32Assume the following history exists and the current branch is "topic": 33 34------------ 35 A---B---C topic 36 / 37 D---E---F---G master 38------------ 39 40From this point, the result of either of the following commands: 41 42 43 git-rebase master 44 git-rebase master topic 45 46would be: 47 48------------ 49 A'--B'--C' topic 50 / 51 D---E---F---G master 52------------ 53 54The latter form is just a short-hand of `git checkout topic` 55followed by `git rebase master`. 56 57Here is how you would transplant a topic branch based on one 58branch to another, to pretend that you forked the topic branch 59from the latter branch, using `rebase --onto`. 60 61First let's assume your 'topic' is based on branch 'next'. 62For example feature developed in 'topic' depends on some 63functionality which is found in 'next'. 64 65------------ 66 o---o---o---o---o master 67 \ 68 o---o---o---o---o next 69 \ 70 o---o---o topic 71------------ 72 73We would want to make 'topic' forked from branch 'master', 74for example because the functionality 'topic' branch depend on 75got merged into more stable 'master' branch, like this: 76 77------------ 78 o---o---o---o---o master 79 | \ 80 | o'--o'--o' topic 81 \ 82 o---o---o---o---o next 83------------ 84 85We can get this using the following command: 86 87 git-rebase --onto master next topic 88 89 90Another example of --onto option is to rebase part of a 91branch. If we have the following situation: 92 93------------ 94 H---I---J topicB 95 / 96 E---F---G topicA 97 / 98 A---B---C---D master 99------------ 100 101then the command 102 103 git-rebase --onto master topicA topicB 104 105would result in: 106 107------------ 108 H'--I'--J' topicB 109 / 110 | E---F---G topicA 111 |/ 112 A---B---C---D master 113------------ 114 115This is useful when topicB does not depend on topicA. 116 117In case of conflict, git-rebase will stop at the first problematic commit 118and leave conflict markers in the tree. You can use git diff to locate 119the markers (<<<<<<) and make edits to resolve the conflict. For each 120file you edit, you need to tell git that the conflict has been resolved, 121typically this would be done with 122 123 124 git update-index <filename> 125 126 127After resolving the conflict manually and updating the index with the 128desired resolution, you can continue the rebasing process with 129 130 131 git rebase --continue 132 133 134Alternatively, you can undo the git-rebase with 135 136 137 git rebase --abort 138 139OPTIONS 140------- 141<newbase>:: 142 Starting point at which to create the new commits. If the 143 --onto option is not specified, the starting point is 144 <upstream>. 145 146<upstream>:: 147 Upstream branch to compare against. 148 149<branch>:: 150 Working branch; defaults to HEAD. 151 152--continue:: 153 Restart the rebasing process after having resolved a merge conflict. 154 155--abort:: 156 Restore the original branch and abort the rebase operation. 157 158--skip:: 159 Restart the rebasing process by skipping the current patch. 160 161--merge:: 162 Use merging strategies to rebase. When the recursive (default) merge 163 strategy is used, this allows rebase to be aware of renames on the 164 upstream side. 165 166-s <strategy>, \--strategy=<strategy>:: 167 Use the given merge strategy; can be supplied more than 168 once to specify them in the order they should be tried. 169 If there is no `-s` option, a built-in list of strategies 170 is used instead (`git-merge-recursive` when merging a single 171 head, `git-merge-octopus` otherwise). This implies --merge. 172 173-v, \--verbose:: 174 Display a diffstat of what changed upstream since the last rebase. 175 176include::merge-strategies.txt[] 177 178NOTES 179----- 180When you rebase a branch, you are changing its history in a way that 181will cause problems for anyone who already has a copy of the branch 182in their repository and tries to pull updates from you. You should 183understand the implications of using 'git rebase' on a repository that 184you share. 185 186When the git rebase command is run, it will first execute a "pre-rebase" 187hook if one exists. You can use this hook to do sanity checks and 188reject the rebase if it isn't appropriate. Please see the template 189pre-rebase hook script for an example. 190 191You must be in the top directory of your project to start (or continue) 192a rebase. Upon completion, <branch> will be the current branch. 193 194Author 195------ 196Written by Junio C Hamano <junkio@cox.net> 197 198Documentation 199-------------- 200Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. 201 202GIT 203--- 204Part of the gitlink:git[7] suite 205