Original: http://gitbook.liuhui998.com/3_3.htmlhttp://gitbook.liuhui998.com/5_3.html
first, how to merge the branchesIn Git, you can use git merge and git rebase two commands to merge the branches. git merge and Git rebase are pretty much the same, and the following are mainly examples of git merge to explain the branching process. If you want to learn more about branching merge, read git merge introduction, git rebase introduction (Basic), and Git rebase Introduction (Advanced section). Git merge Command example: $ git merge branchname This command merges the branch "Branchname" into the current branch. If there is a conflict (conflict--the same file is modified in a different way in the remote branch and local branch); then the command executes the output as follows $ git merge next 100% (4/4) doneauto-merged file.txtconflict ( Content): Merge conflict in file.txtautomatic merge failed; Fix conflicts and then commits the result. There will be conflicting tags on the problematic file, you can add this file to the index after you manually resolve the conflict, and commit it with the git commit command, just as you normally modify a file The same. If you use GITK to see the results of a commit, you will see that it has two parent branches: one pointing to the current branch and the other to the branch that you just merged in.
ii. resolving conflicts in a mergerIf you do not succeed with automatic merging, git sets a special state in the index and work tree to show you how to resolve conflicts in the merge. Files with conflicts (conflicts) will be saved in the index, unless you solve the problem and update the index, executing a git commit will fail: git commitfile.txt:needs merge if you do git status Will show that these files are not merged (unmerged), these conflicting files will be added like the following conflicting identifiers:<<<<<<< HEAD:file.txtHello World=======goodbye >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086: File.txt all you need to do is edit the conflict, (then delete the conflict identifier), then execute the following command: $ git add file.txt$ git commit Note: There is already some information about merging in the commit comment, usually with these default information, But you can add some of the comments you want. These are the things you need to know to do a simple merge, but git provides more information to help resolve conflicts.
Iii. Distribution of a mergerIf you think your merged state is mess and you want to discard the current changes, you can use the following command to return to the state before the merge: $ git reset--hard head or you have already submitted the merged code, but still want to scatter them: $ git reset--hard Orig_head But just now this command can be dangerous in some cases, and if you delete a branch that has been merged by another branch, then you will get an error when merging related branches. For more information on undo, please refer to "Git Reset profile"
Iv. Quick and forward mergingThere is also a situation that requires special treatment, which is not mentioned earlier. Typically, a merge produces a merge commit (commit) that merges the contents of each row in the two parent branch. However, if there is no difference in content between the current branch and the other branch, that is, each commit (commit) of the current branch already exists in another branch, and Git executes a fast forward operation, and Git does not create any new commits (commit) , just point the current branch to the merged branch.
v. Assistance in conflict resolution in the course of the mergerGit adds all the changes that can be automatically merged into the index, so git diff shows only the conflicting parts. It uses an uncommon syntax: $ git diffdiff--cc file.txtindex 802992c,2b60207. 0000000---a/file.txt+++ b/file.txt@@@ -1,1-1,1 +1,5 @@@++<<<<<<< Head:file.txt +hello world++=======+ Goodbye++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt recalled, After we resolve the conflict, the resulting commit will have two instead of a parent commit: a parent commit is the head before the current branch commits; Another parent commit is the HEAD of the merged branch, which is temporarily present merge_head. During the merge process, three versions of each file are saved in the index. Each of the three file stage files represents a different version of the file: $ git show:1:file.txt # two branches in a common ancestor version. $ git show:2:file.txt # Version in head. $ git show:3:file.txt version in # merge_head. When you use Git diff to show conflicts, it is in the work Tree, staging 2 (Stage 2) and staging 3 ( Stage 3) performs a three-way diff operation, showing only those blocks (in other words, when the merge result of a block is only obtained from the staging 2, it is not displayed; The diff result above shows the file.txt in the working tree, Differences in staging 2 and staging 3. git does not precede each line with a single ' + ' or '-', instead, it uses two columns to display the difference: The first column shows the difference between the first parent commit and the working directory file copy, and the second column shows the difference between the second parent commit and the working file copy. (see "COMBINED diff format" in Git diff-files to get this format details.) After resolving the conflict in an intuitive way (but before updating the index), diffThe output will look like this: $ git diffdiff--cc file.txtindex 802992c,2b60207. 0000000---a/file.txt+++ b/file.txt@@@ -1,1-1,1 +1,1 @@@-Hello World-goodbye++goodbye World's output shows that the conflict resolution version removes the "Hello world" provided by the first parent version and the "Goodbye" provided by the second parent, and then joins the "Goodbye world" that is not included in the two parent versions. Some special diff options allow you to compare the differences between the working directory and any of the three staging: $ git diff-1 file.txt # vs. staging 1 compare $ git diff--base file.txt &nbs P # with the same $ git diff-2 file.txt # compared to staging 2 $ git diff--ours File.txt # with the same $ git diff-3 file.txt # compared to staging 3 $ git diff--theirs fil E.txt # the same as on. Also, the Git log and GITK commands provide special assistance for merge operations: $ git log --merge$ gitk -- Merge This will show all commits that exist only at head or only in Merge_head, and those that have updated (touch) files that have not been merged. You can also use Git Mergetool, which allows you to merge files using external tools such as Emacs or KDIFF3 . every time you resolve a conflict, you should update the index: $ git add file.txt after the index update is complete, Git-diff (by default) no longer shows the difference in that file, so the different staging versions of that file are "collapsed".
Vi. merger of multiple roadsYou can merge multiple headers at once, simply by listing them as a git merge parameter. For example, $ git merge scott/master rick/master tom/master equivalent to: $ git merge scott/master$ git merge rick/master$ git merge tom/maste R
Seven, sub-treeThere are times when you want to introduce content from other independent development projects in your own project. Without path collisions, you simply need to pull the content from other projects. If there are conflicting files, then the problem occurs. Possible examples include makefile and some other standard file names. You can choose to merge these conflicting files, but in more cases you don't want to merge them. A better solution would be to merge the external project as a subdirectory. This is not supported by a recursive merge strategy, so a simple pull is useless. In this case, you need a subtree merge strategy. In this example, we set you to have a warehouse located in/path/to/b (or a URL if you need to). You want to merge the Master branch of that repository into the dir-b subdirectory of your current repository. Here's the sequence of commands you need: $ git remote add-f bproject/path/to/b (1) $ git merge-s ours--no-commi T Bproject/master (2) $ git read-tree--prefix=dir-b/-u bproject/master (3) $ git commit-m "Merge B project as our Subdire Ctory "(4) $ git pull-s subtree bproject master (5) The benefit of a subtree merge is that it does not add too much administrative burden to the users of your warehouse. It is compatible with older (version number less than 1.5.2) clients and can get the code immediately after cloning is complete. However, if you use Submodules (submodule), you can choose not to transfer these submodule objects. This may cause problems during the subtree merge process. Translator Note: Submodule is another way for git to embed other warehouses into the local warehouse. In addition, if you need to modify the contents of an inline external project, you can make it easier to submit your changes using the Submodule method.
Merging of git branches
