图文讲解，团队开发中的 Git 最佳实践

公众号发现了一篇很是好的有关Git的实践文章，特意转载过来，很是感谢做者 芋道源码 分享的宝贵经验。

在 2005 年的某一天，Linux 之父 Linus Torvalds 发布了他的又一个里程碑做品——Git。它的出现改变了软件开发流程，大大地提升了开发流畅度！直到如今仍十分流行，彻底没有衰退的迹象。

本文不是一篇 Git 入门教程，这样的文章一搜一大把，我是要从具体实践角度，尤为是在团队协做中，阐述如何去好好地应用 Git。既然是讲在团队中的应用实践，我就尽量地结合实际场景来说述。

1、习惯养成

若是一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范当然重要，但更重要的是我的素质，在使用 Git 时须要本身养成良好的习惯。

提交

如何去写一个提交信息，《Git: 教你如何在Commit时有话可说》中作了很好的说明。在具体开发工做中主要须要遵照的原则就是「使每次提交都有质量」，只要坚持作到如下几点就 OK 了：

• 一、提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操做时可以将「误伤」减到最低；
• 二、用一句简练的话写在第一行，而后空一行稍微详细阐述该提交所增长或修改的地方；
• 三、不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样能够避免在进行一次提交后发现代码中还有小错误。

假如已经把代码提交了，对此次提交的内容进行检查时发现里面有个变量单词拼错了或者其余失误，只要尚未推送到远程，就有一个不被他人发觉你的疏忽的补救方法——

首先，把失误修正以后提交，能够用与上次提交一样的信息。

而后，终端中执行命令 git rebase -i [SHA]，其中 SHA 是上一次提交以前的那次提交的，在这里是 3b22372。

最后，这样就将两次提交的节点合并成一个，甚至可以修改提交信息！

谁说历史不可篡改了？前提是，想要合并的那几回提交尚未推送到远程！

推送

当本身一我的进行开发时，在功能完成以前不要急着建立远程分支。

拉取

请读张文钿所写的《使用 git rebase 避免無謂的 merge》。

合并

在将其余分支的代码合并到当前分支时，若是那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，能够考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。

2、分支管理

Git 的一大特色就是能够建立不少分支并行开发。正由于它的灵活性，团队中若是没有一个成熟的分支模型的话，那将会是一团糟。

要是谁真把这么乱的提交图表摆在我面前，就给他一个上勾拳！

分支模型

有个很成熟的叫「Git Flow」的分支模型，它可以应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。

须要注意的是，它只是一个模型，而不是一个工具；你能够用工具去应用这个模型，也能够用最朴实的命令行。因此，重要的是理解概念，不要执着于实行的手段。

简单说来，Git Flow 就是给本来普普统统的分支赋予了不一样的「职责」：

• master——最为稳定功能最为完整的随时可发布的代码；
• hotfix——修复线上代码的 bug；
• develop——永远是功能最新最全的分支；
• feature——某个功能点正在开发阶段；
• release——发布按期要上线的功能。

看到上面的「master」和「develop」加粗了吧？表明它们是「主要分支」，其余的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每一个类型能够同时存在多个。各种型分支之间的关系用一张图来体现就是：

更多信息可参考 xirong 所整理的《Git工做流指南》。

工具选择

一直不喜欢「＊＊最好用」这种命题，主观性太强，不会有一个结论。对于工具的选择，我一直都是秉承「哪一个能更好地解决问题就用哪一个」这个原则。因此，只要不影响到团队，用什么工具都是能够接受的。但根据多数开发人员的素质状况来看，建议使用图形化工具，例如 SourceTree。若是想用命令行，能够啊！先在内心问下本身：「我 Git 牛逼不？会不会惹麻烦给别人？」

在团队中应用 Git Flow 时，推荐使用 SourceTree 与 GitLab 配合的形式：

• 一、用 SourceTree 建立 feature 等分支以及本地的分支合并、删除；
• 二、用 GitLab 作代码审核和远程的分支合并、删除。

SourceTree 和 GitLab 应该是相辅相成的存在，而不是互相取代。

3、事前准备

为了将一些规范性的东西和 Git Flow 的部分操做自动化处理，要对 SourceTree 和 GitLab 进行一下配置。

SourceTree

按下 command + , 调出「Preferences」界面并切换到「Git」标签，勾选「Use rebase instead of merge by default for tracked branches」和「Do not fast-forward when merging, always create commit」。

这样设置以后，在点「Pull」按钮拉取代码时会自动执行 git pull --rebase；而且，每次合并时会自动建立新的包含分支信息的提交节点。

接下来，点击工具栏中的「Git Flow」按钮将相关的流程自动化。若是没有特殊需求，直接按下对话框中的「OK」就行了。初始化完成后会自动切换到 develop 分支。

这下再点「Git Flow」按钮所弹出的对话框就是选择建立分支类型的了。

GitLab

在建立项目仓库后必定要把主要分支，也就是 master 和 develop 给保护起来。为它们设置权限，只有项目负责人能够进行推送和删除等操做。

被保护的分支在列表中会有特殊的标记进行区分。

4、开发流程

在引入 Git Flow 以后，全部工做都要围绕着它来展开，将本来的流程与之结合造成「基于 Git Flow 的开发流程」。

开发功能

在肯定发布日期以后，将须要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具建立一个对应的 feature 分支。若是是多人配合的话，建立分支并作一些初始化工做以后就推送建立远程分支；不然，直到功能开发完毕要合并进 develop 前，不要建立远程分支。

功能开发完并自测以后，先切换到 develop 分支将最新的代码拉取下来，再切换回本身负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」，若是有冲突则本身和配合的人一块儿解决。

而后，到 GitLab 上的项目首页建立合并请求（merge request）。

「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮，在出现的表单中将处理人指派为项目负责人。

项目负责人在收到合并请求时，应该先作下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。

在将某次发布的所需功能所有开发完成时，就能够交付测试了。

测试功能

负责测试的人建立一个 release 分支部署到测试环境进行测试；若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支建立一个分支进行修复。

发布上线

当确保某次发布的功能能够发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，而后打包发布到线上环境。

建议打 tag 时在信息中详细描述此次发布的内容，如：添加了哪些功能，修复了什么问题。

修复问题

当发现线上环境的代码有小问题或者作些文案修改时，相关开发人员就在本地建立 hotfix 分支进行修改，具体操做参考「开发功能」。

若是是至关严重的问题，可能就得回滚到上一个 tag 的版本了。

5、额外说明

这里所提到的事情，虽非必需，但知道以后却会如虎添翼。

分支命名

除了主要分支的名字是固定的以外，派生分支是须要本身命名的，这里就要有个命名规范了。强烈推荐用以下形式：

• feature——按照功能点（而不是需求）命名；
• release——用发布时间命名，能够加上适当的前缀；
• hotfix——GitLab 的 issue 编号或 bug 性质等。

另外还有 tag，用语义化的版本号命名。

发布日期

发布频率是影响开发人员与测试人员的新陈代谢和心情的重要因素之一，频繁无规律的发布会致使内分泌失调、情绪暴躁，导致爆粗口、砸电脑等情况出现。因此，确保一个固定的发布周期相当重要！

在有一波或几波需求来临之时，想挡掉是不太可能的，但能够在评审时将它（们）分期，在某个发布日以前只作一部分。这是必需要控制住的！否则任由着需求方说「这个今天必定要上」「那个明天急着用」的话，技术人员就等着进医院吧！

---

特此注明：
本文为转载 芋道源码公众号文章，原文地址：图文讲解，团队开发中的 Git 最佳实践