Enable javascript in your browser for better experience. Need to know to enable it? Go here.
radar blip
radar blip

Gitflow 的长期分支

本页面中的信息并不完全以您的首选语言展示,我们正在完善其他语言版本。想要以您的首选语言了解相关信息,可以点击这里下载PDF。
更新于 : May 19, 2020
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。 了解更多
May 2020
Hold ? 谨慎行事

五年前,我们强调了 Gitflow 长期分支 的问题。从本质上讲,长期分支与将所有更改持续集成到源代码中的方法背道而驰。并且,根据我们的经验,持续集成对大多数软件开发来说是更好的方法。后来,因为看到不少团队几乎只用长期分支,我们将警惕的态度扩大到 Gitflow 本身。时至今日,我们依然能看到以 Web 系统持续交付为既定目标的团队沉迷于长期分支。因此当看到 Gitflow 的作者现在已经在他的原有文章中添加了一条注释,解释说 Gitflow 当初不是为此类场景而设计时,我们非常高兴。

May 2015
Hold ? 谨慎行事

Gitflow is a strict branching pattern for releases using Git. Although not an inherently bad pattern, we often see it misused. If the feature and develop branches are short lived and merged often, you are really using the power of Git, which makes these activities easy. However, a problem we often see is that these become long lived branches , which results in the dreaded merge conflicts many people began using Git to escape. A merge is a merge. Regardless of the source control tool or pattern you use. If you wait more than a day or two to merge, you could hit a big merge conflict. This becomes a real issue if you have a larger team. If you have more than a few people waiting to merge, you can have a serious a bottleneck. Introducing patterns like Gitflow require the discipline to merge often to be successful. So by all means use the pattern, but only if you have the discipline to prevent long lived branches

Jan 2015
Hold ? 谨慎行事
发布于 : Jan 28, 2015

下载 PDF

 

English | Español | Português | 中文

订阅技术雷达简报

 

立即订阅

查看存档并阅读往期内容