我的笔记

Git 的优点

Git 的优点很多，但是这里只列出我认为非常突出的几点：

• 分布式：所有本地库包含了远程库的所有内容。
• 优秀的分支模型：打分支以及合并分支非常方便。
• 快速：在这个时间就是金钱的时代，Git 由于代码都在本地，打分支和合并分支极其快速，使用过 SVN 的人能深刻体会到这种优势。

感兴趣的，可以去看一下 Git 本身的设计。其内在的架构体现了很多优势，不愧是出自天才程序员 Linus（Linux 之父）之手。

版本管理的挑战

虽然有这么优秀的版本管理工具，但我们面对版本管理时依然有非常大的挑战。大家工作在同一个仓库上，彼此的代码协作必然带来很多问题和挑战，如下：

• 如何开始一个 Feature 的开发，而不影响别的 Feature？
• 由于很容易创建新分支，分支多了如何管理？时间久了，如何知道每个分支是干什么的？
• 哪些分支已经合并回了主干？
• 如何进行 Release 的管理？开始一个 Release 的时候如何冻结 Feature？如何在 Prepare Release 的时候，让开发人员可以继续开发新功能？
• 线上代码出 Bug 了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个 Release？

大部分开发人员现在使用 Git 就只是用三个甚至两个分支：一个是 Master，一个是 Develop，还有一个是基于 Develop 打的各种分支。这在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个 Release。但是人员一多，而且项目周期一长，就会出现各种问题。

Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范。

Vincent Driessen 同学为了解决这个问题，提出了 A Successful Git Branching Model。

Git Flow 常用的分支

Production 分支（主干分支）

也就是我们经常使用的 Master 分支。这个分支包含最近发布到生产环境的代码（最近发布的 Release）。
这个分支只能从其他分支合并，不能直接在此分支修改。

Develop 分支（开发主干）

这个分支是我们的主开发分支，包含所有要发布到下一个 Release 的代码。
主要用于合并其他分支，比如 Feature 分支。

Feature 分支（功能分支）

主要用于开发一个新功能。一旦开发完成，就合并回 Develop 分支，进入下一个 Release。

Release 分支（发布分支）

当你需要发布一个新 Release 时，基于 Develop 分支创建一个 Release 分支。
完成 Release 后，将此分支合并到 Master 和 Develop 分支。

Hotfix 分支（热修复分支）

当在 Production（Master）发现新 Bug 时，需要创建一个 Hotfix 分支。
完成修复后，合并回 Master 和 Develop 分支，因此 Hotfix 的改动会进入下一个 Release。