gitk - remove trailing whitespace from a few lines.
[git/mingw.git] / Documentation / git-rebase.txt
blob977f661b9d7a1b92d27959429c48450a416c08b8
1 git-rebase(1)
2 =============
4 NAME
5 ----
6 git-rebase - Forward-port local commits to the updated upstream head
8 SYNOPSIS
9 --------
10 'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>]
12 'git-rebase' --continue | --skip | --abort
14 DESCRIPTION
15 -----------
16 git-rebase replaces <branch> with a new branch of the same name.  When
17 the --onto option is provided the new branch starts out with a HEAD equal
18 to <newbase>, otherwise it is equal to <upstream>.  It then attempts to
19 create a new commit for each commit from the original <branch> that does
20 not exist in the <upstream> branch.
22 It is possible that a merge failure will prevent this process from being
23 completely automatic.  You will have to resolve any such merge failure
24 and run `git rebase --continue`.  Another option is to bypass the commit
25 that caused the merge failure with `git rebase --skip`.  To restore the
26 original <branch> and remove the .dotest working files, use the command
27 `git rebase --abort` instead.
29 Note that if <branch> is not specified on the command line, the currently
30 checked out branch is used.
32 Assume the following history exists and the current branch is "topic":
34 ------------
35           A---B---C topic
36          /
37     D---E---F---G master
38 ------------
40 From this point, the result of either of the following commands:
43     git-rebase master
44     git-rebase master topic
46 would be:
48 ------------
49                   A'--B'--C' topic
50                  /
51     D---E---F---G master
52 ------------
54 The latter form is just a short-hand of `git checkout topic`
55 followed by `git rebase master`.
57 Here is how you would transplant a topic branch based on one
58 branch to another, to pretend that you forked the topic branch
59 from the latter branch, using `rebase --onto`.
61 First let's assume your 'topic' is based on branch 'next'.
62 For example feature developed in 'topic' depends on some
63 functionality which is found in 'next'.
65 ------------
66     o---o---o---o---o  master
67          \
68           o---o---o---o---o  next
69                            \
70                             o---o---o  topic
71 ------------
73 We would want to make 'topic' forked from branch 'master',
74 for example because the functionality 'topic' branch depend on
75 got merged into more stable 'master' branch, like this:
77 ------------
78     o---o---o---o---o  master
79         |            \
80         |             o'--o'--o'  topic
81          \
82           o---o---o---o---o  next
83 ------------
85 We can get this using the following command:
87     git-rebase --onto master next topic
90 Another example of --onto option is to rebase part of a
91 branch.  If we have the following situation:
93 ------------
94                             H---I---J topicB
95                            /
96                   E---F---G  topicA
97                  /
98     A---B---C---D  master
99 ------------
101 then the command
103     git-rebase --onto master topicA topicB
105 would result in:
107 ------------
108                  H'--I'--J'  topicB
109                 /
110                 | E---F---G  topicA
111                 |/
112     A---B---C---D  master
113 ------------
115 This is useful when topicB does not depend on topicA.
117 A range of commits could also be removed with rebase.  If we have
118 the following situation:
120 ------------
121     E---F---G---H---I---J  topicA
122 ------------
124 then the command
126     git-rebase --onto topicA~5 topicA~2 topicA
128 would result in the removal of commits F and G:
130 ------------
131     E---H'---I'---J'  topicA
132 ------------
134 This is useful if F and G were flawed in some way, or should not be
135 part of topicA.  Note that the argument to --onto and the <upstream>
136 parameter can be any valid commit-ish.
138 In case of conflict, git-rebase will stop at the first problematic commit
139 and leave conflict markers in the tree.  You can use git diff to locate
140 the markers (<<<<<<) and make edits to resolve the conflict.  For each
141 file you edit, you need to tell git that the conflict has been resolved,
142 typically this would be done with
145     git update-index <filename>
148 After resolving the conflict manually and updating the index with the
149 desired resolution, you can continue the rebasing process with
152     git rebase --continue
155 Alternatively, you can undo the git-rebase with
158     git rebase --abort
160 OPTIONS
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.
168 <upstream>::
169         Upstream branch to compare against.  May be any valid commit,
170         not just an existing branch name.
172 <branch>::
173         Working branch; defaults to HEAD.
175 --continue::
176         Restart the rebasing process after having resolved a merge conflict.
178 --abort::
179         Restore the original branch and abort the rebase operation.
181 --skip::
182         Restart the rebasing process by skipping the current patch.
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.
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.
196 -v, \--verbose::
197         Display a diffstat of what changed upstream since the last rebase.
199 include::merge-strategies.txt[]
201 NOTES
202 -----
203 When you rebase a branch, you are changing its history in a way that
204 will cause problems for anyone who already has a copy of the branch
205 in their repository and tries to pull updates from you.  You should
206 understand the implications of using 'git rebase' on a repository that
207 you share.
209 When the git rebase command is run, it will first execute a "pre-rebase"
210 hook if one exists.  You can use this hook to do sanity checks and
211 reject the rebase if it isn't appropriate.  Please see the template
212 pre-rebase hook script for an example.
214 You must be in the top directory of your project to start (or continue)
215 a rebase.  Upon completion, <branch> will be the current branch.
217 Author
218 ------
219 Written by Junio C Hamano <junkio@cox.net>
221 Documentation
222 --------------
223 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
227 Part of the gitlink:git[7] suite