]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-rebase(1) |
2 | ============= | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
c3f0baac | 6 | git-rebase - Forward-port local commits to the updated upstream head |
7fc9d69f JH |
7 | |
8 | SYNOPSIS | |
9 | -------- | |
e448ff87 | 10 | [verse] |
059f446d | 11 | 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] |
f32086be | 12 | [-s <strategy> | --strategy=<strategy>] |
059f446d BF |
13 | [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges] |
14 | [--onto <newbase>] <upstream> [<branch>] | |
cc120056 | 15 | 'git-rebase' --continue | --skip | --abort |
031321c6 | 16 | |
7fc9d69f JH |
17 | DESCRIPTION |
18 | ----------- | |
5ca2db53 SP |
19 | If <branch> is specified, git-rebase will perform an automatic |
20 | `git checkout <branch>` before doing anything else. Otherwise | |
21 | it remains on the current branch. | |
22 | ||
23 | All changes made by commits in the current branch but that are not | |
24 | in <upstream> are saved to a temporary area. This is the same set | |
25 | of commits that would be shown by `git log <upstream>..HEAD`. | |
26 | ||
27 | The current branch is reset to <upstream>, or <newbase> if the | |
28 | --onto option was supplied. This has the exact same effect as | |
29 | `git reset --hard <upstream>` (or <newbase>). | |
30 | ||
31 | The commits that were previously saved into the temporary area are | |
ff905462 JK |
32 | then reapplied to the current branch, one by one, in order. Note that |
33 | any commits in HEAD which introduce the same textual changes as a commit | |
34 | in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream | |
35 | with a different commit message or timestamp will be skipped). | |
69a60af5 | 36 | |
031321c6 SE |
37 | It is possible that a merge failure will prevent this process from being |
38 | completely automatic. You will have to resolve any such merge failure | |
cc120056 SE |
39 | and run `git rebase --continue`. Another option is to bypass the commit |
40 | that caused the merge failure with `git rebase --skip`. To restore the | |
41 | original <branch> and remove the .dotest working files, use the command | |
42 | `git rebase --abort` instead. | |
031321c6 | 43 | |
69a60af5 CW |
44 | Assume the following history exists and the current branch is "topic": |
45 | ||
031321c6 | 46 | ------------ |
69a60af5 CW |
47 | A---B---C topic |
48 | / | |
49 | D---E---F---G master | |
031321c6 | 50 | ------------ |
69a60af5 | 51 | |
228382ae | 52 | From this point, the result of either of the following commands: |
69a60af5 | 53 | |
031321c6 | 54 | |
69a60af5 CW |
55 | git-rebase master |
56 | git-rebase master topic | |
57 | ||
58 | would be: | |
59 | ||
031321c6 | 60 | ------------ |
69a60af5 CW |
61 | A'--B'--C' topic |
62 | / | |
63 | D---E---F---G master | |
031321c6 | 64 | ------------ |
69a60af5 | 65 | |
e52775f4 JN |
66 | The latter form is just a short-hand of `git checkout topic` |
67 | followed by `git rebase master`. | |
69a60af5 | 68 | |
ff905462 JK |
69 | If the upstream branch already contains a change you have made (e.g., |
70 | because you mailed a patch which was applied upstream), then that commit | |
71 | will be skipped. For example, running `git-rebase master` on the | |
72 | following history (in which A' and A introduce the same set of changes, | |
73 | but have different committer information): | |
74 | ||
75 | ------------ | |
76 | A---B---C topic | |
77 | / | |
78 | D---E---A'---F master | |
79 | ------------ | |
80 | ||
81 | will result in: | |
82 | ||
83 | ------------ | |
84 | B'---C' topic | |
85 | / | |
86 | D---E---A'---F master | |
87 | ------------ | |
88 | ||
e52775f4 JN |
89 | Here is how you would transplant a topic branch based on one |
90 | branch to another, to pretend that you forked the topic branch | |
91 | from the latter branch, using `rebase --onto`. | |
69a60af5 | 92 | |
e52775f4 JN |
93 | First let's assume your 'topic' is based on branch 'next'. |
94 | For example feature developed in 'topic' depends on some | |
95 | functionality which is found in 'next'. | |
69a60af5 | 96 | |
031321c6 | 97 | ------------ |
e52775f4 JN |
98 | o---o---o---o---o master |
99 | \ | |
100 | o---o---o---o---o next | |
101 | \ | |
102 | o---o---o topic | |
103 | ------------ | |
104 | ||
105 | We would want to make 'topic' forked from branch 'master', | |
106 | for example because the functionality 'topic' branch depend on | |
107 | got merged into more stable 'master' branch, like this: | |
108 | ||
109 | ------------ | |
110 | o---o---o---o---o master | |
111 | | \ | |
112 | | o'--o'--o' topic | |
113 | \ | |
114 | o---o---o---o---o next | |
031321c6 | 115 | ------------ |
7fc9d69f | 116 | |
e52775f4 JN |
117 | We can get this using the following command: |
118 | ||
119 | git-rebase --onto master next topic | |
120 | ||
121 | ||
122 | Another example of --onto option is to rebase part of a | |
123 | branch. If we have the following situation: | |
124 | ||
125 | ------------ | |
126 | H---I---J topicB | |
127 | / | |
128 | E---F---G topicA | |
129 | / | |
130 | A---B---C---D master | |
131 | ------------ | |
132 | ||
133 | then the command | |
134 | ||
135 | git-rebase --onto master topicA topicB | |
136 | ||
137 | would result in: | |
138 | ||
139 | ------------ | |
140 | H'--I'--J' topicB | |
141 | / | |
142 | | E---F---G topicA | |
143 | |/ | |
144 | A---B---C---D master | |
145 | ------------ | |
146 | ||
147 | This is useful when topicB does not depend on topicA. | |
148 | ||
ea81fcc5 SP |
149 | A range of commits could also be removed with rebase. If we have |
150 | the following situation: | |
151 | ||
152 | ------------ | |
153 | E---F---G---H---I---J topicA | |
154 | ------------ | |
155 | ||
156 | then the command | |
157 | ||
13cc4c81 | 158 | git-rebase --onto topicA~5 topicA~3 topicA |
ea81fcc5 SP |
159 | |
160 | would result in the removal of commits F and G: | |
161 | ||
162 | ------------ | |
163 | E---H'---I'---J' topicA | |
164 | ------------ | |
165 | ||
166 | This is useful if F and G were flawed in some way, or should not be | |
167 | part of topicA. Note that the argument to --onto and the <upstream> | |
168 | parameter can be any valid commit-ish. | |
169 | ||
8978d043 | 170 | In case of conflict, git-rebase will stop at the first problematic commit |
031321c6 SE |
171 | and leave conflict markers in the tree. You can use git diff to locate |
172 | the markers (<<<<<<) and make edits to resolve the conflict. For each | |
173 | file you edit, you need to tell git that the conflict has been resolved, | |
174 | typically this would be done with | |
175 | ||
176 | ||
d7f078b8 | 177 | git add <filename> |
031321c6 SE |
178 | |
179 | ||
180 | After resolving the conflict manually and updating the index with the | |
181 | desired resolution, you can continue the rebasing process with | |
182 | ||
183 | ||
184 | git rebase --continue | |
8978d043 | 185 | |
8978d043 BF |
186 | |
187 | Alternatively, you can undo the git-rebase with | |
188 | ||
031321c6 SE |
189 | |
190 | git rebase --abort | |
8978d043 | 191 | |
7fc9d69f JH |
192 | OPTIONS |
193 | ------- | |
69a60af5 CW |
194 | <newbase>:: |
195 | Starting point at which to create the new commits. If the | |
196 | --onto option is not specified, the starting point is | |
ea81fcc5 SP |
197 | <upstream>. May be any valid commit, and not just an |
198 | existing branch name. | |
69a60af5 | 199 | |
52a22d1e | 200 | <upstream>:: |
ea81fcc5 SP |
201 | Upstream branch to compare against. May be any valid commit, |
202 | not just an existing branch name. | |
7fc9d69f | 203 | |
228382ae | 204 | <branch>:: |
52a22d1e | 205 | Working branch; defaults to HEAD. |
7fc9d69f | 206 | |
031321c6 SE |
207 | --continue:: |
208 | Restart the rebasing process after having resolved a merge conflict. | |
209 | ||
210 | --abort:: | |
211 | Restore the original branch and abort the rebase operation. | |
212 | ||
58634dbf EW |
213 | --skip:: |
214 | Restart the rebasing process by skipping the current patch. | |
58634dbf | 215 | |
3240240f SB |
216 | -m:: |
217 | --merge:: | |
58634dbf EW |
218 | Use merging strategies to rebase. When the recursive (default) merge |
219 | strategy is used, this allows rebase to be aware of renames on the | |
220 | upstream side. | |
221 | ||
3240240f SB |
222 | -s <strategy>:: |
223 | --strategy=<strategy>:: | |
58634dbf EW |
224 | Use the given merge strategy; can be supplied more than |
225 | once to specify them in the order they should be tried. | |
226 | If there is no `-s` option, a built-in list of strategies | |
227 | is used instead (`git-merge-recursive` when merging a single | |
228 | head, `git-merge-octopus` otherwise). This implies --merge. | |
229 | ||
3240240f SB |
230 | -v:: |
231 | --verbose:: | |
b758789c RS |
232 | Display a diffstat of what changed upstream since the last rebase. |
233 | ||
67dad687 MT |
234 | -C<n>:: |
235 | Ensure at least <n> lines of surrounding context match before | |
236 | and after each change. When fewer lines of surrounding | |
237 | context exist they all must match. By default no context is | |
238 | ever ignored. | |
239 | ||
059f446d BF |
240 | --whitespace=<nowarn|warn|error|error-all|strip>:: |
241 | This flag is passed to the `git-apply` program | |
5162e697 | 242 | (see linkgit:git-apply[1]) that applies the patch. |
059f446d | 243 | |
3240240f SB |
244 | -i:: |
245 | --interactive:: | |
1b1dce4b | 246 | Make a list of the commits which are about to be rebased. Let the |
f0fd889d JS |
247 | user edit that list before rebasing. This mode can also be used to |
248 | split commits (see SPLITTING COMMITS below). | |
1b1dce4b | 249 | |
3240240f SB |
250 | -p:: |
251 | --preserve-merges:: | |
f09c9b8c JS |
252 | Instead of ignoring merges, try to recreate them. This option |
253 | only works in interactive mode. | |
254 | ||
58634dbf EW |
255 | include::merge-strategies.txt[] |
256 | ||
031321c6 SE |
257 | NOTES |
258 | ----- | |
259 | When you rebase a branch, you are changing its history in a way that | |
260 | will cause problems for anyone who already has a copy of the branch | |
261 | in their repository and tries to pull updates from you. You should | |
262 | understand the implications of using 'git rebase' on a repository that | |
263 | you share. | |
264 | ||
265 | When the git rebase command is run, it will first execute a "pre-rebase" | |
266 | hook if one exists. You can use this hook to do sanity checks and | |
267 | reject the rebase if it isn't appropriate. Please see the template | |
268 | pre-rebase hook script for an example. | |
269 | ||
702088af | 270 | Upon completion, <branch> will be the current branch. |
031321c6 | 271 | |
1b1dce4b JS |
272 | INTERACTIVE MODE |
273 | ---------------- | |
274 | ||
275 | Rebasing interactively means that you have a chance to edit the commits | |
276 | which are rebased. You can reorder the commits, and you can | |
277 | remove them (weeding out bad or otherwise unwanted patches). | |
278 | ||
279 | The interactive mode is meant for this type of workflow: | |
280 | ||
281 | 1. have a wonderful idea | |
282 | 2. hack on the code | |
283 | 3. prepare a series for submission | |
284 | 4. submit | |
285 | ||
286 | where point 2. consists of several instances of | |
287 | ||
288 | a. regular use | |
289 | 1. finish something worthy of a commit | |
290 | 2. commit | |
291 | b. independent fixup | |
292 | 1. realize that something does not work | |
293 | 2. fix that | |
294 | 3. commit it | |
295 | ||
296 | Sometimes the thing fixed in b.2. cannot be amended to the not-quite | |
297 | perfect commit it fixes, because that commit is buried deeply in a | |
298 | patch series. That is exactly what interactive rebase is for: use it | |
299 | after plenty of "a"s and "b"s, by rearranging and editing | |
300 | commits, and squashing multiple commits into one. | |
301 | ||
302 | Start it with the last commit you want to retain as-is: | |
303 | ||
304 | git rebase -i <after-this-commit> | |
305 | ||
306 | An editor will be fired up with all the commits in your current branch | |
307 | (ignoring merge commits), which come after the given commit. You can | |
308 | reorder the commits in this list to your heart's content, and you can | |
309 | remove them. The list looks more or less like this: | |
310 | ||
311 | ------------------------------------------- | |
312 | pick deadbee The oneline of this commit | |
313 | pick fa1afe1 The oneline of the next commit | |
314 | ... | |
315 | ------------------------------------------- | |
316 | ||
317 | The oneline descriptions are purely for your pleasure; `git-rebase` will | |
318 | not look at them but at the commit names ("deadbee" and "fa1afe1" in this | |
319 | example), so do not delete or edit the names. | |
320 | ||
321 | By replacing the command "pick" with the command "edit", you can tell | |
322 | `git-rebase` to stop after applying that commit, so that you can edit | |
323 | the files and/or the commit message, amend the commit, and continue | |
324 | rebasing. | |
325 | ||
326 | If you want to fold two or more commits into one, replace the command | |
327 | "pick" with "squash" for the second and subsequent commit. If the | |
328 | commits had different authors, it will attribute the squashed commit to | |
81ab1cb4 | 329 | the author of the first commit. |
1b1dce4b JS |
330 | |
331 | In both cases, or when a "pick" does not succeed (because of merge | |
332 | errors), the loop will stop to let you fix things, and you can continue | |
333 | the loop with `git rebase --continue`. | |
334 | ||
335 | For example, if you want to reorder the last 5 commits, such that what | |
336 | was HEAD~4 becomes the new HEAD. To achieve that, you would call | |
337 | `git-rebase` like this: | |
338 | ||
339 | ---------------------- | |
340 | $ git rebase -i HEAD~5 | |
341 | ---------------------- | |
342 | ||
343 | And move the first patch to the end of the list. | |
344 | ||
f09c9b8c JS |
345 | You might want to preserve merges, if you have a history like this: |
346 | ||
347 | ------------------ | |
348 | X | |
349 | \ | |
350 | A---M---B | |
351 | / | |
352 | ---o---O---P---Q | |
353 | ------------------ | |
354 | ||
355 | Suppose you want to rebase the side branch starting at "A" to "Q". Make | |
356 | sure that the current HEAD is "B", and call | |
357 | ||
358 | ----------------------------- | |
359 | $ git rebase -i -p --onto Q O | |
360 | ----------------------------- | |
361 | ||
f0fd889d JS |
362 | |
363 | SPLITTING COMMITS | |
364 | ----------------- | |
365 | ||
366 | In interactive mode, you can mark commits with the action "edit". However, | |
367 | this does not necessarily mean that 'git rebase' expects the result of this | |
368 | edit to be exactly one commit. Indeed, you can undo the commit, or you can | |
369 | add other commits. This can be used to split a commit into two: | |
370 | ||
371 | - Start an interactive rebase with 'git rebase -i <commit>^', where | |
372 | <commit> is the commit you want to split. In fact, any commit range | |
373 | will do, as long as it contains that commit. | |
374 | ||
375 | - Mark the commit you want to split with the action "edit". | |
376 | ||
377 | - When it comes to editing that commit, execute 'git reset HEAD^'. The | |
378 | effect is that the HEAD is rewound by one, and the index follows suit. | |
379 | However, the working tree stays the same. | |
380 | ||
381 | - Now add the changes to the index that you want to have in the first | |
5162e697 DM |
382 | commit. You can use linkgit:git-add[1] (possibly interactively) and/or |
383 | linkgit:git-gui[1] to do that. | |
f0fd889d JS |
384 | |
385 | - Commit the now-current index with whatever commit message is appropriate | |
386 | now. | |
387 | ||
388 | - Repeat the last two steps until your working tree is clean. | |
389 | ||
390 | - Continue the rebase with 'git rebase --continue'. | |
391 | ||
392 | If you are not absolutely sure that the intermediate revisions are | |
393 | consistent (they compile, pass the testsuite, etc.) you should use | |
5162e697 | 394 | linkgit:git-stash[1] to stash away the not-yet-committed changes |
f0fd889d JS |
395 | after each commit, test, and amend the commit if fixes are necessary. |
396 | ||
397 | ||
1b1dce4b | 398 | Authors |
7fc9d69f | 399 | ------ |
1b1dce4b JS |
400 | Written by Junio C Hamano <junkio@cox.net> and |
401 | Johannes E. Schindelin <johannes.schindelin@gmx.de> | |
7fc9d69f JH |
402 | |
403 | Documentation | |
404 | -------------- | |
405 | Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. | |
406 | ||
407 | GIT | |
408 | --- | |
9e1f0a85 | 409 | Part of the linkgit:git[1] suite |