github项目团队协作开发流程

数据分析绘图软件开发项目将由多人合作进行开发、测试、发布等工作，为了控制软件开发的版本管理、代码共享以及项目整合等，有必要采用git分布式版本管理工具进行项目版本管理和github开源平台作为代码仓库托管平台。因此本文介绍了git和github的基本使用方法，并基于git和github定义团队开发的工作流（workflow）。

1.git和github相关概念

git最基本的概念和操作这里不详细介绍，可以参考网上相关的教程文档，这里只介绍与项目相关的内容。同时，为了简化使用并节约学习时间，在Windows上使用git和github可以使用github for Windows软件，进行本地和github上的版本管理、内容管理的相关操作。

• 仓库（Repository）
  

仓库是git的基本概念，本质就是一个文件目录，这个目录中的所有文件都被git管理，目录下不管做什么操作都会被记录，包括：增加、删除、修改文件等，都会被记录下来，以便后来跟踪与修改相关记录，甚至可以还原到项目中的某个点。从项目的开始到结束，我们会有两种仓库。一种是源仓库（origin），一种是本地开发者仓库。对于本项目，围绕远端github上的源仓库，每一个开发者都会在本地有一个clone的开发者仓库与源仓库关联。每个开发者都有权限拉取（pull）源仓库的内容阅读，在本地开发者仓库修改并推送到远程源仓库。不过，为了控制不必要的错误修改，后文介绍了源仓库上使用的一些配置，使得源仓库的重要分支无法被开发者直接修改。

源仓库

在项目的开始，首先构建起一个项目的最原始的仓库，我们把它称为origin，以我们的项目为例源仓库即为github上的jaketear/DAGUI。在github上的源仓库内邀请团队开发成员（Collaborators）共同管理，项目的所有代码都托管在这个源仓库上，每个团队成员都可以获取并修改源仓库内容。

源仓库的有两个作用：

1. 汇总参与该项目的各个开发者的代码
2. 存放趋于稳定和可发布的代码

开发者仓库

源仓库建立以后，每个开发者需要做的事情就是把源仓库clone到本地，作为自己日常开发的仓库。以github for windows软件为例，通过Clone repository就可以将指定的仓库克隆到本地，同时本地的仓库与远程源仓库是关联的，随时可以通过push或pull等操作与源仓库进行交互。

每个开发者的本地仓库共享同一个源仓库，为分离每个人的工作应在仓库自己对应的分支进行操作，实现分布式的工作，集中式的管理。

• 分支（branch）
  

分支是git中非常重要的一个概念,几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，在项目的开发中会频繁使用git提供的创建分支、合并分支和删除分支的操作。关于git branch的详细介绍请参考网上相关的文档，这边介绍与项目相关的内容。

在一般的项目开发中会定义分支模型，在常用的模型中，分支有两类，五种

• 永久性分支
  
  
  • master branch：主分支
  • develop branch：开发分支
• 临时性分支
  
  
  • feature branch：功能分支
  • release branch：预发布分支
  • hotfix branch：bug修复分支

永久性分支：

永久性分支是寿命无限的分支，存在于整个项目的开始、开发、迭代、终止过程中。永久性分支只有两个master和develop。

master：主分支从项目一开始便存在，它用于存放经过测试，已经完全稳定代码；在项目开发以后的任何时刻当中，master存放的代码应该是可作为产品供用户使用的代码。所以，应该随时保持master仓库代码的清洁和稳定，确保入库之前是通过完全测试和代码reivew的。master分支是所有分支中最不活跃的，大概每个月或每两个月更新一次，每一次master更新的时候都应该用git打上tag，说明你的产品有新版本发布了。

develop：开发分支，一开始从master分支中分离出来，用于开发者存放基本稳定代码。开发者自己的分支一般基于develop分支创建，开发的代码存放在自己的分支（develop-name）上。当开发者把功能做好以后，可以向源仓库发起一个pull request（PR），请求把自己分支合并到源仓库的develop中。

所有开发者开发好的功能会在源仓库的develop分支中进行汇总，当develop中的代码经过不断的测试，已经逐渐趋于稳定了，接近产品目标了。这时候，我们就可以把develop分支合并到master分支中，发布一个新版本。所以，一个产品不断完善和发布过程就正如下图：

注意，任何人不应该向master直接进行无意义的合并、提交操作。正常情况下，master只应该接受develop的合并，也就是说，master所有代码更新应该源于合并develop的代码。

暂时性分支：

暂时性分支和永久性分支不同，暂时性分支在开发过程中会被删除的分支。所有暂时性分支，一般源于develop，最终也一定会回归合并到develop。

feature：功能性分支，是用于开发项目的功能的分支。开发者在本地仓库从自己分支分出功能分支，在该分支上进行功能的开发，并推送到源仓库，开发完成以后再合并到develop分支上，这时候功能性分支已经完成任务，可以删除。功能性分支的命名一般为feature-*，*为需要开发的功能的名称。

release：预发布分支，当产品即将发布的时候，要进行最后的调整和测试，这时候就可以分出一个预发布分支，进行最后的bug fix。测试完全以后，发布新版本，就可以把预发布分支删除。预发布分支一般命名为release-*。

hotfix：修复bug分支，当产品已经发布了，突然出现了重大的bug。这时候就要新建一个hotfix分支，继续紧急的bug修复工作，当bug修复完以后，把该分支合并到master和develop以后，就可以把该分支删除。修复bug分支命名一般为hotfix-*。





以我们的项目为例介绍分支的操作，假设我是DAGUI项目的开发者，并且已经把源仓库clone到本地仓库，现在要基于develop分支进行开发工作：

github for Windows方法：

step 1：基于develop新建分支develop-yanhua，可以根据需求选择是否将此分支publish到源仓库。

step 2:在此分支上进行开发工作，多次提交commit（commit相当于每次开发后的提交的一个状态点，可以在开发过程中随时回退到之前的commit点）。commit后可以将代码推送到远程源仓库对应的develop-yanhua分支。

step 3：把做好的功能合并（merge）到develop中。在本地仓库虽然可以合并到本地的develop分支，但是不推荐这么做，同时由于流程的控制，本地的develop和master的commit被禁止直接提交到远程源仓库的对应develop和master分支。因此合并到develop需要遵从规定的工作流程，即在github上提交pull request申请将develop-yanhua分支合并到develop，这需要相关的其他团队开发人员review代码确认无误后才能合并分支。

git命令行方法：

使用git命令行模式进行版本管理的方法步骤基本类似，git的操作命令请参考网上教程。

step 1：切换到develop分支

 >>> git checkout develop

step 2：新建一个分支

 >>> git checkout -b develop-yanhua

step 3：在新分支上进行开发工作，多次commit，测试...提交到远端

 >>> git commit
 >>> git push

step 4: 本地的分支合并

    >>> git checkout develop

    # 回到develop分支

    >>> git merge --no-ff develop-yanhua
    # 把做好的功能合并到develop中

2.工作流（Workflow）

工作流定义

项目的工作流程初步定义如下，现阶段仅使用master和develop分支，后续根据软件开发、测试和发布需要增加相应分支。

master分支定义：

• 主分支
• 保持稳定
• 不允许直接往这个分支提交代码，只允许往这个分支发起merge request
• 只允许release分支和hotfix分支进行合并（现阶段仅允许develop分支进行合并）

develop分支定义：

• 开发分支
• 相对稳定的分支
• 用于日常开发，包括代码优化、功能性开发

feature分支定义：

• 特性分支
• 从develop分支拉取，用于下个迭代版本的功能特性开发
• 功能开发完毕合并到develop分支

release分支定义：

• 发布分支
• 从develop分支拉取
• 用于回归测试，bug修复
• 发布完成后打tag并合入master和develop

hotfix分支定义：

• 热更新分支
• 从develop分支拉取
• 用于紧急修复上线版本的问题
• 修复后打tag并合入master和develop

github工作流实例流程

以项目的基本工作流程为例，介绍使用github托管项目的主要流程操作方法。

step 1：源仓库构建

由发起人建立起了一个源仓库jaketear/DAGUI，初始化两个永久性分支master和develop，添加团队开发人员。

step 2：开发者clone源仓库，并创建自己的分支develop-name

clone仓库和创建分支的方法上文已有详细介绍，github显示的分支如下图

step 3：在本地仓库的自己分支develop-name开发，提交commit，推送到远端

step 4：github上提交pull request请求合并到develop分支

master和develop分支禁止直接从本地仓库commit并push到源仓库，必须由开发者的分支合并过去。合并前需要提交pull request的请求，通过相关代码编写人的code review并同意合并后才能将自己的分支合并到develop分支。master分支只能从develop分支合并。

为了提高效率，防止过多的冲突，在寻求分支合并前，应尝试将develop分支合并到自己分支，提前查看合并的冲突，在解决冲突后再提交pull request。

如图develop-wxl提交pull request以合并到develop分支，通过create pull request新建PR。

如图，workflow规定每次pull request必须有至少另一名开发者review才能完成merge，因此图中的pull request失败。

因此在github页面右侧添加Reviewers，请求其他开发者进行code review。

step 5：code review

github提供了强大的code review功能，可以在线直接review，也可以根据其分支在本地新建一个测试分支，进行review和测试。

step 6：Reviewer经过测试等没问题，同意可以把代码合并到源仓库的develop中。

以上，就是一个git & github协同工作流的基本步骤。

参考资料：

https://git-scm.com/book/zh

https://blog.csdn.net/xiangff_csdn/article/details/52184394

https://blog.csdn.net/koffuxu/article/details/39010803

https://blog.csdn.net/wwj_748/article/details/55226044