一、分支的创建与合并

在程序项目开发中，git 提供了分支功能，为项目的分佈式开发提供支持，避免开发者之间产生衝突。其中 master 分支最爲重要，它是提供给客户使用的，因此，对于开发而言，应该创建其他的分支进行开发。

查看当前仓库的分支：git branch，结果内容中以“*”标记当前使用的分支。

创建新的分支：git branch 新分支名称

在新分支上进行开发，切换到新分支上：git checkout 新分支名称

创建并切换到新分支：git checkout -b 新分支名称

切换回 master 分支，进行新分支合并：git merge 新分支名称

注意：使用 git merge 直接合并，并未生成新的提交点，而是指向上一个分支的提交点，也即 Fast-forward。但是经过一系列的测试，新的 Git 版本实现了生成新的提交点。（此处有待进一步的验证，因为当前 Git 版本库仍然有 Fast-forward 说明）

合并分支形成新的提交点：git merge --no-ff -m "注释" 分支名称

推送分支至远程仓库：git push -u origin 分支名称

删除分支：git branch -d 分支名称

强制删除不需要的分支（feature 分支），此时分支有未提交的数据：git branch -D 分支名称

直接删除远程仓库的分支：git push origin --delete 分支名称

已删除本地仓库分支，随后删除远程仓库的对应分支：git push origin :分支名称

问题：master 分支和子分支 sub 分别修改同一个文件 one 文件，各自提交，随后，master 分支再次修改 one 文件，然后合并 sub 分支，one 内容是什么，是否可以合并？

在本地实验的情况下，分支必须提交后才可进行合并

二、bug 分支思想

用户运行 master 分支代码，开发人员当下进行 sub 分支编码。此时，用户运行程序出现异常，需要及时修复，但开发人员又不可丢失当下的编码工作内容。因此，可将当前 sub 分支的工作内容进行暂时挂起，暂时挂起工作区而不是将工作内容添加至暂存库。爲什么要暂时挂起？切换后，会将当下分支的工作区内容影响到其他分支的工作区内容。挂起 sub 分支的工作区后，切换至 master 分支，新建 bug 分支，在 bug 分支上进行代码修改，检测，最后提交，直至 master 分支合并最新修改的代码。

1、暂时挂起当前分支的工作区

git stash

2、切换至 master 分支，并新建分支

git branch master

git checkout -b 新分支名称

3、新建分支下修改信息并提交，切换至 master 分支进行合并

git commit -a -m "注释"

git checkout master

git merge 新分支名称

4、删除新分支

git branch -d 新分支名称

5、切换至之前工作的分支，查看暂时挂起的工作区

git checkout 之前工作的分支名称

git stash list

6、并恢复工作区

恢复工作区有两种方式

第一种

恢复暂时挂起的工作区：git stash apply

清除暂时挂起的工作区：git stash drop

第二种

直接进行恢复并删除暂时挂起的工作区：git stash pop（经过验证，不是最早的一个，则起作用）

注意：若是有多个暂时挂起的工作区，则采用先进后出的原则，恢复信息以最新一次挂起时的内容爲主

三、补丁（重要思想）

对于整体项目的开发而言，由于项目文件的数量和大小非常大，而衹是修改了文件中的一个较小内容，故不需要整体项目或者整个文件提交，衹需要提交变化的内容即可，因此，采用补丁的方式高效快速地传递改变的信息。

以下方式主要表达的是思路，随著 Git 的不断改进，以下方式也在不断变化。

补丁的方式有两种

第一种，各个开发者沟通方便的情况。

1、开发分支上修改提交变更信息

git add .

git commit -m "注释"

2、在开发分支上，将 master 分支与开发分支的不同保存为一个补丁文件

git diff master > patch

3、在 master 分支上应用补丁

git checkout master

git apply patch

4、master 分支提交

git commit -a -m "注释"

第二种，开发者之间沟通不方便，由统一的人员进行 master 分支的管理，故需要传递特定格式的补丁。

1、开发分支上修改提交变更信息

git add .

git commit -m "注释"

2、在开发分支上，打包特定格式的补丁，并远程发送至统一的开发管理者

git format-patch -M master

将生成好的*.patch 文件邮件发送至管理者

3、统一开发管理者接收补丁并认可补丁，随后在 master 分支上应用补丁

git am *.patch

4、master 分支添加提交补丁信息

git add .

git commit -m "注释"

四、多人协作开发

这里介绍下多人协作开发的流程，可做参考。实际开发就是以下流程不断循环使用。

1、开发者 A 创建 sub 分支，修改并提交

git checkout -b sub

git add .

git commit -a -m "注释"

2、开发者 A 推送分支至远程仓库（建立远程连接不在此赘述，可查看之前文章信息）

git push origin master

git push origin sub

3、开发者 B 选择新目录克隆远程仓库分支（克隆结果是衹能克隆 master 分支）

git clone 远程仓库地址

4、开发者 B 创建 sub 分支对应于远程仓库 sub 分支

git checkout -b sub origin/sub

5、开发者 B 抓取远程仓库信息，这里有两种方式

第一种，pull：git pull

第二种，fetch：git branch --set-upstream-to=origin/sub sub

使用--set-upstream 去跟踪远程分支，也就是在建立新的分支推送远程仓库时，需要先校验远程仓库的分支，以免分支冲突。

6、开发者 B 修改提交信息并推送远程仓库

git add .

git commit -a -m "注释"

git push origin sub

7、查看远程分支

git branch -r

8、删除远程分支

git branch -r -d origin/分支名称

git push origin :分支名称

问题

回退到分支当前提交点之前的版本，修改文件信息，是否可以重新提交？

根据 Git 版本控制规则，同一分支上，版本可以进行穿越，但不能跨越版本提交。从版本历史的角度来看，历史是不能被修改的。所以，可以穿越版本，然后，再拉取新分支后，修改文件再提交。