利用git 进行多人协做开发

如今，大部分项目都是用 git 来管理代码的，但当项目变大、多人协做时，git 的使用就变得复杂了，这时就须要在 git 使用的流程上来思考如何更优的使用 git。

对于大部分 web 项目而言，并不像软件、APP 项目同样有版本的划分，而是不断的更新、迭代，这就使得 web 项目的 git 使用要复杂一些，须要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、多人共同开发时如何避免代码冲突与线上新代码被旧代码覆盖等等。

1. 一个分支

若是项目比较小，不频繁更新时，能够只用 master 一个分支。

使用流程：

1. 提交代码到本地 master 分支，并推送到远程 master 分支
2. 持续集成构建或本地构建，而后上传到服务器

上传到服务器有两种方式：

1. 持续集成构建，而后同步到服务器
2. 本地构建，而后上传到服务器（为了简洁清晰，后面的图例中会隐藏这种方式）

2. 开发分支与我的分支

若是项目稍大些，频繁更新时，就须要另一个开发分支：

• master：主分支，对应线上代码
• dev：开发分支，对应开发代码

使用流程：

1. 提交代码到本地 dev 分支
2. 在须要构建项目时 merge 到本地 master 分支，并推送到远程 master 分支
3. 持续集成构建，而后同步到服务器

若是是多人参与的项目，就须要我的开发分支了：

• master：主分支，对应线上代码
• man1：我的 man1 开发分支
• man2：我的 man2 开发分支

使用流程：

1. 提交代码到本地 man1 分支（以 man1 我的为例）
2. 在须要构建项目时 merge 到本地 master 分支，并推送到远程 master 分支（有可能须要先 pull 远程的代码）
3. 持续集成构建，而后同步到服务器

在适当的时候，每个我的分支（如 man1, man2）都须要 pull 一下 master 分支，以保证本身本地的代码的版本不会低于服务器。

3. 多个服务器环境

若是项目比较大，而且对应多个服务器环境（测试环境、产品环境）：

• master：主分支
• prod：产品分支，对应产品服务器环境
• test：测试分支，对应测试服务器环境
• dev：开发分支

使用流程：

构建测试环境：

1. 提交代码到本地 dev 分支
2. 在须要构建项目时 merge 到本地 test 分支，并推送到远程 test 分支
3. 持续集成构建，而后同步到测试服务器

构建产品环境能够由远程的 test 分支 merge 到远程 prod 分支进行持续集成构建，也可由本地 dev 或 test 分支 merge 到本地 prod 分支，并推送到远程 prod 分支进行持续集成构建。

若是是多人参与的项目，就须要我的开发分支了：

• master：主分支
• prod：产品分支，对应产品服务器环境
• test：测试分支，对应测试服务器环境
• man1：我的 man1 开发分支
• man2：我的 man2 开发分支

使用流程：

构建测试环境：

1. 提交代码到本地 man1 分支（以 man1 我的为例）
2. 在须要构建项目时 merge 到本地 test 分支，并推送到远程 test 分支（有可能须要先 pull 远程的代码）
3. 持续集成构建，而后同步到测试服务器

构建产品环境能够由远程的 test 分支 merge 到远程 prod 分支进行持续集成构建，也可由本地 man1 或 test 分支 merge 到本地 prod 分支，并推送到远程 prod 分支进行持续集成构建。

在适当的时候，每个我的分支（如 man1, man2）都须要 pull 一下 prod 分支（若有须要，也能够 pull test 分支），以保证本身本地的代码的版本不会低于服务器。

4. 多个需求同时开发

有时候会有多个需求同时开发，而且相互独立，为了避免影响每一个需求的测试与上线，须要为每一个需求建立一个分支。

• master：主分支
• prod：产品分支，对应产品服务器环境
• test：测试分支，对应测试服务器环境
• man1：我的 man1 开发分支
• man2：我的 man2 开发分支
• task1：需求 task1 开发分支
• task2：需求 task2 开发分支

使用流程：

构建测试环境与以前的步骤一致，但构建产品环境时，为了保证各个需求不相互影响，通常由本地直接合并到 prod 分支：

1. 本地 task1 分支 merge 到本地 prod 分支，并推送到远程 prod 分支进行持续集成构建
2. 每个我的分支（如 man1, man2）都须要 pull 一下 prod 分支，以保证本身本地的代码的版本不会低于服务器
3. 最后删除 task1 分支

5. 多人协做开发修改公共文件

由于不一样分支修改同一个文件而致使的文件冲突是多人协做开发中比较常见的问题之一，避免这种问题的思路主要有如下的几种：

1. 在代码层面，尽可能避免多个成员都会改动的文件，尽可能将代码分解到每一个人只负责本身的那块代码，不须要去改别人的代码
2. 在工程层面，尽可能减小公共文件，尽可能每一个文件只由一我的负责
3. 在 git 层面，若是有必要，能够单独建一个分支，用于更新某些公共文件，并及时的更新到其余分支

6. 其余分支

有一些经常使用的分支，可能咱们会用到：

• bug 分支：用于紧急修复产品环境的 bug

7. 根据状况调整、简化流程

上面的图例只有测试服务器和产品服务器，更多服务器类型的工做流程是相似的；图例也只有 man1 和 man2 两个我的分支，更多我的分支的工做流程也是相似的。

上面的图例主要用于如下特色的项目（须要把整个项目打包成一个总体）：

• 单页面 web 前端应用，整个项目只有一个 html 文件，页面之间的切换由本地路由控制，每次更新到服务器都须要打包全部页面
• Java、Go 等后端应用，每次都须要打包成一个总体，多是一个文件，或者一批文件（不打包成一个总体的方式除外，好比分散 java class 文件）
• 使用持续集成构建的方式更新代码到服务器

这样作主要是为了不一些问题：

• 线上新代码被旧代码覆盖：多人同时开发项目，都须要更新到测试机，若是不是统一 push 到 test 分支作持续集成构建，很难保证线上新代码不会被旧代码覆盖
• 未测试的代码被更新到产品环境：这个问题也须要注意，由于这个问题并不能从流程上彻底杜绝，须要各位在开发中留意

对于像下面这种特色的项目，能够根据状况调整、简化流程：

• 多页面 web 前端应用，把某一个页面更新到服务器并不影响其余页面
• NodeJs、PHP、Python 等后端应用，只上传本身更新的文件，而不影响服务器上其余文件（把全部代码打包成一个总体的方式除外）
• 使用本地构建的方式更新代码到服务器

好比：

• master：主分支
• man1：我的 man1 开发分支
• man2：我的 man2 开发分支
• task1：需求 task1 开发分支
• task2：需求 task2 开发分支

使用流程：

若是多个需求没有冲突，能够同时在 man1 我的分支上开发，并根据须要上传到不一样的服务器。

若是多个需求有冲突，能够每一个需求都新建一个分支，如上图所示：

1. 提交代码到本地 task1 分支（以 task1 我的为例）
2. 根据须要上传到不一样的服务器
3. 若是代码经过产品环境后，更新到每一个我的分支，并删除 task1 分支