团队Git工作流总结

Posted 2020-06-17

为什么使用Git

“svn用了这么多年都好好的，为啥折腾搞Git？”

“Git一点都不好用，提交个代码都提交不上去！”

“Git这么复杂，命令多到记不住，而且完全用不到。哪有svn简单好用？”

 

推销任何一种新事物，无论新事物本身是否先进，最能打动客户的一点就是，能否解决客户的痛点，能否给客户带来价值。

拿软件开发过程来说，项目团队关注项目版本的可控性，包括对多个版本的开发、构建、测试、发布、特性等管理；关注持续集成的效率等；开发团队关注代码管理、回溯、合并的可控性；关注开发协同等；

在svn（目前在用的版本管理工具）的上述痛点，Git都能很大的解决或改善。推广Git，背后的目的就是提高项目产品的质量和团队开发的效率。当然，任何收益都有代价，在支持如此多的特性的同时，Git的使用复杂度也势必增加。

本文侧重讨论Git在团队的推广，所以首先回答一下，相较于svn，Git给开发中个人和开发团队带来的价值：

• 对于开发者，可以随时提交修改到本地仓库，方便代码修改查看，回滚，终结svn时代开发阶段无代码管理工具、代码管理混乱的窘境，提高个人代码管理效率。
• 如果一个功能需要尝试多种方案进行对比，开发者可以通过本地分支对多个方案代码进行修改、对比、查看等管理，终结svn时代手动备份代码的远古习惯，提高个人代码管理效率。
• 如果一个功能需要多人协同开发，可以通过Git分支协同开发，驱散自己搭svn服务器、建svn仓库、代码手动同步的苦闷，提升团队协同开发效率。
• 如果这些都没有打动你，那还有最后一点：全世界都在用Git，作为基本技能的Git你都不会的话，以后找工作都困难哦。

 

团队级Git分支模型

Git本身并没有推荐的最佳实践，但有很多非官方的最佳实践总结，比如这篇《一个成功的Git分支模型》，这个分支模型贯穿整个产品的生命周期，为整个产品项目服务。这个模型过于复杂，特别是对于特性团队级的Git来说，有点重了。

团队的Git分支策略由使用场景、任务特点、开发周期等决定，在团队2年多的Git使用实践中，主要用到了如下三种分支模型：

• remote/master
• remote/master, remote/dev
• remote/master,  local dev

 

分支详情展示：

[email protected]:~/healthcheck$ git br -a
* master
  remotes/origin/master

 这个分支模型只有master分支。适用于在新团队中起步推广Git，避免使用复杂的分支模型，引起程序员心理不适。而且对于不需要协同开发的任务，这个分支模型也够用了。 

 

[email protected]:~/sc/robot_framework$ git br -a
  develop
* master
  remotes/origin/develop
  remotes/origin/master

 这个分支模型有master和dev分支，master分支是稳定版本分支，用于每日自动化测试的持续集成，要保证功能稳定。dev分支是开发分支，用于新特性开发和协同开发需要。

 

[email protected]:~/sc/ci$ git br -a
* alex_dev
  master
  remotes/origin/master 

 这个分支模型除了一个master分支外，还有一个未推送的本地dev分支。这种分支模型适用于如下场景：想验证对比多个实现方案，对已有实现采用多种策略进行重构尝试；只想从主分支同步某些合入，避免不相关的同步破坏自己正在开发的功能。

 

团队级Git工作流程

Git之所以强大，主要来自其复杂的分支模型和分布式策略，这也是其复杂的原因。

Git命令是操作的是Git对象和对象间的关系。所以要掌握Git，理解Git的工作机制，首先要理解Git中的基本对象，比如远程仓库、本地仓库、远程分支、本地分支，暂存区（stage）、工作区（workspace），以及数据是如何在这些对象中流动的。在这基础上，才有可能真正掌握Git。

上图是前面介绍的几种分支模型下的Git工作流及相关命令的总结梳理。

详细的命令讲解这里不再赘述，请读者咨询Google。这里只对几个易混淆的操作命令的区别总结如下：

• fetch只更新local repo，不修改local branch；
• pull更新local branch，pull等价于fetch+merge，pull -r等价于fetch+rebase；
• merge、rebase同时更新local branch、stage和workspace，只是合并策略不同；
• reset更新local branch和stage，不更新workspace；
• checkout更新stage和workspace，不修改local branch

 

Git推广注意事项

• Git推广中的最大的问题往往是最简单的问题，比如软件安装、兼容。所以最好能提供工具来统一环境，包括操作系统、基础软件、Git版本、Git配置等;
• 提前准备好各系统的安装包、安装说明，方便所有人访问查阅;
• 制定Git使用规范，通过工具，在环境配置、分支管理、提交日志、提交策略做好统一约束;
• 采用适合任务特点和团队的Git模型，不要盲目仿照。

 

-EOF-