分支管理是Git支持多人协作和版本控制的关键，参照廖雪峰对Git的介绍，对真实开发环境中Git的使用结合实践进行梳理。
|
摘自：廖雪峰的官方网站 在实际开发中，我们应该按照几个基本原则进行分支管理： 首先， 那在哪干活呢？干活都在 你和你的小伙伴们每个人都在 所以，团队合作的分支看起来就像这样：
|
在看具体实践前，需要了解一些理论概念，参考创建与合并分支：
（1）HEAD指针与分支间的关系：
（2）分支合并的时候，默认采用Fast Forward模式，可称为“快进合并”，即将master直接指向dev的当前提交，如下图，但这种模式下，删除分支后，会丢掉分支信息：
（3）no-ff模式，在合并的时候采用该模式，会新创建一个提交，并将master指向该最新提交。
1. 创建git工程
（1）创建本地库：执行命令 git init ，创建 .git隐藏文件
（2）本地库关联远程仓库：用github对工程进行托管，具体可参照添加远程库，为本地库添加远程仓库信息
创建完成后，本地工程如下：
2. 开发过程
假设有2名开发，bob和lilei。
（1）创建开发分支dev
git checkout -b dev，此时该分支还属于私人分支。
git push origin dev:dev，远程仓库创建dev分支，并与本地关联。
git checkout dev 切换分支（切之前，可以先执行 git pull 拉去分支信息，使本地版本库与远程相同）。
（2）对index.html文件进行修改，bob添加“add by bob”，提交到远程仓库，具体指令参照Git常用命令
（3）lilei拉取最新代码，并进行修改，在index.html中添加“add by lilei”
① git fetch origin dev 拉去dev分支最新代码
② git merge --no-ff -m \'合并最新代码\' dev 采用no-ff方式，将拉取的最新代码与本地合并，注意：不加 -m后边参数，会打开编辑器，输入注解
③ 在index.html中添加“add by lilei”，提交并push到远程仓库
（4）bob拉取最新代码，并将dev分支合并到master分支
① git pull origin dev 直接pull，代替fetch+merge操作，默认采用Fast-Forward模式合并。（此处应该采用（3）先fetch，再merge，分支结构更明显）
② git checkout master 切到主分支
③ git merge --no-ff -m \'merge with no-ff\' dev 或者 git merge dev，会对dev和master进行合并提交
④ git push origin 将合并后的主分支同步到远程仓库
3. 分支结构
（1）采用no-ff模式
执行命令： git log --graph --pretty=oneline --abbrev-commit 查看分支图形结构，如下：
① bob在dev的本地分支上修改文件，并提交到远程仓库。
② lilei本地拉取最新文件，并采用 no-ff方式进行合并（新创建一个提交，从而是dev分支的HEAD指针指向新提交）
③ lilei修改文件，并提交到远程仓库。bob直接pull拉取，默认采用Fast-Forward模式。
④ bob将dev合并到master分支，执行命令 git merge --no-ff -m \'merge with no-ff\' dev。
在github上查看最后一次提交，其中本次提交有2个parent（4f368cc和5b53028），与上图对应，如下：
（2）采用Fast Forward模式
① 第一种模式最后一次提交。
② bob将修改提交远程仓库。lilei从远程仓库直接pull拉取合并，采用Fast Forward方式，没有产生新的提交。
③ lilei将修改提交远程仓库。bob拉取远程仓库后合并（fetch+merge），采用Fast Forward模式，没产生新的提交。
④ 切换到master分支，执行 git merge dev 合并。
4. 合并冲突解决
遇到冲突时，Git已经做了合并，但是没有自动地创建一个新的合并提交。 Git会暂停下来，等待你去解决合并产生的冲突，然后再对冲突的文件执行提交（add、commit、push）即可，但分支树上会记录冲突。
具体做法参考：Git 分支 - 分支的新建与合并