1git-rebase(1) 2============= 3 4NAME 5---- 6git-rebase - Forward-port local commits to the updated upstream 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 117A range of commits could also be removed with rebase. If we have 118the following situation: 119 120------------ 121 E---F---G---H---I---J topicA 122------------ 123 124then the command 125 126 git-rebase --onto topicA~5 topicA~2 topicA 127 128would result in the removal of commits F and G: 129 130------------ 131 E---H'---I'---J' topicA 132------------ 133 134This is useful if F and G were flawed in some way, or should not be 135part of topicA. Note that the argument to --onto and the <upstream> 136parameter can be any valid commit-ish. 137 138In case of conflict, git-rebase will stop at the first problematic commit 139and leave conflict markers in the tree. You can use git diff to locate 140the markers (<<<<<<) and make edits to resolve the conflict. For each 141file you edit, you need to tell git that the conflict has been resolved, 142typically this would be done with 143 144 145 git update-index <filename> 146 147 148After resolving the conflict manually and updating the index with the 149desired resolution, you can continue the rebasing process with 150 151 152 git rebase --continue 153 154 155Alternatively, you can undo the git-rebase with 156 157 158 git rebase --abort 159 160OPTIONS 161------- 162<newbase>:: 163 Starting point at which to create the new commits. If the 164 --onto option is not specified, the starting point is 165 <upstream>. May be any valid commit, and not just an 166 existing branch name. 167 168<upstream>:: 169 Upstream branch to compare against. May be any valid commit, 170 not just an existing branch name. 171 172<branch>:: 173 Working branch; defaults to HEAD. 174 175--continue:: 176 Restart the rebasing process after having resolved a merge conflict. 177 178--abort:: 179 Restore the original branch and abort the rebase operation. 180 181--skip:: 182 Restart the rebasing process by skipping the current patch. 183 184--merge:: 185 Use merging strategies to rebase. When the recursive (default) merge 186 strategy is used, this allows rebase to be aware of renames on the 187 upstream side. 188 189-s <strategy>, \--strategy=<strategy>:: 190 Use the given merge strategy; can be supplied more than 191 once to specify them in the order they should be tried. 192 If there is no `-s` option, a built-in list of strategies 193 is used instead (`git-merge-recursive` when merging a single 194 head, `git-merge-octopus` otherwise). This implies --merge. 195 196-v, \--verbose:: 197 Display a diffstat of what changed upstream since the last rebase. 198 199include::merge-strategies.txt[] 200 201NOTES 202----- 203When you rebase a branch, you are changing its history in a way that 204will cause problems for anyone who already has a copy of the branch 205in their repository and tries to pull updates from you. You should 206understand the implications of using 'git rebase' on a repository that 207you share. 208 209When the git rebase command is run, it will first execute a "pre-rebase" 210hook if one exists. You can use this hook to do sanity checks and 211reject the rebase if it isn't appropriate. Please see the template 212pre-rebase hook script for an example. 213 214You must be in the top directory of your project to start (or continue) 215a rebase. Upon completion, <branch> will be the current branch. 216 217Author 218------ 219Written by Junio C Hamano <junkio@cox.net> 220 221Documentation 222-------------- 223Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. 224 225GIT 226--- 227Part of the gitlink:git[7] suite 228