Git简介及工作流

Git 对版本是分布式管理，因此有四个保存数据的区域，如下图中浅绿色的部分，分别是本地工作区 Workspace、本地暂存区 Stage、本地仓库和远程仓库。

开发时先从远程拉取代码到工作区，可以有 clone、pull、fetch+checkout 几种方式，如图中向左的几个箭头所示。在提交代码时，先通过 add 命令添加到暂存区，然后 commit 提交到本地仓库，最后使用 push 推送到远程仓库。如图中向右的几个箭头所示。

稍微注意一下 fetch 与 pull 的区别。

fetch 是从远程仓库同步到本地仓库，但并不会合并到工作区。

pull 相当于执行 fetch 命令+merge 命令，先同步到本地仓库，然后在 merge 到工作区。

Git 的命令行提示非常友好，对常用 Git 操作的说明非常完善，其他的命令不展开介绍。

Git 常用工作流

使用 Git 进行团队协作开发时，多人协作、多分支开发是很常见的。为了更好得管理代码，需要制定一个工作流程，这就是我们说的工作流，也可以叫分支管理策略。常见的基于 Git 的工作流有 Git-flow工作流、GitHub 工作流和 GitLab 工作流，如下图所示。

Git-Flow 工作流

如上图左侧所示，Git-Flow 按功能来说，分为 5 条分支，在图中以不同颜色表示，其中 master 和 develop 是长期分支。master 分支上的代码都是版本发布状态；develop 分支则代表最新的开发进度。

当需要开发某些功能时，就从 develop 拉出 feature 分支进行开发，开发完成并验证后就可以合并回 develop 分支。当 develop 上的代码达到一个稳定的状态，可以发布版本的时候，会从 develop 合并到 release 分支进行发布，如果验证有问题就在 release 分支进行修复，修复验证通过后进行正式发布，然后合并到 master 分支和 develop 分支。还有一个 hotfix 分支用来做线上的紧急 bug 修复，hotfix 直接从 master 拉出分支修改，修改验证完成后直接合并回 master，并同步到 develop 分支。

Git-Flow 流程非常完善，但对于很多开发人员和团队来说，会稍微有些复杂，而且没有图形页面。

GitHub 工作流

现在来看另一种更简单的工作流，如上图所示，中间的 GitHub 工作流。

GitHub 工作流只有一个长期分支 master，而且 master 分支的代码永远是可发布状态。如果有新功能开发，可以从 master 分支上检出新分支，开发完成需要合并时，创建一个合并到 master 到 PR，也就是 pull request。当 review 通过或者验证通过后，代码合并到 master 分支。GitHub 工作流中 hotfix 热修复的流程和 feature 分支完全一

GitLab 工作流

如上图所示，看右面的 GitLab 工作流。前两种工作流各有优缺点，Git-Flow 稍微复杂，GitHub 的单一主分支有时会略显不足。GitLab 结合了两者的优势，既支持 Git-Flow 的多分支策略，也有 GitHub Flow 的一些机制，比如 Merge Request和 issue 跟踪。GitLab工作流使用 pre-production 分支来进行预发管理，使用 prodution 分支来发布版本。我的团队目前使用的就是 GitLab 工作流。