分类： Git

当前git是大部分开发团队的首选版本管理工具，一个好的流程规范可以让大家有效地合作，像流水线一样有条不紊地进行团队协作。

业界包含三种flow：

• Git flow
• Github flow
• Gitlab flow

继续阅读Gitlab Flow实践

git-flow 的工作流程

当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在你的团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。

基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。

在这章节中我们将一起学习一个当前非常流行的工作流程 git-flow。

什么是 git-flow？

一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！

git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。

安装 git-flow

最新的git bash已经支持，不用安装，或者使用 Sourcetree。

要了解安装 git-flow 细节，请阅读下面这个文档 official documentation。

在项目中设置 git-flow

当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。

话虽如此，git-flow 却存在一些限制。让我们开始在一个新的项目上初始化它吧，之后我们就会有所发现：

当在项目的根目录执行 “git flow init” 命令时（它是否已经包括了一个 Git 仓库并不重要），一个交互式安装助手将引导您完成这个初始化操作。听起来是不是有点炫，但实际上它只是在你的分支上配置了一些命名规则。
尽管如此，这个安装助手还是允许你使用自己喜欢的名字。我强烈建议你使用默认的命名机制，并且一步一步地确定下去。

分支的模式

git-flow 模式会预设两个主分支在仓库中：

• master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
• develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。

让我们开始探索一些在现实应用中可能遇到的案例吧！

功能开发

对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。

开始新功能

让我们开始开发一个新功能 “rss-feed”：

概念

在这些命令的输出文本中，git-flow 会对刚刚完成的操作打印出一个很有帮助的概述
当你需要帮助的时候，你可以随时请求帮助。例如：

$ git flow feature help

1	$ git flow feature help

正如上面这个新功能一样，git-flow 会创建一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。

完成一个功能

经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：

最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：

1. 一个在更广泛的 “开发” 背景下的全面测试。
2. 稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。

之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。

管理 releases

Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。

创建 release

当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：

请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当我们完成了release 后，git-flow 会适当地自动去标记那些 release 提交。

有了一个 release 分支，再完成针对 release 版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑。

完成 release

现在是时候按下那个危险的红色按钮来完成我们的release了：

这个命令会完成如下一系列的操作：

1. 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
2. 然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
3. 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
4. 清理操作，版本分支会被删除，并且回到 “develop”。

从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。

hotfix

很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。

创建 Hotfixes

这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。

就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！

完成 Hotfixes

在把我们的修复提交到 hotfix 分支之后，就该去完成它了：

这个过程非常类似于发布一个 release 版本：

• 完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
• 这个 hotfix 程序将被标记起来以便于参考。
• 这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。

还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。

回顾一下

最后，在结束这个章节之前，我要再次强调几个重点。

首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。

其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。

记住，使用 git-flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。

上面的工作流程不涉及到代码评审过程，开发人员开发完就可以合并分支。但是如果合并分支之前需要进行代码评审，那么整个流程就变复杂，我们下面分析增加了代码评审情况下的工作流。

代码评审下的 git-flow 的工作流程

我们使用 Git Flow 来进行版本管理控制，它相对于 GitHub Flow 更适合在产品开发中快速迭代，这种代码管理模式应该已经广泛使用了。

另外，我们鼓励使用 Git 客户端 SourceTree，它集成了 Git Flow 的一些基本操作。如果严格遵循 Git Flow 的流程进行版本管理控制，那么我们只用管开始和结束一个 Feature/Release/Hotfix，基本上是不用手动 merge 分支的。

新功能开发流程

1. 从 develop 分支创建 feature 分支；
2. 开发调试完将 feature 分支提交到远程版本库；
3. 提交 pull request 请求合并到 develop 分支；
4. 相关负责人 code review 后如果同意合并后，删除远程 feature 分支，如果不同意，重新修改后再上传 feature 分支请求 pull request。

Pull Request

Pull Request是当功能开发者完成一个新功能后向项目维护者发送合并请求通知的机制。它的使用过程如下：

1. 功能开发者可以通过Gitlab页面发送pull request
2. 开发管理员自己或组织其他的团队成员审查、讨论和修改代码
3. 开发管理员合并新增功能分支到develop分支，然后关闭pull request，并且可以选择删除新增分支

工作流程

1. 由开发管理员负责在Gitlab上创建空白的仓库，并clone到本地，在sourcetree的git flow菜单中选择初始化仓库，并push到远端。

2. 在Gitlab上设置保护分支，把master、develop分支保护起来，只有指定人可push。

3. 功能开发者clone代码到本地，先在sourcetree的git flow菜单中选择初始化仓库。

4. 然后再开始新建功能分支，进行开发工作。

5. 新功能开发全部完成或部分完成后，功能开发者把最新代码push到远端同样的新功能分支里，并在Gitflow发起pull request给开发管理员

6. 开发管理员review代码，选择合并代码到develop，并可选择删除已经合并的新功能分支

7. 当开发管理员处理完合并请求后，开发者,切换到develop分支，直接删除自己的本地分支及远程分支，不要点击完成(Finish Feature)，此时开发者pull远端develop分支最新代码即可，可忽视本地的push提醒。

8. release、hotfix分支和feature分支操作类似。

9. 不可点击完成新功能、完成发布版本、完成修复补丁，因为这样会导致自动合并代码到master或develop分支

Git Flow Release

到此为止，我们发现整个的工作流还算可以接受，但是执行 git flow release 的时候，会发现由于 Git Flow 总是假定我们合并的分支可以立即部署到生产环境，所以如果我们的工作流程符合这个过程，是很简单的。

但是更多的时候，我们会遇到同时开发可功能模块A、B、C，最终上线只上线A、C的情况，这种情况下，会涉及到版本会退的问题，这个时候 git flow 反倒是不方便使用了。

这种情况下，GitLab Flow 流程可能更适合我们的工作流程。

参考链接

---

• git-flow 的工作流程
• Git Flow详细介绍和使用
• 如何看待 Git flow 发明人称其不适用于持续交付？
• 真正的敏捷工作流 —— GitHub flow
• 一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流
• 别再推荐 Git Flow 了
• A successful Git branching model
• 这才是真正的 Git——分支合并
• GitFlow+Gitlab工作流及Git规范
• git 在命令行提交merge request
•  git-flow
• 一个可以提高开发效率的命令：cherry-pick
• Git cherry-pick 这个命令你会经常用到！
• Git Flow与Gitlab Flow两种工作流中，release分支的不同作用
• [译] GitLab Flow简介
• 一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流
• 基于 Git 的分支策略，你值得一看！
• Git分支管理最佳实践

问题

创建的 .gitignore 文件无法提交到 git 上

场景

在log路径下创建了.gitignore文件, 文件内容:

想着忽略当前文件夹的所有内容. 此时想将 .gitignore文件提交上去, 运行git status 发现没有.gitignore文件的变动.

于是想着可能没反应过来, 就直接提交吧, 运行命令: git add .gitignore, 提示信息如下:

解决

如此看来, 是我将这个文件忽略了, 运行命令检查是那里将其忽略了git check-ignore -v .gitignore. 输出结果:

表明, 是在.gitignore文件的第一行, 规则* 忽略了此文件.

吆西, 明白了, 解决方法也简单, 修改.gitignore文件内容, 将此文件排除即可, 修改后的内容:

此时就可以正常提交。

参考链接

---

.gitignore 文件无法提交

钩子文件在项目目录下

git 的钩子放在 git 项目下的 .git/hooks 目录。

如果我们所有项目都需要一个通用的钩子，那么我们需要在所有的项目中都放置钩子文件。挨个复制显然不是一个可行的方案。

模板目录

我们可用模板目录来解决这个问题。

在 git init 或者 git clone时，如果指定有模板目录，会使用拷贝模板目录下的文件到 .git/ 目录下。

好了，那么解决方案就是：把统一的钩子文件放到模板目录，然后在 git init / git clone 时候指定模板目录？

不行，这样还是太麻烦了。

模板目录写入全局配置

模板目录固定在一个地方，我们可以把模板目录写入全局配置。

在 git init 或者 git clone 时，会自动拷贝钩子文件到项目的钩子目录。 已有项目，执行 git init 重新初始化项目即可。

代码提交时候，自动格式化的参考代码如下：

使用的时候，简单的拷贝到.git/hooks 目录下，并重新命名为pre-commit。然后执行:

这样，每次提交代码的时候，都会自动格式化代码了。

参考链接

---

• andrewseidl/githook-clang-format
• wangqiang1588/githook-clang-format
• In a git hook is the current working directory guaranteed to be within the git repository?
• How do I specify a clang-format file?
• git 全局钩子
• Git Hooks

Git 钩子

和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。 有两组这样的钩子：客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。

安装一个钩子

钩子都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的 .git/hooks 。 当你用 git init 初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。这些脚本除了本身可以被调用外，它们还透露了被触发时所传入的参数。 所有的示例都是 shell 脚本，其中一些还混杂了 Perl 代码，不过，任何正确命名的可执行脚本都可以正常使用 —— 你可以用 Ruby 或 Python，或其它语言编写它们。 这些示例的名字都是以 .sample 结尾，如果你想启用它们，得先移除这个后缀。

把一个正确命名且可执行的文件放入 Git 目录下的 hooks 子目录中，即可激活该钩子脚本。 这样一来，它就能被 Git 调用。 接下来，我们会讲解常用的钩子脚本类型。

客户端钩子

客户端钩子分为很多种。 下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。

Note	需要注意的是，克隆某个版本库时，它的客户端钩子 并不 随同复制。 如果需要靠这些脚本来强制维持某种策略，建议你在服务器端实现这一功能。（请参照 使用强制策略的一个例子 中的例子。）

提交工作流钩子

前四个钩子涉及提交的过程。

pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。

prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。

commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。 在本章的最后一节，我们将展示如何使用该钩子来核对提交信息是否遵循指定的模板。

post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。

电子邮件工作流钩子

你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。

第一个运行的钩子是 applypatch-msg 。 它接收单个参数：包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。

下一个在 git am 运行期间被调用的是 pre-applypatch 。 有些难以理解的是，它正好运行于应用补丁 之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。

post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。

其它客户端钩子

pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase 钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程不匹配。

post-rewrite 钩子被那些会替换提交记录的命令调用，比如 git commit --amend 和 git rebase（不过不包括 git filter-branch）。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。

在 git checkout 成功运行后，post-checkout 钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。

在 git merge 成功运行后，post-merge 钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。

pre-push 钩子会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更新操作（一个非零的退出码将终止推送过程）。

Git 的一些日常操作在运行时，偶尔会调用 git gc --auto 进行垃圾回收。 pre-auto-gc 钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。

服务器端钩子

除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。

pre-receive

处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。

update

update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。

post-receive

post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器，或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态，所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。

参考链接

---

• 8.3 自定义 Git - Git 钩子
• 5.4 Git 钩子：自定义你的工作流
• 使用git钩子对提交代码进行检查(pre-commit)
• Git Hooks