Web项目如何进行git多人协同开发声明：本文不介绍git的基本用法，读者需要对git有一定的了解git，git命令，以及git的使用现在，大部分项目都使用git来管理代码，但是当项目变大，多人协作时，git的使用就变得复杂了。这时候就需要思考一下在使用git的过程中如何更好的使用git。对于大多数web项目来说，并没有像软件、APP项目那样的版本划分，而是不断的更新迭代，这使得web项目使用git变得更加复杂，需要管理哪些代码在开发，哪些代码提交用于测试，哪些代码已经上线，多人一起开发时，如何避免代码冲突和上线的新代码被旧代码覆盖等。1.对于一个分支，如果项目比较小，更新不频繁，只需要一个可以使用master的分支。使用流程：提交代码到本地master分支，push到远程master分支持续集成构建或者本地构建，然后上传到服务器上传到服务器有两种方式：持续集成构建，然后同步到服务器本地构建，然后上传到服务器（为了简洁明了，下图中会隐藏该方法）2.开发分支和个人分支如果项目稍大，更新频繁，需要另外开发一个分支:master:主分支，对应线上代码dev:开发分支对应开发代码使用流程：将代码提交到本地dev分支，需要构建项目时合并到本地master分支，推送到远程master分支进行持续集成构建，然后同步到服务器。如果是多人项目，需要个人开发分支：master：主分支，对应网上代码man1：个人man1开发分支man2：个人man2开发分支使用过程：提交代码到本地man1分支（以man1为一个例子）并在需要构建项目master分支时合并到本地，并推送到远程master分支（可能需要先拉取远程代码）进行持续集成构建，然后同步到服务器。在适当的时候，每个个人分支（比如man1，man2）都需要拉取master分支来保证你本地代码的版本不会低于服务端。3、多服务器环境如果项目比较大，对应多服务器环境（测试环境，产品环境）：master：主分支prod：产品分支，对应产品服务器环境test：测试分支，对应测试服务器环境dev:development分支使用流程：搭建测试环境：提交代码到本地dev分支，当项目需要构建时合并到本地test分支，推送到远程测试分支持续集成构建，然后同步到测试服务器构建产品环境可以通过远程test分支合并到远程prod分支进行持续集成构建，或者从本地dev或test分支合并到本地prod分支，推送到远程prod分支进行持续集成构建。如果是多人项目，需要个人开发分支：master：主分支prod：产品分支，对应产品服务器环境test：test分支，对应测试服务器环境man1：个人man1开发分支man2：个人man2开发分支使用流程：搭建测试环境：提交代码到本地man1分支（以man1为例）需要搭建项目时merge到本地测试分支，push到远程测试分支（以man1为例）可能需要先拉取远程代码）持续集成构建，然后同步到测试服务器搭建产品环境。可以将远程test分支合并到远程prod分支进行持续集成，也可以将本地man1或test分支合并到本地prod分支，推送到远程prod分支进行持续集成。在适当的时候，每个个人分支（比如man1、man2）都需要拉取prod分支（如果需要，也可以拉取test分支），保证你本地代码的版本不会低于服务端。4.同时开发多个需求有时会同时开发多个需求，并且相互独立。为了不影响每个需求的测试和上线，需要为每个需求创建一个分支。master：主分支prod：产品分支，对应产品服务器环境test：测试分支，对应测试服务器环境man1：个人man1开发分支man2：个人man2开发分支task1：需求task1开发分支task2：需求task2开发分支使用流程:搭建测试环境同前面的步骤，但是在搭建产品环境的时候，为了保证各个需求不互相影响，一般都是直接从本地合并到prod分支：本地的task1分支合并到本地prod分支，推送到远程prod分支进行持续集成构建每个个人分支（比如man1，man2）都需要拉取prod分支，保证本地代码的版本不会低于服务器的。最后删除task1分支。5.多人协同开发修改公共文件由于不同分支修改同一个文件导致的文件冲突是多人协同开发中比较常见的问题之一。避免这个问题的主要思路是：在代码层面，尽量避免多个成员会更改的文件，尽量将代码分解成每个人只负责自己的一段代码，不需要改别人的代码。在项目层面，尽量减少公开文件的数量，尽量每个文件只有一个人负责。在git层面，如果需要，可以单独建一个分支，用来更新一些公共文件，及时更新到其他分支。6.其他分支有一些常用的分支，我们可能会用到：bug分支：用于紧急修复产品环境中的bug7。根据情况调整和简化流程图例只有测试服务器和生产服务器，更多服务器类型的工作流程类似；图例也只有两个个人分支，man1和man2，更多个人分支的工作流程类似。上图主要用于具有以下特点的项目（需要将整个项目打包成一个整体）：单页web前端应用，整个项目只有一个html文件，页面之间的切换是受控的通过本地路由。Java、Go等后端应用需要对所有页面进行打包，每次都需要打包为一个整体，可能是一个文件，也可能是一批文件（除了不打包为一个整体，比如分散的java类文件）使用持续集成来构建这主要是为了避免一些问题：线上新代码被旧代码覆盖：多人同时开发项目，都需要更新到测试机。如果不统一推送到测试分支进行持续集成建设，很难保证上线的新代码不会被旧代码覆盖，未测试的代码会更新到生产环境：这个问题还需要注意，因为这个问题无法从流程中完全杜绝，开发中需要注意以下几点。特殊项目可以根据情况调整和简化流程：对于多页面的web前端应用，更新某个页面到服务器不会影响其他后端应用如NodeJs、PHP、Python等，仅上传更新后的文件，不影响服务器上的其他文件（除了将所有代码打包成一个整体的方式）使用本地构建方式更新代码到服务器，如：master：主分支man1：个人man1开发分支man2:personalman2developmentbranchtask1:requirementstask1developmentbranchtask2:Requirementtask2developmentbranch使用流程：如果多个需求不冲突，可以同时在man1个人分支上开发，根据需要上传到不同的服务器。如果多个需求之间存在冲突，可以为每个需求创建一个新的分支，如上图所示：将代码提交到本地的task1分支（以task1为例），根据需要上传到不同的服务器。如果代码通过产品环境，更新为Foreachindividualbranch，删除task1分支，就简单多了。更多后续博客，查看https://github.com/senntyou/blogs作者：沈玉之(@senntyou)版权声明：免费转载-非商业-非衍生-保留署名（CreativeCommons3.0许可）
