使用Git进行产品代码管理的总结

使用Git进行产品代码管理的总结

Git近些年来非常流行，很多公司已经从SVN/CVS/TFS 这样的管理工具切换过来，但是很多人对Git使用以及与其他版本管理工具的区别仍然有疑惑。在这里我根据实际的产品管理经验，总结一下Git工作流的实践，供大家参考。

背景和要求

可能很多朋友与我们一样，进行着产品的开发和销售，通常这就意味着我们管理着一套产品的基准代码，同时又需要满足各个客户的要求，对每个销售的版本进行单独的二次开发和修改，这些代码的变更修改往往是不能合并到产品代码的主线中的。因此需要对每个销售的版本进行管理。
之前我们的方式比较落后，简单的把每个项目的代码复制出来，重新建立一个新的Repository，随着项目变多，很多修改需要在不同的Repository间复制，尤其是bug的修复，如果在主产品代码上修复了bug没有即时在其他项目间同步，那一定是会被忘掉的，然后团队成员在其他项目的代码上再改一遍，极大的浪费有没有…
针对这些问题，我们进行了改进，这种，利用了Git的分布式开发特性，分成了产品主线开发、销售版本的开发两部分，当然仅仅是Git不够的，在版本管理的实施过程中，团队还需要达成默契：定版本、勤提交、写说明。

GIT的典型工作流模式

Git 是分布式的工作流程，使得开发者之间的协作更加灵活多样，根据官方的总结，主要有三种模式：集中式工作流、集成管理者工作流、司令官与副官工作流。实际使用中可以选择其中的一种或者将几种进行搭配使用，在这里把官方的介绍进行整理，更加具体的您可以去参考官方文档。

集中式工作流

这意味着如果两个开发者从中心仓库克隆代码下来，同时作了一些修改，那么只有第一个开发者可以顺利地把数据推送回共享服务器。 第二个开发者在推送修改之前，必须先将第一个人的工作合并进来，这样才不会覆盖第一个人的修改。 这和 Subversion （或任何 CVCS）中的概念一样。

集成管理者工作流

Git 允许多个远程仓库存在，使得这样一种工作流成为可能：每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。 这种情形下通常会有个代表`‘官方’’项目的权威的仓库。 要为这个项目做贡献，你需要从该项目克隆出一个自己的公开仓库，然后将自己的修改推送上去。 接着你可以请求官方仓库的维护者拉取更新合并到主项目。 维护者可以将你的仓库作为远程仓库添加进来，在本地测试你的变更，将其合并入他们的分支并推送回官方仓库。

司令官与副官工作流

这其实是多仓库工作流程的变种。 一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式，例如著名的 Linux 内核项目。 被称为副官（lieutenant）的各个集成管理者分别负责集成项目中的特定部分。 所有这些副官头上还有一位称为司令官（dictator）的总集成管理者负责统筹。 司令官维护的仓库作为参考仓库，为所有协作者提供他们需要拉取的项目代码。 整个流程看起来是这样的(见 司令官与副官工作流。):

• 普通开发者在自己的特性分支上工作，并根据 master 分支进行变基。 这里是司令官的master分支。
• 副官将普通开发者的特性分支合并到自己的 master 分支中。
• 司令官将所有副官的 master 分支并入自己的 master 分支中。
• 司令官将集成后的 master 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。

主产品线版本管理

对于产品的主线的版本管理，还是基于Git的集中式管理模式，与我们以前用的SVN差不多，在分支上做了优化，我们创建了这几个分支：develop、bugfix、feature、prelease，加上master，一共五个。

• develop: 开发团队日常开发测试的分支
• bugfix: bug修复分支
• feature：具体功能的开发，开发一些比较独立复杂的功能。
• prelease：发布前的测试，给测试团队用的
• master：发布的版本，每个发布版本会打Tag，标记一下。

参考这张图：

开发

在实际操作中，涉及到开发、测试、产品三种角色。对于开发，一开始我们是在develop分支进行的，处在混沌态，很多页面的调用参数需要即时的协调和沟通，搭好产品的基本框架。根据产品需求，一些功能逐渐的被分配给一个或者几个人进行开发，这时创建一些feature分支（feature1，feature2），开发完后merge到develop分支（当然经常因为变动一些feature直接被砍掉了，你懂的），当一个阶段开发完成后，我们会将develop内部测试一遍，合并到test分支给测试团队，然后继续进行下一阶段的开发。

测试

通常测试团队可以在1~2个工作日给我们反馈结果，我们基于test创建一些bugfix分支，由此bugfix和test进入了蜜月期，直到测试团队通过。完成后的需要保证所有的修改都合并到了develop中。

发布

测试完成后，由test创建分支到master，并打上tag版本号发布出来，注意这里的发布还是内部发布而不是直接发布给客户。

销售版的版本管理

销售版本面向每个客户都是不同的，这就利用了Git的集成管理者模式，从产品主线的master中fork出来，当然fork这个功能只有gitlab/github里面有，实际fork是由多个git命令实现的，这里借用这个名字。
fork出来的代码与主产品代码有着上下游的关系，销售版可以拉去最新发布的master版本，也可以提交到主产品中，但只能创建新的feature提交进去。

销售版的分支就没有那么多了，只有feature，bugfix，prerelease，和master。测试团队和开发团队一样，这里我们取消了develop分支，让prerelease具备了他的功能，即日常开发基于prelease。

过程是这样的：

首次发布

1. fork master版本的代码到prelease分支
2. 从prelease发布到master，把master发布给客户

二次开发/修改

1. 二次修改，创建feature/bugfix 开发完成后发布到prelease
2. prelease测试完成后合并到master，发布给客户。

提交到产品主线中

在产品主线中创建一个feature分支，将需要提交的feature和bugfix都提交到这个分支中。

总结

这里分享的是我们的经验，相信很多朋友遇到跟我们类似的情况，可能每个团队的成员组成不一样，具体的操作流程需要进行调整，但重要的是熟悉git的过程，创建合并分支，集成和分布式的进行代码管理。

附：全过程的Git操作命令