本文共 6155 字，大约阅读时间需要 20 分钟。
此处以github平台为例。
查看分支的情况，前面带*号的就是当前分支
git branch创建分支
git branch 分支名删除分支
git branch -d 分支名切换当前分支到指定分支
git checkout 分支名创建分支并切换到创建的分支
git checkout -b 分支名合并某分支的内容到当前分支
git merge 分支名如果两个分支同时进行了同一个文件的修改和提交，在merge时就会产生冲突，首先要手动打开文件解决冲突，再提交。
查看分支合并图
git log --graph红色和绿色的虚线分别代表两个分支。
git merge 的原理：
我们知道分支文件中存储的是当前分支的最新一次提交的commitID，也就是版本号，而每一个版本号对应的 objects 文件中都存储着 parent 版本号（首次提交没有 parent），以此将版本串起来，每一个分支都有自己的串。 比如将分支A合并到分支B，其实就意味着使分支B和分支A的内容完全一致，那么要达到这个目的最快的方式就是将分支A中的最新的commitID复制到分支B的文件中，这样分支B也就拥有了分支A的串，就达到了合并的效果。
如果在合并的时候出现了冲突，需要手动编辑解决冲突，然后提交一个commit，但是分支A上还是之前的内容。
创建 b2 分支git checkout -b b2修改 t1.txt 文件，并提交回到 master 分支，修改 t1.txt，并提交分别查看 log$ git log -3 --pretty=oneline2a09fbe5794df384dab0cf0a95751a969a5ae057 (HEAD -> master) yy4052f8d1f053d8b486673b5e1c79c3720ff2316f del0d3d0d430b2fb9f5788cde925319f718eaddd61d add$ git log b2 -3 --pretty=oneline837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx4052f8d1f053d8b486673b5e1c79c3720ff2316f del0d3d0d430b2fb9f5788cde925319f718eaddd61d add可见是在 4052f8d1f053d8b486673b5e1c79c3720ff2316f 时产生的分支，之后各自有一个提交。试图将 b2 合并到 master$ git merge b2Auto-merging t1.txtCONFLICT (content): Merge conflict in t1.txtAutomatic merge failed; fix conflicts and then commit the result.手动修复 master 冲突文件，然后提交$ git add .$ git commit -m 'fix'[master 19bf978] fix再次查看 log$ git log -3 --pretty=oneline19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> master) fix2a09fbe5794df384dab0cf0a95751a969a5ae057 yy837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx$ git log b2 -3 --pretty=oneline837a61a1e32de4bf25ced7ff6b8dc2820968100c (b2) xx4052f8d1f053d8b486673b5e1c79c3720ff2316f del0d3d0d430b2fb9f5788cde925319f718eaddd61d add可以看到分支 b2 并没有什么变化，而分支 master 变化较大，首先 b2 的 837a61a1e3 插入到了 master 的 2a09fbe579 的前面去了（那是因为 b2 比 master 先提交的）；其次 master 多出了一个新提交 19bf978522。此时，对于 b2，如果不需要了则可以删掉这个本地分支；如果还有用那么就应该使 b2 同步，防止以后出现差错。$ git checkout b2$ git merge masterUpdating 837a61a..19bf978Fast-forward t1.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 将 master 同步到 b2，并不会有冲突发生，那是因为 master 最新的提交晚于 b2 最新的提交，Git 认为可以直接覆盖。所以，当你准备将“早期”代码合并到“晚期”代码中时才可能出现冲突，反之则不会。最后再查看一次 log$ git log master -6 --pretty=oneline19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> b2, master) fix2a09fbe5794df384dab0cf0a95751a969a5ae057 yy837a61a1e32de4bf25ced7ff6b8dc2820968100c xx4052f8d1f053d8b486673b5e1c79c3720ff2316f del0d3d0d430b2fb9f5788cde925319f718eaddd61d add71243b890c66751d8b32d547f0a0f6150775903c rm$ git log b2 -6 --pretty=oneline19bf97852267733011f5f4bf5793d4a22224f71b (HEAD -> b2, master) fix2a09fbe5794df384dab0cf0a95751a969a5ae057 yy837a61a1e32de4bf25ced7ff6b8dc2820968100c xx4052f8d1f053d8b486673b5e1c79c3720ff2316f del0d3d0d430b2fb9f5788cde925319f718eaddd61d add71243b890c66751d8b32d547f0a0f6150775903c rm
默认情况下Git会使用Fast-forward的方式来merge，这样的好处是快，当然也有不好的地方，比如
$ git log master -5 --pretty=onelinef3e1527aa1b7a44d4a34efcd15cbe48f3148ed1e (HEAD -> master) qqq4a573a96f86a404fe22745ffd71c5341f636438d (b5) 555fd0ef1ad99851b0871b6544eab1c5dd051c63882 444069ec4544846898724d7c8cf8de6f8e0dcaaf408 merge from b331d8a05af468dc14dd5d1cfbdd8e8b6ca3b3db0b 333现在你可以清楚的看到 555 是从 b5 merge 来的，但是如果我把 b5 分支删掉了$ git branch -d b5Deleted branch b5 (was 4a573a9).再次查看，你就不知道 555 是来自 merge，因此 fast-forward 模式会丢掉分支信息。$ git log master -5 --pretty=onelinef3e1527aa1b7a44d4a34efcd15cbe48f3148ed1e (HEAD -> master) qqq4a573a96f86a404fe22745ffd71c5341f636438d 555fd0ef1ad99851b0871b6544eab1c5dd051c63882 444069ec4544846898724d7c8cf8de6f8e0dcaaf408 merge from b331d8a05af468dc14dd5d1cfbdd8e8b6ca3b3db0b 333鉴于此，在 merge 的时候加上 --no-ff 参数即可避免掉这个问题，他会产生一个新的commit。$ git merge --no-ff b3 -m 'merge from b3'
当前目录有 aaa.txt, bbb.txt ，且是干净状态。
当前为master分支。创建分支
git branch test-branch切换分支
git checkout test-branch当前目录具有和master分支一样的结构，可见 test-branch 分支会继承当时创建它的分支的状态。
编辑文件
vi ccc.txt 提交 git add . git commit -m ‘add ccc’ 该分支第一次提交 git push -u origin test-branch 在Gitlab服务器查看我们推送的分支，它会自动创建分支 test-branch此时 test-branch 分支有ccc.txt文件，而master分支是没有的。
切换到master
git checkout master目录下没有ccc.txt文件。
合并 test-branch 分支到master分支，首先要pull到最新版本。
git pull origin master git merge test-branch git push origin master 在Gitlab服务器查看master删除所创建的分支
git push origin --delete test-branch git branch 发现 test-branch 依然存在本地，而远程仓库不存在此分支了。 git branch -d test-branch git branch 发现 test-branch 已经不存在了可见git的多分支是共用一个working copy，当前是那个分支就显示那个分支的内容。
git branch test-branch
git checkout test-branch git push -u origin test-branch 修改ccc.txt文件 git add . git commit -m ‘modify ccc 2’ git push origin test-branch git checkout master 修改ccc.txt文件 git status git merge test-brancherror: Your local changes to the following files would be overwritten by merge: ccc.txt Please commit your changes or stash them before you merge. Aborting
显然，如果有改动未提交，是不让merge的。
git add . git commit -m ‘modify ccc 3’ git merge test-branchAuto-merging ccc.txt CONFLICT (content): Merge conflict in ccc.txt Automatic merge failed; fix conflicts and then commit the result
此时test-branch分支已经合并过来了，只是出现了冲突，打开ccc.txt解决冲突内容，然后提交。
git add . git commit -m ‘resolve conflict’ git push origin master git status git log --graph之前svn解决玩冲突还需要执行resolved命令，而git则不需要，直接提交即可。
master develop testing task1 task2
master 主干，线上处于此分支，有权限控制
develop 过度分支 testing 测试专用分支 task1 任务1 task2 任务11、管理员在master分支创建develop，并负责将develop合并到master。
2、开发的时候在develop分支创建task1，在task1中开发，将task1合并到develop，为了减少冲突应经常将develop合并到task1，将task1合并到develop操作。
3、测试的时候去到测试服务器将develop合并到testing。
4、发布的时候去到线上服务器将develop合并到master。
比如你正在 task1 上开发一个功能，而且开发了一段时间了，这个时候突然线上报出一个bug，你需要立即修复，这个时候应该先保护好现场（使用 git stash 命令），不然切换分支后你的心该滴血了；然后从 master 创建一个分支bug-100，为什么不能从 develop 创建呢？因为在多人开发模式下 develop 分支上经常会有一些暂时不需要同步到 master 上的提交。
修复好之后将分支 bug-100 的提交 merge 到 master （加上 --no-ff 参数），然后发布到线上，删除 bug-100 分支。
总感觉哪里还少了点啥，是的，你的 develop 分支上同样存在这个bug，而且我是在 bug-100 分支上修复的，不是在 task1 分支，所以如果不修复之，日后将 develop 上的提交同步到 master 上的时候是不是会把这个 bug 也带过去了呢？
既然如此，有人会说，这还不简单，将 master 同步到 develop 不就行了。显然不能这么干，因为 develop 上面还有一些提交没有同步到 master ，开头就提到过，这样做将会是一场悲剧。 又有人说了，那我在 develop 分支再重复修复一遍总行吧，这个当然可以。不过 Git 专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：git cherry-pick commitID并且 Git 会替当前分支做一次提交。
此时就可以回到 task1 分支上，恢复之前保存的现场，并且要从 develop 同步一次，然后接着开发了。
关于 git stash 命令可以参考
转载地址：http://cdaui.baihongyu.com/