这个Git分支模型有什么缺陷吗？

Question

我在询问这个git分支模型或工作流。我真的很喜欢这个。在我看来，这是非常直观和富有成效的，但我想要的是，这种方法是否有任何缺陷或负面，我还不清楚(来自ClearCase统治时代的另一个世界)。

(你不需要回答每一个问题，尽你所能帮助你)

1. 您使用此或类似的git分支工作流吗？
2. 你认为这是一种有成效的做法吗？
3. 你认为这种方法有什么缺陷吗？有什么潜在的缺点吗？
4. 如果你有一个更好的方法，你会介意分享，或提供一个链接到一篇文章或讨论它？

Answer 1

在大多数情况下，这是我们到目前为止使用的任何VCS所使用的通常工作流。有了一些(CVS，SVN)，就更难做了，而用GIT则是微不足道的。话虽如此，我有两点意见：

首先，在特色分支方面，有两种学派：

1. 把它们合并
2. 重新定位他们

(1)该条似乎意味着什么。合并提交的问题称为邪恶的合并。具体来说，那些加入一个函数在其中一个分支中更改了语义的开发路径，但是自动合并无法修补代码中来自另一个分支的所有出现的情况。以这种方式引入的回归是众所周知的很难调试的。作为一个GIT用户，您通常可以对回归更加轻松，因为您有git bisect可以自动为您找到它们的原因。但是，在所描述的情况下，git bisect将指出合并提交，这对您毫无帮助。

(2)尽量保持线性历史，从而避免了这一问题。那些反对重新基地的人声称它使你在重新基地之前所做的任何测试都无效。

就我个人而言，我坚定地站在camp (2)中，因为我更重视git bisect结果的有效性，而不是测试覆盖的潜在损失，这很容易通过使用适当的CI系统来补偿。

其次，我决定在开发人员之间穿插很少是个好主意。允许每个人在您的盒子中获取或在本地运行git-deamon涉及到安全问题，更重要的是，在不太小的团队中，疏忽可能会很快丢失。

尽管如此，我完全赞成使用分期存储库(有时也称为scratch)，该存储库允许子团队通过中央服务器共享他们正在进行的工作，但这与主服务器不同(通常是面向外部的，如果不是公共的话)。通常，每个子团队将为自己维护一个主题分支，而CI系统将对所有主题分支执行周期性的章鱼合并到一个大型集成分支，抱怨冲突和构建错误。

Answer 2

目前，我正在进行大规模和长期的重构(将应用程序从一个转换为另一个GUI工具包)，并成功地执行以重基为中心的工作流，因为其他团队成员仍在开发新功能：

主要有两个分支:开发新特性的master分支和toolkit-conversion分支。最重要的规则很简单:只在toolkit-conversion分支中执行与转换相关的事情。每当在master (旧的GUI工具包)中有什么可以做的时候，我就在那里做，并将toolkit-conversion更改重新定位到新的master头上。另一条规则是保持toolkit-conversion分支相当短。因此，我经常使用重置，樱桃挑选和修改-提交和重新基地的胶水属于较小的提交到较大的(这在最后有相同的目的)。如果我尝试了一些没有很好地“撤消”更改的东西，或者在我用临时助手代码重构了一些代码之后，这也会很好地工作。

我已经决定不将master中的更改合并到toolkit-conversion分支中，因为这将使得更难重新调整以前提交的提交，以保持分支的整洁和易于检查。此外，合并可能会引发冲突，其解决办法不如保持干净历史时那么明确。

当然，这种工作流程也有缺点.最重要的是，它只适用于一个人。当我将toolkit-conversion分支重定向到master的头上时，将它拉到另一个存储库上就变得困难了(自动地将其重新定位到跟踪分支通常会因为冲突而失败)。

最后，我的toolkit-conversion分支仍然很短，很干净，很容易查看。我无法想象使用SVN这样的强大功能。

Answer 3

我现在正忙着适应这个工作流。我认为这是一个很好的工作流，因为它使用git擅长的分支模型。

唯一的小缺点是，它需要一些纪律，以保持这个工作流程，而不是试图采取捷径。

科哈纳的开发人员也使用这个工作流，他们似乎非常喜欢它。