本文介绍了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