6 git-merge - Join two or more development histories together
12 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
13 [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
14 [--[no-]allow-unrelated-histories]
15 [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
20 Incorporates changes from the named commits (since the time their
21 histories diverged from the current branch) into the current
22 branch. This command is used by 'git pull' to incorporate changes
23 from another repository and can be used by hand to merge changes
24 from one branch into another.
26 Assume the following history exists and the current branch is
35 Then "`git merge topic`" will replay the changes made on the
36 `topic` branch since it diverged from `master` (i.e., `E`) until
37 its current commit (`C`) on top of `master`, and record the result
38 in a new commit along with the names of the two parent commits and
39 a log message from the user describing the changes.
44 D---E---F---G---H master
47 The second syntax ("`git merge --abort`") can only be run after the
48 merge has resulted in conflicts. 'git merge --abort' will abort the
49 merge process and try to reconstruct the pre-merge state. However,
50 if there were uncommitted changes when the merge started (and
51 especially if those changes were further modified after the merge
52 was started), 'git merge --abort' will in some cases be unable to
53 reconstruct the original (pre-merge) changes. Therefore:
55 *Warning*: Running 'git merge' with non-trivial uncommitted changes is
56 discouraged: while possible, it may leave you in a state that is hard to
57 back out of in the case of a conflict.
62 include::merge-options.txt[]
65 --gpg-sign[=<keyid>]::
66 GPG-sign the resulting merge commit. The `keyid` argument is
67 optional and defaults to the committer identity; if specified,
68 it must be stuck to the option without a space.
71 Set the commit message to be used for the merge commit (in
74 If `--log` is specified, a shortlog of the commits being merged
75 will be appended to the specified message.
77 The 'git fmt-merge-msg' command can be
78 used to give a good default for automated 'git merge'
79 invocations. The automated message can include the branch description.
81 --[no-]rerere-autoupdate::
82 Allow the rerere mechanism to update the index with the
83 result of auto-conflict resolution if possible.
86 Abort the current conflict resolution process, and
87 try to reconstruct the pre-merge state.
89 If there were uncommitted worktree changes present when the merge
90 started, 'git merge --abort' will in some cases be unable to
91 reconstruct these changes. It is therefore recommended to always
92 commit or stash your changes before running 'git merge'.
94 'git merge --abort' is equivalent to 'git reset --merge' when
95 `MERGE_HEAD` is present.
98 Commits, usually other branch heads, to merge into our branch.
99 Specifying more than one commit will create a merge with
100 more than two parents (affectionately called an Octopus merge).
102 If no commit is given from the command line, merge the remote-tracking
103 branches that the current branch is configured to use as its upstream.
104 See also the configuration section of this manual page.
106 When `FETCH_HEAD` (and no other commit) is specified, the branches
107 recorded in the `.git/FETCH_HEAD` file by the previous invocation
108 of `git fetch` for merging are merged to the current branch.
114 Before applying outside changes, you should get your own work in
115 good shape and committed locally, so it will not be clobbered if
116 there are conflicts. See also linkgit:git-stash[1].
117 'git pull' and 'git merge' will stop without doing anything when
118 local uncommitted changes overlap with files that 'git pull'/'git
119 merge' may need to update.
121 To avoid recording unrelated changes in the merge commit,
122 'git pull' and 'git merge' will also abort if there are any changes
123 registered in the index relative to the `HEAD` commit. (One
124 exception is when the changed index entries are in the state that
125 would result from the merge already.)
127 If all named commits are already ancestors of `HEAD`, 'git merge'
128 will exit early with the message "Already up-to-date."
133 Often the current branch head is an ancestor of the named commit.
134 This is the most common case especially when invoked from 'git
135 pull': you are tracking an upstream repository, you have committed
136 no local changes, and now you want to update to a newer upstream
137 revision. In this case, a new commit is not needed to store the
138 combined history; instead, the `HEAD` (along with the index) is
139 updated to point at the named commit, without creating an extra
142 This behavior can be suppressed with the `--no-ff` option.
147 Except in a fast-forward merge (see above), the branches to be
148 merged must be tied together by a merge commit that has both of them
151 A merged version reconciling the changes from all branches to be
152 merged is committed, and your `HEAD`, index, and working tree are
153 updated to it. It is possible to have modifications in the working
154 tree as long as they do not overlap; the update will preserve them.
156 When it is not obvious how to reconcile the changes, the following
159 1. The `HEAD` pointer stays the same.
160 2. The `MERGE_HEAD` ref is set to point to the other branch head.
161 3. Paths that merged cleanly are updated both in the index file and
162 in your working tree.
163 4. For conflicting paths, the index file records up to three
164 versions: stage 1 stores the version from the common ancestor,
165 stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
166 can inspect the stages with `git ls-files -u`). The working
167 tree files contain the result of the "merge" program; i.e. 3-way
168 merge results with familiar conflict markers `<<<` `===` `>>>`.
169 5. No other changes are made. In particular, the local
170 modifications you had before you started merge will stay the
171 same and the index entries for them stay as they were,
172 i.e. matching `HEAD`.
174 If you tried a merge which resulted in complex conflicts and
175 want to start over, you can recover with `git merge --abort`.
180 When merging an annotated (and possibly signed) tag, Git always
181 creates a merge commit even if a fast-forward merge is possible, and
182 the commit message template is prepared with the tag message.
183 Additionally, if the tag is signed, the signature check is reported
184 as a comment in the message template. See also linkgit:git-tag[1].
186 When you want to just integrate with the work leading to the commit
187 that happens to be tagged, e.g. synchronizing with an upstream
188 release point, you may not want to make an unnecessary merge commit.
190 In such a case, you can "unwrap" the tag yourself before feeding it
191 to `git merge`, or pass `--ff-only` when you do not have any work on
197 git merge --ff-only v1.2.3
201 HOW CONFLICTS ARE PRESENTED
202 ---------------------------
204 During a merge, the working tree files are updated to reflect the result
205 of the merge. Among the changes made to the common ancestor's version,
206 non-overlapping ones (that is, you changed an area of the file while the
207 other side left that area intact, or vice versa) are incorporated in the
208 final result verbatim. When both sides made changes to the same area,
209 however, Git cannot randomly pick one side over the other, and asks you to
210 resolve it by leaving what both sides did to that area.
212 By default, Git uses the same style as the one used by the "merge" program
213 from the RCS suite to present such a conflicted hunk, like this:
216 Here are lines that are either unchanged from the common
217 ancestor, or cleanly resolved because only one side changed.
218 <<<<<<< yours:sample.txt
219 Conflict resolution is hard;
222 Git makes conflict resolution easy.
223 >>>>>>> theirs:sample.txt
224 And here is another line that is cleanly resolved or unmodified.
227 The area where a pair of conflicting changes happened is marked with markers
228 `<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======`
229 is typically your side, and the part afterwards is typically their side.
231 The default format does not show what the original said in the conflicting
232 area. You cannot tell how many lines are deleted and replaced with
233 Barbie's remark on your side. The only thing you can tell is that your
234 side wants to say it is hard and you'd prefer to go shopping, while the
235 other side wants to claim it is easy.
237 An alternative style can be used by setting the "merge.conflictStyle"
238 configuration variable to "diff3". In "diff3" style, the above conflict
242 Here are lines that are either unchanged from the common
243 ancestor, or cleanly resolved because only one side changed.
244 <<<<<<< yours:sample.txt
245 Conflict resolution is hard;
248 Conflict resolution is hard.
250 Git makes conflict resolution easy.
251 >>>>>>> theirs:sample.txt
252 And here is another line that is cleanly resolved or unmodified.
255 In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses
256 another `|||||||` marker that is followed by the original text. You can
257 tell that the original just stated a fact, and your side simply gave in to
258 that statement and gave up, while the other side tried to have a more
259 positive attitude. You can sometimes come up with a better resolution by
260 viewing the original.
263 HOW TO RESOLVE CONFLICTS
264 ------------------------
266 After seeing a conflict, you can do two things:
268 * Decide not to merge. The only clean-ups you need are to reset
269 the index file to the `HEAD` commit to reverse 2. and to clean
270 up working tree changes made by 2. and 3.; `git merge --abort`
271 can be used for this.
273 * Resolve the conflicts. Git will mark the conflicts in
274 the working tree. Edit the files into shape and
275 'git add' them to the index. Use 'git commit' to seal the deal.
277 You can work through the conflict with a number of tools:
279 * Use a mergetool. `git mergetool` to launch a graphical
280 mergetool which will work you through the merge.
282 * Look at the diffs. `git diff` will show a three-way diff,
283 highlighting changes from both the `HEAD` and `MERGE_HEAD`
286 * Look at the diffs from each branch. `git log --merge -p <path>`
287 will show diffs first for the `HEAD` version and then the
288 `MERGE_HEAD` version.
290 * Look at the originals. `git show :1:filename` shows the
291 common ancestor, `git show :2:filename` shows the `HEAD`
292 version, and `git show :3:filename` shows the `MERGE_HEAD`
299 * Merge branches `fixes` and `enhancements` on top of
300 the current branch, making an octopus merge:
302 ------------------------------------------------
303 $ git merge fixes enhancements
304 ------------------------------------------------
306 * Merge branch `obsolete` into the current branch, using `ours`
309 ------------------------------------------------
310 $ git merge -s ours obsolete
311 ------------------------------------------------
313 * Merge branch `maint` into the current branch, but do not make
314 a new commit automatically:
316 ------------------------------------------------
317 $ git merge --no-commit maint
318 ------------------------------------------------
320 This can be used when you want to include further changes to the
321 merge, or want to write your own merge commit message.
323 You should refrain from abusing this option to sneak substantial
324 changes into a merge commit. Small fixups like bumping
325 release/version name would be acceptable.
328 include::merge-strategies.txt[]
332 include::merge-config.txt[]
334 branch.<name>.mergeOptions::
335 Sets default options for merging into branch <name>. The syntax and
336 supported options are the same as those of 'git merge', but option
337 values containing whitespace characters are currently not supported.
341 linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
342 linkgit:gitattributes[5],
343 linkgit:git-reset[1],
344 linkgit:git-diff[1], linkgit:git-ls-files[1],
345 linkgit:git-add[1], linkgit:git-rm[1],
346 linkgit:git-mergetool[1]
350 Part of the linkgit:git[1] suite
projects / git / blob