小开发团队的Git分支策略

Question

小开发团队的Git分支策略

Bil*_*lga 183 git branch git-branch

我们有一个网络应用程序,我们几乎每天更新和发布.我们使用git作为我们的VCS,我们当前的分支策略非常简单和破坏:我们有一个主分支,我们检查我们感觉良好的变化.这是有效的,但直到我们检查一个突破性的变化.

有没有人对小型团队有最喜欢的git分支策略,满足以下要求:

适用于2到3名开发人员的团队
轻量级,而不是太多的过程
允许开发人员轻松地隔离有关错误修复和更大功能的工作
允许我们保持稳定的分支(当我们必须让我们的生产服务器工作时,那些'哦'废话'的时刻)

理想情况下,我很乐意看到一个开发人员处理新bug的分步过程

Answer 1

Jim*_*dra 240

您可能会受益于Scott Chacon在Pro Git中描述的工作流程.在此工作流程中,您有两个始终存在,主控和开发的分支.

master代表项目最稳定的版本,您只需从此分支部署到生产环境.

开发包含正在进行的变更,可能未必为生产做好准备.

在develop分支中,您可以创建主题分支以处理各个功能和修复.一旦您的功能/修复准备就绪,您将其合并到develop中,此时您可以测试它与您的同事合并的其他主题分支的交互方式.一旦开发处于稳定状态,将其合并到master.从master部署到生产应始终是安全的.

Scott将这些长期运行的分支机构描述为代码的"孤岛",其中一个不太稳定的分支中的代码最终将"毕业"为经过测试和团队一般批准后更稳定的代码.

一步一步,您在此模型下的工作流程可能如下所示:

你需要修复一个bug.
创建一个名为myfix的分支,它基于develop分支.
处理此主题分支中的错误,直到修复为止.
将myfix合并到develop中.运行测试.
你会发现另一个话题分支的修复冲突hisfix你的同事合并到开发的时候在你修复工作.
在myfix分支中进行更多更改以处理这些冲突.
将myfix合并到开发和运行测试中.
一切正常.合并发展为大师.
随时部署到master的生产,因为你知道它是稳定的.

有关此工作流程的更多详细信息,请查看Pro Git中的" 分支工作流程"一章.

我认为这很好,除非你从开发分支创建bug修复分支,你强迫你不能将它合并到master并部署它而不必合并你尚未发布的所有其他"new",如果该分支中存在需要记录/数据库更改或其他难以完成的事情,那么这可能是一个真正的痛苦.我认为对于紧急的"修补程序",你应该让你的分支从主人. (68认同)
此外,Scott Chacon在他的网站上有一篇关于Github如何使用Git工作的优秀文章 - http://scottchacon.com/2011/08/31/github-flow.html (7认同)
如果我们正在开发两个独立的功能F1和F2,假设F1和F2的发展重合,那么F1将在一周内发布但F2将在2周内发布,该怎么办？有什么建议吗？ (5认同)
在步骤8,将开发分支合并到主分区听起来是个坏主意,因为开发中的某些代码可能还没有准备好投入生产.将功能分支合并到主服务器中我们会不会更好？ (5认同)
对于git没有的问题,`develop`是一个不必要的"解决方案".据我所知,成功是由于写得好,如果误导的文章没有任何评论.这是一篇反文章https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ (4认同)
我可以用实际经验来备份Stony的评论,这种情况比你希望的更频繁.如果您在其他人开始合并QA之后开始工作,即使功能也会遇到此问题.您可以在之前的版本中删除分支,但实际上并非所有开发人员都记得. (2认同)

Answer 2

Clu*_*tch 45

作为一名新手进入后试图找到一个直接的策略,教给其他从未使用过源代码控制的开发人员.这个适合http://nvie.com/posts/a-successful-git-branching-model/我尝试使用手册页中的标准GIT工作流程,但它让我和我的观众完全混淆了.

在过去的6个月里,我只需要两次修复冲突.我已经添加了一些步骤,以便在合并之后始终进行测试,并在开发功能时进行"获取和合并"或"拉动 - 基础"(一次在早上和下午).我们还使用github.com作为拉取最新代码的中心位置.

每当我看到有人拿起那篇博文时我就死了一点.这是一个反驳:https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ (4认同)

Answer 3

pro*_*365 35

(我的评论高于它自己的答案,正如我最初应该做的那样.)

来自Github的Scott Chacon:

我们如何做到这一点,GitHub Flow是什么？

主分支中的任何内容都是可部署的

要处理新事物,请从master创建一个描述性命名的分支(即:new-oauth2-scopes)

在本地提交该分支,并定期将您的工作推送到服务器上的同一个命名分支

当您需要反馈或帮助时,或者您认为分支已准备好进行合并时,请打开 拉取请求

在其他人审阅并签署该功能后,您可以将其合并到master中

一旦合并并推送到"主",您就可以并且应该立即部署

有关详细信息,请参阅整篇文章:http://scottchacon.com/2011/08/31/github-flow.html

请注意,"拉取请求"是Github的发明,它是在他们的网站上出现的东西,而不是Git本身:https://help.github.com/articles/using-pull-requests/

由于团队规模较小,开发人员对git缺乏经验,因此该工作流程的简单性非常出色.我们唯一不同的做法是在功能分支和主服务器之间建立一个"暂存"分支,作为非开发人员的实时QA站点,以便在生产环境中使用该功能. (4认同)

Answer 4

Lei*_*ldt 15

使用master分支作为开发分支并创建发布分支以执行错误修复.

任何新功能都将master在开发窗口期间继续(直接提交或作为带有pull-requests的主题分支,由您决定 - 未在图中显示).完成所有计划的功能后,输入功能冻结并执行测试.如果您满意,请将发布标记master为v1.0.

随着时间的推移,您的用户将发现错误,v1.0因此您需要从该标记创建分支(例如,在发布后命名1.0)并修复分支中的错误.如果你已经修复了足够的bug,你认为它需要一个新版本,然后v1.0.1将其标记为并将其合并回来master.

同时,master分支上可能会出现一个新的开发窗口,最终会被标记为v1.1.

冲洗并重复.

这遵循语义版本编号逻辑.

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

Run Code Online (Sandbox Code Playgroud)

不要忘记将``1.0.1`更改合并回`master` (5认同)
cherry-pick是一个更好的选择,可以将版本更改检索到master (4认同)

归档时间：	15 年，9 月前
查看次数：	90159 次
最近记录：	9 年前