说说git（三）

git是一个实用的工具，在工作中，用得好，它能极大的提升你的工作效率；但用不好，它同样会给你带来麻烦，这一点我们在上一篇中有过详细的描述。除了使用的规范性（git工作流）以外，在这一篇里，我会继续延伸我对git的理解，希望能够进一步打开你的脑洞，让你和它之间的距离更近。

在互联网公司，我认为git就是产品的中心，经验证明，所有脱离git而独立存在的协同软件都是难以维护的，例如我以前就用trello或禅道在公司里推广敏捷开发模式，用它们建立项目、拆分需求、分配任务，并专门给团队进行培训这些工具的使用方法。但最终都以失败告终，具体原因是开发者总是忘了去这些协同软件上修改状态，每次都需要我来提醒，久而久之，就造成了协同软件上的项目进度和实际进度不一致的情况，最后只好放弃使用。

深入追究这些工具不能持之以恒的原因，可能是因为这些办公软件并没有帮助大家提升工作效率，反而却增加了工作量，本来一次提交就意味着完成了任务，现在还要多出一步去打开一个页面，并修改其中的状态。

程序员都是很懒的。

所以理想的程序员会说，如果我提交一次，就完成了任务状态的修改，那该多好，如果这样，根本就不存在额外的推广其他项目管理软件的必要嘛。当想到这一点的时候，我突然明白了这不就是程序员必须具有的思维吗，原来自己很长时间还没有掌握这种思维。

最终，在近一年的工作中，我用这种方法逐渐的改善了以往的工作模式，即

能一步操作的事情，不要变成两步来完成。

换句话说，既然git是程序员工作中的“必经之路”，那git一定就是连接其他一切的桥梁，我想，这应该也就是为什么有持续集成（continuous integration）这个概念的原因吧。具体一点，也就是利用git hooks的功能，在进行git操作后，执行一系列的事件，例如调用Trello的接口，修改任务的状态为已完成或已解决，这样做的好处也非常美好——它可以把一次提交和一个任务紧紧的联系在一起，而不会出现提交了很多次之后，都不知道哪一次提交修改了哪些代码的情况。

当然，如果你使用gitlab或github，上面说的把任务和编码关联在一起的功能，已经是这些软件自带的了，所以，我们现在使用gitlab，在gitlab上建立任务（issue）、开分支、编码、提交、合并，完成后，任务会自动关闭掉，这个流程没有任何一个多余的动作，也是理想的程序员希望达到的工作流程，详细细节可以阅读上一篇文章。

同样的原理，我们可以在一次提交后做更多的事情，例如完成持续集成的几个基本的步骤：

1. 编译
2. 测试
3. 打包
4. 发布

实现方式同样也是实现一个git hooks，当然这个世界上的很多轮子已经造好了，例如gitlab CI、Jenkins就是这样的轮子，我们直接使用就行，如果理解了原理，肯定会更加得心应手。

下面是我编写的一段go语言环境的gitlab CI脚本，通过它，你就可以一键完成项目的编译、测试、打包这些过程了

# .gitlab-ci.yml
before_script:
  - PRJ_NAME=my_project
  - PRJ=$GOPATH/src/$PRJ_NAME
  - rm -f $PRJ
  - ln -s $CI_PROJECT_DIR $PRJ
  - PATH=$PATH:$GOROOT/bin:$GOPATH/bin
  
stages:
  - build
  - release
  - test
  
build:
  stage: build
  tags:
    - golang
  script:
    - cd $PRJ
    - make release
  except:
    - tags

release:
  stage: release
  artifacts:
    name: "${PRJ_NAME}_${CI_COMMIT_REF_NAME}"
    paths: 
    - build/
  script:
    - cd $PRJ
    - git submodule init
    - git submodule update
    - make release
  tags:
    - golang
  only:
    - tags   

test:
  stage: test
  tags:
    - golang
  script:
    - cd $PRJ
    - make test
  except:
    - tags

以上代码中，before_script是初始化go的环境，stages告诉CI程序，要执行以下3个步骤：

1. build——编译
2. release——打包
3. test——测试

后续的以build、release、test开头的代码段，便是具体的这些步骤所需执行的代码，可以看到这几个步骤所执行的核心脚本是调用Makefile，执行make release和make test，最大的区别是，release只有在打tag的时候才执行，而其他两项是在不打tag的时候执行的。

也就是说，这个CI脚本完成了2个功能：

1. 在日常提交时，gitlab会对代码进行编译和测试，确保该提交是通过了编译和测试两个环节的。
2. 在发版前，项目经理会在production分支上打一个tag，这个动作会触发release环节的执行，会把build目录下的文件打包成一个带有版本号的压缩包，同时产生一个可下载的http链接，这样做的好处也非常明显，在服务器开发中，我觉得最大的好处是把开发和运维解耦了，这两个部门间再也不会扯皮了。

通过这三篇文章，你应该对git由浅入深的有了一些认识，可以看到git对团队协作、团队成员间工作的透明性的威力很大，减少了噪音的同时，让团队更专注于核心的代码层面上，这也是git的作者Linus所提倡的：

Talk is cheap, read the f**king code.