Git——Git分支管理

1. 分支的增删改查

创建分支

git branch a// 创建分支 a
git checkout a// 切换到分支 a
git checkout -b a// 创建分支 a并切换到该分支上

git checkout develop origin/develop// 如果远程有个分支 develop，而本地没有，你想把远程的 develop 分支迁到本地
git checkout -b develop origin/develop// 同样的，把远程分支迁到本地并切换到该分支

删除分支

① 删除本地分支
git branch -d a
git branch -D a// 强制删除分支

② 删除远程分支
git push origin :develop

查看分支

git branch// 查看本地分支列表
git branch -r// 查看远程分支列表

2. 合并分支并解决冲突

（1）合并分支
将指定分支合并到当前分支

a）merge

$ git merge <branchName>
$ git branch -d a

若另一个分支是当前分支提交节点的祖父节点
那么合并命令什么也不做
若当前分支提交节点是另一个分支的祖父节点
会导致fast-forward合并，只是简单的指针移动，并生成一个新的提交。该模式的本质是，将当前分支的指针直接指向<branchName>分支的最新提交。分支 a 的信息合并到 master 后将该分支删除。

该种方式删除分支后会丢掉分支信息。下图是删除分支后查看到的日志信息，可以看到，没有分支被合并上去的信息。

禁用Fast Forward模式

$ git merge --no-ff -m "merge with no-ff" a

上述指令强制禁用Fast Forward模式，Git 在合并时生成一个新的 commit（所以指令中通过-m添加提交日志），从分支历史上就可以看出分支信息。

其余情况进行一次真正的合并
当 Git 无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

b）rebase

（2）解决冲突
廖老师说人生不如意事十之八九，合并分支也不是一帆风顺。手动解决冲突后再次提交（commit）（fix conflicts and run "git commit"）。

① 手动解决冲突
Git 用<<<<<<、=====、>>>>>标记出不同分支的内容。面对冲突文件，我们很容易可以区分出哪些是我们想要的内容，我们只需保留想要的内容，同时移除<<< HEAD、>>> a这些标记。

② 再次提交

$ git add README.md
$ git commit -m "fixed conflict"

3. 将本地分支与远程分支关联

Git 新建一个分支后必须与远程分支进行关联，关联的目的是如果在本地分支下执行指令： git pull ，git push，只要没有显式指定关联分支就会失败。有以下几种方法关联。

（1）以 clone 的方式创建仓库，master 分支自动对应
当从远程仓库克隆时，Git 自动把本地 master 分支和远程的 master 分支对应起来了，远程仓库的默认名是 origin。

（2）基于远程分支创建本地分支
git checkout develop origin/develop// 如果远程有个分支 develop，而本地没有，你想把远程的 develop 分支迁到本地

git checkout -b develop origin/develop// 同样的，把远程分支迁到本地并切换到该分支

（3）在将本地分支提交到远程仓库时，若远程仓库没有对应分支则创建
git push origin master// 该形式中远程分支名被省略，表示将本地分支推送到与之存在追踪关系的远程分支（通常二者同名），如果该远程分支不存在，则会被创建。

git push -u origin master

（4）手动执行指令将本地分支与远程分支关联
远程仓库有 master和 dev 两个分支，通过 clone 的方式得到本地仓库，发现本地仓库只有一个 master 分支和远程仓库关联。在本地仓库新建一个名为 dev 的分支。使用$ git pull（该形式中省略了远程主机名、本地分支名和远程分支名，表示拉取当前分支对应的唯一一个的远程分支的内容），出现下图中提示，说明本地分支和远程分支没有关联起来。使用$ git push（该形式中省略了远程主机名、本地分支名和远程分支名，表示将修改推送到当前分支对应的唯一一个的远程分支上），出现下图中提示。

git pull

git push

所以为了解决上述问题，需要手动将本地分支和远程分支关联起来。

$ git branch --set-upstream-to <远程分支> <本地分支>

$ git branch --set-upstream-to origin/dev dev

关联结果

4. 团队协作流程 Git Flow

（1）相关概念
Git Flow 是一种成熟的分支管理流程，定义了多人协作下的分支管理规范。

Git Flow 中涉及到的分支

master（记录发布历史）

保存官方的发布历史，使用标签为 master 上发布的版本打标签（tag）。永远处在即将发布状态（production-ready）

develop（集成各种功能开发）
feature（功能开发）

每一个新功能的开发，都应各自使用独立的分支，该分支基于 develop，功能完成后 merge 回 develop。功能开发永远不应该直接牵扯到 master。

release（用于进行发布前的准备）

一旦 develop 积攒了足够多的新功能（或者预定的发布日期到了），可以基于 develop 建立一个用于产品发布的分支。该分支的创建意味着一个发布周期的开始，也意味着本次发布不会再增加功能——在这个分支上只能修改 bug，做一些文档工作或和发布相关的任务。一切准备就绪后，该分支合并到 master，并用版本号打上标签。

发布分支上的改动还应合并到 develop 分支，因为在发布周期内，develop分支仍在被使用，release 版本中修复的 bug 应同步到 develop 分支。

该分支基于 develop，功能完成后 merge 回 master 和 develop。

hotfix（用于维护的分支）

发布后的维护工作或紧急修复工作需要使用一个独立的分支。这是唯一可以直接基于 master 创建的分支。一旦问题被修复了，所有的改动应并入 master 和 develop 分支。并使用新的版本号为 master 分支上的提交打上标签。

该分支基于 master ，功能完成后 merge 回 master 和 develop。

（2）使用

① 创建 develop 分支
首先给默认的 master 分支配备一个 develop 分支。简单的做法是，在本地仓库创建一个空的 develop 分支，然后把它推动到中央仓库。这样服务器上的中央仓库中有 master 和 develop 两个分支。

$ git branch develop 
$ git push -u origin develop

② 在功能分支上开发功能
小明和小红分别开发功能 A 和 B。以小明为例，他首先需要克隆中央仓库，但由于本地仓库只有一个 master 分支，需要在本地仓库创建 develop 的追踪分支。然后在 develop 分支的基础上创建功能分支 feature/A，然后在功能分支上开发功能。

$ git clone git@github.com:SiXiWanZi/SSHTest.git
$ git checkout -b develop origin/develop // 基于远程仓库 origin 上的 develop 分支在本地创建 develop 分支
$ git checkout -b feature/A develop // 基于 develop分支创建 feature/A 分支

小明将相关代码使用 Git三部曲提交到 feature/A 分支上。

$ git status
$ git add 
$ git commit

经过几次修改，小明觉得他的功能完成了，那么将该分支合并到 develop 上，然后删除该分支。

$ git pull origin develop？？
$ git checkout develop
$ git merge feature/A
$ git branch -d feature/A

③ 进行发布前的准备工作
功能开发完成后进入发布阶段，使用一个新的分支进行产品发布的准备工作，包括测试、文档的更新及其他准备工作。一旦创建了这个分支，并把它推送到中央仓库，这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。

$ git checkout -b release/1.0 develop

一些准备就绪后，将发布分支上的修改并入到 master（开发准备工作做完后，将其并入 master 进行正式发布）和 develop（因为修复的 bug 对于正在进行的功能开发是有用的）。

$ git pull origin master
$ git checkout master
$ git master release/1.0
$ git push origin master

$ git pull origin develop
$ git checkout develop
$ git master release/1.0
$ git push origin develop

合并后删除分支。

$ git branch -d release/1.0

④ 正式发布版本
无论什么时候，把一些东西并入 master，都应该随即打上合适的标签。

$ git tag -a 1.0 -m "initial public release" master???
$ git push --tags???

⑤ 发现正式发布版本中的 bug，需紧急修复
为了修复这个 bug，小明基于 master 创建了一个分支 hotfix/C，在该分支上修复 bug 后，把改动合并到 develop 和 master。

$ git pull origin master
$ git checkout master
$ git master hotfix/C
$ git push origin master

$ git pull origin develop
$ git checkout develop
$ git master hotfix/C
$ git push origin develop

合并后，将修复分支删除。

$ git branch -d hotfix/C