从svn迁移到了git。 补充git知识和Git Flow在团队中的应用
Git的主要优点是分布式存储，本地仓库包含远程仓库的所有内容。 安全可靠，即使远程仓库文件丢失也不怕好的分支模型，创建/合并分支非常方便快捷。 从远程抽取和合并分支非常快，因为代码在本地有存储器。 如果分歧太多，如何管理这些分歧呢？ 我们的团队采用了Git Flow的模式
作为GitFlow常用分支的master主分支，在产品功能全部实现后，最终在master分支上对外宣布该分支为只读的唯一分支，只能与其他分支(release/hotfix )合并很容易描摹。 例如，release可被合并到主文件，或hotfix可被合并到主文件的主开发分支。 基于master分支的克隆包含发布到下一个release的所有代码，并且该分支是唯一的只读分支，只能从其他分支合并feature功能分支。 将release分支拉伸到与develop合并(不推送)的develop，检测到release/hotfix分支已联机，然后合并到develop并推送feature功能开发分支！ ) feature分支可以同时存在多个，因为团队中的多个功能被同时开发，所以是临时分支。 功能完成后，可选删除release测试分支，基于feature分支合并到develop后，从develop分支克隆并主要提交给测试器进行功能测试，测试中发现的bug在本分支修复。 修复在线后合并推送(完成功能)到develop/master分支，打Tag是临时分支，功能在线后可选删除hotfix补丁分支，根据master分支进行克隆。 主要用于在线版本修复和修复bug后合并并推送到develop/master分支，打Tag是临时分支。 修补程序在线后，删除所有热传真分支的更改(可选)将继续下一个release主要工作流1。 初始化项目为gitflow，缺省情况下创建主分支，并从主分支中引出第一个develop分支
从develop中提取feature分支进行编码开发(多个开发者提取多个feature同时进行并行开发，互不影响) )。
3 . feature分支完成后合并(不推送)到develop。 feature的功能是否会完成还没有被预测，如果推送的话会影响其他功能分支的开发) )。
要将feature合并到develop中，可以选择删除或不删除当前feature。 但是，不能更改当前的feature。 必须从release分支继续进行编码修改
从develop中提取release分支，在提取过程中在release分支中修正错误
5 .释放分支联机后，合并释放分支并将其推送到develop/master
合并后，根据需要删除当前的release分支。 如果不删除，则无法修改当前版本。 即使在线出现问题，也必须从master中拉动热传真分支进行修复
6 .上线后，如果发现在线错误，从主机上拉hotfix进行错误修正
7 . hotfix通过测试上线后，合并并推送至develop/master
合并后，(可选)删除当前主机传真。 如果不删除，则无法修改当前的热传真。 如果修补程序未修复，则必须从master中拉出新的热传真以继续修复
8 .运行一个feature时，如果develop分支发生了更改，并且其他开发人员完成并联机了该功能，则必须将完成的功能集成到自己的分支中
这意味着将develop合并到当前feature分支中
在执行release分支时，如果develop分支发生更改，并且其他开发人员已完成并联机该功能，则必须将完成的功能集成到自己的分支中
这意味着将develop合并到当前release分支(！ 当前的release分支在通过测试后在线发布，因此如果不合并最新的develop分支，可能会丢失代码。)
从大神那里引用的Git Flow工作流程图
讨厌命令行的同学，这里有一个完美支持Git Flow的图形工具-中文简体字支持)