说说git（二）

上篇文章《说说git（一）》简要的介绍了git的基本信息及要点，本篇主要说下git的工作流，git工作流是git仓库的流程管理规范，它是项目协作的基础，如果对它不了解，在需要多人共同完成的项目中，还是会捉襟见肘，相反，如果能够在项目中实践git工作流，会让你有条不紊，事半功倍。

一般小团队对代码管理的重视程度不是很高，谈到用git管理项目，他们往往只会停留在工具层面上，例如用SourceTree这样的界面来下载、更新和上传代码，并没有指定可持续发展的流程，这样实际上带来的问题很明显，就是维护代码的成本会比较高。

例如我曾经接手过一个这样的项目，由于没有很好的流程规范，以至于生产环境上的程序产生了bug，竟然不知道这个程序对应于代码仓库上的哪一次提交，进而在排查问题前，需要通过对比程序的部署日期和提交日期来确定，如果这一天有多次提交，还要先编译不同的提交，并核实MD5值来确定，这种开发效率实在是低得可以。

制定git工作流的目的也是为了提高效率，使代码仓库的管理简洁明了，让开发者专注于业务的开发上，经过一段时间的实践，我主要采用的是gitlab工作流来管理项目，下面分2点介绍一下：

1. gitlab工作流
2. bugfix如何处理

gitlab工作流

gitlab是一个非常优秀的开源软件，对github比较了解的同学都知道，gitlab实际上是私有版的github，gitlab的工作流是建立在分支的基础上的，在服务器开发的场景下，我们一般需要额外建立2个分支：pre-production分支和production分支，pre-production分支是预发布环境，主要用来模拟生产环境的测试，而production环境则是生产环境

image.png

有了这两个分支，就可以制定提交的流程了，团队里的每个人都按照这样的流程来维护代码，就不会出现混乱、难以管理等问题

1. 创建一个issue，同时在issue页面拉出一个分支
   在上一篇里我说过，由于git的分支非常轻量，所以每个改动都可以新建一个分支，修改完成后再合并到主分支中去，那issue是什么呢，issue是这次修改的详细描述，例如描述这次修改是一个新的功能，还是一个bug修复，这次修改的目的是什么，如何完成这次修改。同时它可以关联一个分支，最终这个分支的提交、合并等整个过程都可以由这个issue来追踪。
   创建issue
   在issue下创建分支
   分支创建好后，可以在终端执行git fetch origin master把新创建的分支拉到本地，这样就可以在本地通过新的分支开发新功能了。

这里需要注意的是，一个issue的开发周期不宜过长，最好控制在1天，否则跨了多天的提交，最后合并起来会带来很大的麻烦。

2. 提交代码
   开发完成后，就可以把代码提交到对应的远程分支上了，如果你设置了gitlab CI，提交后还会触发对代码的编译、测试等步骤，这取决于你的CI的具体设置，目的也是为了保证你的提交质量。关于CI，这里就不多讲了，有机会我再写一篇相关的文章。
3. code review
   提交代码后，我们需要让团队里的其他小伙伴对代码进行review，code review的好处很多，除了可以帮助统一团队的编码格式之外，还可以帮助检查一些显而易见的错误，最大的好处是提升了团队对业务的理解水平，而不是各自负责一个模块，形成了孤岛。gitlab提供了很好的code review功能，它不仅会对代码修改点进行区别的显示，同时还可以在代码上进行注释，这些注释，开发者需要逐个solve掉，否则被认为是不能合并到主分支上。
4. 合并代码
   通过了层层的审核，最后终于可以合并到主分支上了，当然这一步可以和第3步一起完成，即先创建Merge Request，然后项目管理者在合并代码前，先进行code review，通过后再允许合并到主分支上。

以上便是日常开发代码的基本流程，可以涵盖了开发工作中涉及git操作的80%的内容，剩下20%在哪里？你就要了解后面的内容了

bugfix如何处理

bugfix主要是修复生产环境中发现的bug，找到解决思路后，我们一般需要以下步骤去完成这个任务：

1. 找到生产环境上对应的具体commit_id
2. 创建bugfix类型的issue和分支，并回退到第1步的那个commit
3. 修改代码，打补丁
4. 测试
5. 将补丁合并到master分支上
6. 用修改后的程序替换掉生产环境上的程序

以上步骤中，如果没有很好的工作流，第1步和第6步是比较难操作的，第1步上文已经说过了，第6步为什么难操作呢，因为它需要手动将修改后的代码与master分支的代码对比后，合并到master上，为什么要手动呢，因为git是不允许从一个旧的提交向较新的提交上合并的，你可能会问：能不能不这么原始呢，因为手动对比真的是很费时。答案是有的，有个概念叫cherry-pick，可以完成这样的功能，但问题就在这里了，这个概念大多数人平时是没有接触过的，而且即便看过书，也很难理解它到底有什么用，即把它应用到工作中的概率极低。

使用gitlab工作流后，可以很好的改善以上的窘境，因为每次你合并代码，都会有个大大的cherry-pick按钮弹出来，好奇心的驱使，会让你迟早知道这功能是怎么回事儿。说了不少废话，下面说下gitlab工作流怎么完成bugfix的流程。

还记得之前我们创建的3个分支吗，其中production分支里的所有提交，都对应于生产环境中的一个版本，那么以上的第1步就很好解决了，很快便可以找到生产环境上的版本对应的那个commit_id。下面还需要修改下第5步的内容：

5. 将代码合并到production分支，合并完成后，cherry-pick到master分支上

下面三个截图是整个合并过程

打补丁，合并到production分支（截图是release分支，是一回事），注意这里不要勾选Remove source branch选项，勾选了就无法进行cherry-pick了

合并到production分支

合并成功会弹出Cherry-pick对话框

将补丁Cherry-pick到master分支上

以上便是开发工作中，几乎可以全部覆盖的涉及到git的工作流程，遵守这一套流程，可以让我们的开发协作更为高效，下一篇，我会介绍一下CI和git如何结合，及如何进行开发过程中的版本管理。