Git merge Introduction

The basic use of Git merge is to merge the changes of a branch or a commit into the current branch.
We can run Git merge-h andgit merge--helpView its commands, which go directly to a Web page (git's Help document), in more detail.
Usage:git merge [options] [<commit> ...]
Or:git merge [options] <msg> HEAD <commit>
Or:git Merge--abort

-N do not show a diffstat at the end of the merge
--stat show a diffstat at the end of the merge
--summary (synonym to--stat)
--log[=<n>] Add (at a <n>) entries from Shortlog to merge Commi T message
--squash Create a single commit instead of doing a merge
--commit perform a commit if the merge succeeds (default)
-E,--edit edit message before committing
--ff allow Fast-forward (default)
--ff-only Abort If fast-forward is not possible
--rerere-autoupdate Update the index with reused conflict resolution if PO Ssible
-S,--strategy <strategy>
Merge strategy to use
-X,--strategy-option <option=value>
Option for selected merge strategy
-M,--message <message>
Merge commit message (for a non-fast-forward merge)
-V,--verbose is more verbose
-Q,--quiet is more quiet
--abort abort the current in-progress merge
--progress Force Progress Reporting
-S,--gpg-sign[=<key Id>]
GPG Sign Commit
--overwrite-ignore update ignored files (default)
git merge [options] <msg> head <commit> the head here is actually a branch name that explains merging the head branch into the current branch.

The--squash option means that the local file content is the same as the merge result that does not use this option, but does not preserve historical information on the branch to be merged, nor commits or moves the head, so an additional commit command is required.   The effect is equivalent to merging multiple commits on the another branch into one, placed on the current branch, and the original commit history is not taken. The most fundamental criterion for judging whether to use the--squash option is whether the history on the merged branch is meaningful. If submissions on the development Branch are very casual or even written to a microblog, be sure to use the--squash option. The version history should be the development of the Code, not the activity of the developer at the time of encoding. Only if each commit on the development branch has its own meaning, and it can be compiled (more perfect by testing), the default merge method should be chosen to preserve the commit history. --no-ffCreate a merge commit even when the merge resolves as a fast-forward. This is the default behaviour if merging an annotated (and possibly signed) tag. When we publish the develop branch to the master branch, we may use the following command: # switch to Master branch git checkout Master # Merge the develop branch with git merge--no-ff develop here a little solution Let me explain what the--NO-FF parameter of the previous command means. This command is to be passed git merge--helpView its command, which goes directly to a webpage to see its detailed description by default, Git performs a "fast-forward Merge" (Fast-farward merge) that directly points the master branch to the develop branch. Figure 1-1 shown in Figure 1-2 command: Git checkout mastergit merge robin_local with the--NO-FF parameter, a normal merge is performed and a new node is generated on the master branch. In order to ensure a clear version evolution, we would like to adopt this approach. For more explanations on merging, refer to Benjamin Sandofsky's understanding the Git Workflow. Figure 2-1 shown in Figure 2-2 command: Git checkout mastergit merge robin_local Figure 3Here's an article from Harvard University about git merge
English Address: http://www.eecs.harvard.edu/~cduan/technical/git/git-3.shtml merging

After you had finished implementing a new feature on a branch, you want to bring that new feature into the main branch, s O that everyone can use it. You can do that with the git merge or git pull command.

The syntax for the commands is as follows:

git merge [head]

They is identical in result. (Though the merge form seems simpler for today, the reason for the pull form would become apparent when dis cussing multiple developers.)

These commands perform the following operations. The current head is called current, and the head is merged calledmerge.

1. Identify The common ancestor of current and merge. Call It ancestor-commit.
2. Deal with the easy cases. If The ancestor-commit equals merge, then does nothing. If ancestor-commit equals current, then do a fast forward merge.
3. Otherwise, determine the changes between the ancestor-commit and merge.
4. attempt to merge those changes into the files in current.
5. If There were no conflicts, create a new commit, with the parents, current and merge. set current  (And head) to point to this new commit, and update the working files for the project Accordingl Y.
6. If There was a conflict, insert appropriate conflict markers and inform the user. No commit is created.

Important Note:git can get very confused if there is uncommitted changes in the files when your ask it to perform a merge . So make sure to commit whatever changes you has made so far before you merge.

So, to complete the above example, say you check out the master head again and finish writing up the new data for your PAP Er. Now you want to bring in those changes you made to the headers.

The repository looks like this:

+----------(D)

/             |

(A)--(B)--(C)--------------(E)

| |

Fix-headers Master

|

HEAD

where (E) is the commit reflecting the completed version with the new data.

You would run:

git merge Fix-headers

If There is no conflicts, the resulting respository looks like this:

+----------(D)---------------+

/             | \

(A)--(B)--(C)--------------(E)--(F)

| |

Fix-headers Master

|

HEAD

The merge commit is (F) and has parents (D) and (E). Because (b) is the common ancestor between (d) and (E), the files in (F) should contain the changes between (b) and (d), n Amely the heading fixes, incorporated into the files from (E).

Note on Terminology:when I say "merge head A to head B," I mean that Head B was the current head, and you are drawing ch Anges from head A to it. Head B gets updated; Nothing was done to head A. (If you replace the word ' merge ' with the word ' pull, ' it may make more sense.)

Resolving Conflicts

A conflict arises if the commit to is merged in have a change in one place, and the current commit have a change in the same Place. Git has no how to telling which change should take precedence.

To resolve the commit, edit the files to fix the conflicting changes. Then run git add to add the resolved files, and rungit commit to commit the repaired merge. Git remembers that's were in the middle of a merge, so it sets the parents of the commit correctly.

If there is no conflict, the merge is complete. If there is a conflict, Git will prompt for conflicts in that file, such as the following:

<<<<<<< head:test.c

printf ("Test1″");

=======

printf ("Test2″");

>>>>>>> issuefix:test.c

You can see the top half of the ======= partition, which is the content in the HEAD (that is, the branch that was checked out when the merge command was run), and the lower part is the content in the Issuefix branch. The way to resolve conflicts is to either choose one or you can integrate it yourself. For example, you can solve this by replacing the content with the following:

printf ("Test2″");

This solution incorporates a subset of the two branches, and removes the <<<<<<<,=======, and >>>>>>> lines.

After all the conflicts in all files have been resolved, running git add will mark them as resolved (resolved).

Then use the git commit command to commit, and the merge is complete.

Fast Forward Merges

A fast forward merge is a simple optimization for merging. Say your repository looks like this:

+--(D)------(E)

/            |

(A)--(B)--(C) |

| |

Current To-merge

|

HEAD

And you run git merge to-merge. In the this case, the all Git-needs to does is set for current-to-point (E). Since (C) is the common ancestor, there was no changes to actually "merge."

Hence, the resulting merged repository looks like:

+--(D)--(E)

/            |

(A)--(B)--(C) |

|

To-merge, current

|

HEAD

That's, to-merge and current both point-to-commit (E), and HEAD still points to current.

Note an important Difference:no new commit object was created for the merge. Git only shifts the head pointers around.

Common Merge Use Patterns

There is, common reasons to merge, and branches. The first, as explained above, is to draw the changes from a new feature branch into the main branch.

The second use pattern was to draw the main branch into a feature branch you are developing. This keeps the feature branch up to date with the latest bug fixes and new features added to the main branch. Doing this regularly reduces the risk of creating a conflict when you merge your feature into the main branch.

One disadvantage of doing the above is that your feature branch would end up with a lot of merge commits. An alternative-solves this problem was rebasing, although that comes with problems of its own.

http://blog.csdn.net/hudashi/article/details/7664382

Git merge introduction (GO)