利用Git进行版本管理和团队合作 | 青训营笔记

186 阅读5分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的第2篇笔记

本文总结了利用Git进行版本管理和团队合作的两种常用工作模型,为后续大项目的合作打下基础

一、认识Git

Git是一种分布式管理系统(VCS),与其相对的是中央式管理系统,中央式管理系统只有一个中央仓库,成员每次改动都要提交到中央仓库,由中央仓库负责代码的版本控制和同步。分布式版本控制系统除了一个中央仓库之外还有本地仓库。团队成员在本地可以提交代码,查看历史。换句话说,分布式版本管理系统的本地仓库分担了中央仓库一部分保存版本历史的功能,不必每次做完一些小修改之后就向中央仓库提交同步请求。它们的工作模型分别如下:

中央式版本控制系统工作模型

(假设开发团队由三人组成)

  1. 主工程师搭建项目架构,创建中央仓库并提交代码
  2. 另外两个成员从中央仓库克隆代码,并在本地开始并行开发
  3. 每人独立负责一个功能,功能开发完成之后,这个人将新的代码提交到中央仓库
  4. 每当有人提交代码(中央仓库被更新)后,另外两人可以将这些代码同步到自己本地(pull)

确保本地代码是最新的

分布式版本管理系统工作模型

(依然假设开发团队由三人组成)

  1. 主工程师搭建项目架构,并把代码提交到本地仓库
  2. 主工程师创建中央仓库,并将1中代码提交到中央仓库
  3. 其他成员将中央仓库内容克隆到本地,并初始化本地仓库
  4. 每人独立开发一个功能,开发过程中的每一次改动提交到本地仓库
  5. 当某人把某项功能开发完成之后,将这个功能相关的所有提交上传到中央仓库
  6. 每当有人将提交上传的中央仓库后,其他成员可以将这些代码同步到自己本地与本地代码合并

分布式版本管理系统的优缺点:

优点:

  1. 大多数提交操作在本地进行,不依赖网络环境、速度更快
  2. 无需担心频繁的提交操作污染中央仓库的历史记录,可以将代码提交做得更细便于review和回溯

缺点:

由于本地需要维护版本历史,因此本地耗费的资源相比于中央式版本管理系统更多

(对于文本代码文件而言一般不会很大,而且VCS有相关的压缩算法,因此在大部分情景下这个缺点并不明显)

小结

Git是一种分布式版本管理系统,提供版本管理和代码同步功能。

在绝大部分情境下,基于分布式版本管理系统的Git是项目管理的很好选择。

二、团队合作模型

模型1 单一主线模型

在此模型下项目只有单一master分支,某一成员本地的更新在提交到中央分支之前无法被团队成员得知。利用该模型进行工作的流程如下:

  1. 团队中的任意成员本地commit之后,直接尝试push
  2. 如果push失败则表明中央仓库已经发生变更,需要将中央仓库pull(隐式执行了merge操作)到本地并处理冲突,处理完毕commit + push

该模型简单容易上手,但是缺点同样明显:无法保证master分支的代码质量;而如果对master分支进行频繁修改,则会降低团队合作的效率。

模型2 Feature Branching 模型

在此模型下,任何成员开发任何新的功能或者修复bug全都新建一个分支;新分支写完测试完毕与master分支进行合并,然后删除这个branch

举例说明该模型的工作过程:

假设小明和小王两人共同开发一个项目P,小明想要实现一个新功能F,那么小明首先从master分支下创建一个新分支B(git checkout -b B),在一段时间本地编码调试之后,小明完成了这项功能,并想要把F添加到master分支,这时小明应该做的操作流程如下:

  1. 利用git push origin B, 将当前分支上传到中央仓库的同名分支
  2. 等待大家的review意见,如果团队同意合并执行步骤3, 如果不同意那么继续修改分支B,然后重新执行步骤1
  3. 先更新本地的master分支到最新(git checkout master, git pull)
  4. 合并master分支与B分支(git merge B),将新的master分支上传(git push)到中央仓库
  5. 删除本地的B分支和中央仓库的B分支(git branch -d books, git push origin -d books)

利用Pull Request对模型2进行简化

有了Pull Request的工具加持,小明完成新功能之后所做的事情可以简化如下:

  1. 利用git push origin B, 将当前分支上传到中央仓库的同名分支
  2. 在中央仓库提供商的网页上创建一个 Pull Request
  3. 其他团队成员在此页面可以看到commit并提出意见,按照意见提交新的commits并push,多轮迭代后确定该功能可以merge到master
  4. 点击Merge Pull Request按钮,中央仓库自动合并master并删除B分支
  5. 将中央仓库Pull到本地

小结

单一主线模型虽然操作简单,但是有可能影响团队合作效率,单一主线的特性使它不适合应用在生产环境当中。

Feature Branching 模型是最流行的团队协作开发的模型,仓库提供商还提供了Pull Request方法简化相关操作。

参考资料

Git 原理详解及实用指南 朱凯