开展项目就需要了解GitHub的流程，才能更好的使用它

workflow.png

GitHub的几个常见名词

• Repostory: 仓库，用来存放代码的地方
• Master ： 主干，当创建好一个仓库以后，即使没有任何的代码也会有这样一个master，作为存放代码的根目录
• Branch ：分支，根据项目特点可以创建多个分支，可以用来开发新功能，可以提交缺陷修复补丁，可以发布生产版本等
• Tag：标签，一般用于在版本发布的时候带上一个标签，一个是标记历史版本，一个是可以从中将发布出去的版本进行跟踪
• Pull Request : 如果是有分支合并，比如child branch往parent branch合并，branch往master合并，或者fork一个项目想作为贡献者提交个人代码到原仓库。这个主要是将发起的request给到仓库管理员或者项目管理员进行评审，如果代码合适就可以提交成功。

GitHub的几种工作流程

集中式工作流

• 特点

  
  集中式工作流.png

• 集中式工作流类似SVN，它也是从SVN转到GitHub使用最容易入手的一种形式。它的特点就是集中式管理代码，每一个项目中的修改分支都会作为一个分支最后回到中央仓库集中。就是要么回到Master,不然就创建一个developer分支，最后回到dev分支结束。
  所有的开发者都要clone或者复制master,branch进行开发，然后所有的开发者在将代码push回到这里。

• 问题
  这个方式比较容易入手，但是代码没有分支，容易push操作出现代码冲突，比较相同的文件太多，不同的开发者将代码放进同一个文件中就会出现冲突的问题。

• 解决冲突的方式
  首先代码存放本地，如果需要提交代码的话，先使用fetch功能，将GitHub远程仓库代码同步到本地暂存区，然后使用push的方式进行代码提交，如果遇到冲突的文件，需要单个文件解决冲突以后才可以push成功。

  
  流程图.png

功能分支工作流

• 特点

  
  功能分支工作流.png

• 特点
  功能分支的特点在于根据功能模块划分，可以创建多个branch进行并行开发代码，这样在自己功能完成前都可以在branch上面不需要将代码push到master，也不需要关系其他同事开发的功能是否跟自己有冲突或者关联性。

• 问题
  功能在没有开发完成或开发完成以后会push到master的步骤，当master分支如果有合并的操作时候有可能功能并未开发成功，影响master的进度及功能，有可能还有相关的bug产生。

• 解决方式
  当合并的时候可以创建pull request，让领导或者其他开发者帮助检查代码及优化的空间，如果没有问题就可以提交代码到master.相反如果问题或者改进意见需要得到复批以后可以重复pull request，然后就可以合并分支。

发布分支工作流

• 特点

  
  发布分支工作流.png

发布分支工作流.png

• 跟功能分支类似，需要根据不同的功能模块进行创建不同的分支，这里我们需要创建的分支是根据业务流

• 根据图片显示不同的版本时期为了完成不同的功能，这样就会有不同的功能开发

• 每个功能根据时间，优先级就可以在不同的版本发布

• 如果不是当前版本需要发布的功能可以继续开发，不需要合并到主分支，或者是master分支

• 重要的分支master,Develop,Release分支

• 问题
  跟功能分支类似，如果有需要合并或者交互性的功能，需要进行合并而且需要提交版本库中

维护分支工作流

维护分支工作流.png

• 特点
  维护分支主要是关注的hotfix分支，主要是在产品版本发布以后，测试人员发现bug并需要修复的时候，单独创建的分支。
  这个分支可以从master分支，或者release分支中生成，具体可以关注项目要求。

• 问题
  当bug被修复可以让测试人员继续测试的时候，hotfix分支可以将代码跟develop分支合并，当问题确认修复，可以在tag以后跟master分支合并。
  这样做的好处是可以在master上面找到版本信息，如果有新的bug，可以继续修复。