本文介绍了Git版本的思想。内容非常详细。感兴趣的朋友可以参考一下，希望对大家有所帮助。
简单来说，git的管理策略有两大流派。和同事聊天或者和其他公司的朋友交流的时候都能感受到，分别是Git One Track和Git-flow。
一首曲目。
One Track简单来说就是在开发项目时，整个团队都在同一个分支上工作。这意味着开发阶段的所有工作都集中在同一个分支上，比如新功能开发和bug修复。当然，一轨战略并不意味着只有一个分支，而是只有一个发展分支。当达到团队设定的里程碑时，可以开一个新的分支来维护这个基本稳定的版本，这个维护分支只进行维护工作，不进行开发工作。与此同时，发展处继续进行最新的发展工作。
使用这种策略的最大特点是每个人都在同一个分支上工作，所以每次提交代码时可能会有冲突。为了减少冲突，团队经常会增加提交的频率，每次提交的粒度相对较小。同时管理成本相对较低，整个团队的学习成本也相对较低。
在我之前的项目中，我参加了一个刚刚从svn切换到git的团队。我们用了一段时间One Track的工作模式，可以看到这个策略对于整个团队接触和适应git是非常有利的。
但我相信更多的人还是很佩服另一种策略，即Git-Flow策略。
gitflow
首先，相信很多人一定在什么地方看到过下面这张图：
这张图片很好地说明了gitflow。也就是说，任何变化都是一个分支。
可以看出，虽然这个图中有很多分支，但大致可以分为两类。即主分支和辅分支。
主要分支。
主要分支是git的默认主分支和一个主要开发分支，develop。
主分支是git默认的主分支，团队通常不会在这个分支上开发。主要的开发分支“开发”管理开发人员提交的代码。当代码稳定或具有固定周期时，开发分支上的代码被合并到主分支中。
附属部门
团队的每个开发人员都可以访问辅助分支。常见的辅助分支包括：
功能部分
出版商
维修部门
这三种分支有其对应的使用场景。
在开发新的功能时，需要从主开发分支创建一个新的功能分支，然后在这个分支上的功能开发完成后合并主功能分支。
发布分支是版本发布时创建的一个分支，它包含了根据产品里程碑的要求应该完成的功能。
修复分支是创建一个新的分支来修改bug，然后将其合并回开发分支，以免影响开发分支。
因此，我们可以看到GitFlow的策略是以分支的方式开发功能和修复bug。这样做的好处当然是管理上非常干净。但是由于函数开发时间相对较长，代码提交粒度相对较大，分支合并时可能会出现冲突。另一个问题是，对整个团队的要求比一轨战略更高。
然而，没有完美的解决方案，有些解决方案只是更适合团队。例如，包括我在内的许多团队现在更喜欢混合使用这两种方法。比如One Track是在同一个分支上开发的，可能不够干净，可以适当开一个新的分支进行开发。针对GitFlow提交合并时粒度大、冲突多的情况，我们每天同步一次代码，不需要等整个功能完成后再合并到主开发分支。
我希望这是Git版本的想法。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/38061.html
