其他人严重依赖的系统的Git-flow

时间:2014-04-01 23:14:28

标签: git svn github git-flow

我的团队已经使用SVN很长一段时间了,我们很快就会将我们的源代码转移到Git。在我的团队中,至少有10多名专门的系统开发人员和更多经常触及系统代码库的开发人员。

由于我们的系统具有许多功能,如帐户管理,支付,第三方连接等,公司几乎每个系统都依赖它,我们应该始终在开发(或QA)中提供早期功能实现,以便其他人开发他们的特色。

我们尝试使用Git-flow模型,我看到了一些问题。 1.由于我提到的第二个原因,我们应该为其他团队提供测试和基础功能。 QA。此外,一些功能在下周开发和部署仅需要1~2天,而涉及许多部分的大功能将在开发或QA环境中停留超过几个月。将它合并到发布QA分支并同时部署其他功能是不可能的。

最好的方法是让开发人员在公司的测试虚拟机上创建自己的测试实例,以便其他系统可以指出,但不幸的是我们现在有一些有限的虚拟机资源,无法创建我们喜欢的虚拟机。

所以我现在正在思考的是,因为团队在SVN基础上做了同样的事情。我们将介绍“adhoc branch”(或“测试分支”),它允许工程师将他们的代码转储到分支中仅用于“为他人开发测试”并使用VM运行它。 此分支将不会合并,甚至有时分支将从开发分支重新创建。一旦其他系统完成了它们的实现,我们将该功能分支推入开发分支,并从它开始关闭下一个版本QA分支等(遵循Git-Flow)

这样做的一个问题是,由于人们会继续在这里转储他们的代码,因此无法保证您的代码会像您最初提交的那样保留其他代码(其他人可以覆盖您的代码)。我会告诉其他人关于这个分支/实例的目的,并且不要指出这个用于发布QA等等。但我想知道是否有任何简单的解决方案来解决这种情况。

我们绝对不希望樱桃挑选,因为我们经历了太多樱桃挑选的陷阱。

感谢阅读。

2 个答案:

答案 0 :(得分:1)

我做过这样的事情......但不相信这是一个好主意

所以我们做了一些类似于你在我以前的公司所描述的东西,我们在那里有一个"一次性"分支,人们可以快速推送他们的变化用于演示目的。据了解,这个分支可能不稳定并且包含错​​误。我并不完全相信采用这种程序是有帮助的,但我不打算在这个答案中讨论这种方法的优缺点。

覆盖其他开发者的解决方案'工作

  

这样做的一个问题是,由于人们会继续在这里转储他们的代码,因此无法保证您的代码会像您最初提交的那样保留其他代码(其他人可以覆盖您的代码)。我将告诉其他人这个分支/实例的目的,并没有指出这个用于发布QA等等。但我想知道这种情况是否有任何简单的解决方案。

如果您担心人们会覆盖其他人的工作,您可以通过在repo的git配置中设置此功能来禁用整个仓库的强制推送:

# In repo
git config receive.denyNonFastForwards true

您可以创建另一个远程实例并设置该配置,然后让您的开发人员将他们的工作副本推送到那里的共享分支。它仍然可以&#34;覆盖&#34;该分支删除它,然后推送它的副本,并有一个设置,将在个人仓库中禁用它,receive.denyDeletes,但禁用远程分支删除可能会使你不方便实际< strong> 确实要远程删除分支 ...所以我想这取决于您。

答案 1 :(得分:0)

更新

我们刚刚执行了我们的计划AS_IS,到目前为止看似顺利。工程师们对所有情况都非常担心,因为我们正在创建大量的功能分支,有时甚至是liveops bug修复分支。

工程师在adhoc分支中合并他们的功能,并将其推送到测试环境(如果他们不介意某人&#34;可能&#34;在合并期间意外覆盖他们的代码,他们可以使用adhoc测试环境),或创建自己的测试环境,其他系统可以指向。

一旦完成,其他过程与NVIE Git-Flow模型完全相同。只需要更多的爱和关注&#34;下一个版本将会发生什么?&#34;和&#34;什么是你的实时推送的先决条件/依赖&#34;。如果您的团队高度依赖于某些数据库端更改(如存储过程)并且您的团队未处理这些更改,请确保在获得已部署CR的更新之前等待合并变得容易并准备好在测试后首先将其合并以开发分支,并担心如果数据库更改请求被延迟,是否必须还原您的更改。 (这种情况下,应该有后向兼容性保证,如果你有多年的经验,可能你和其他团队会这样做)

我们会定期删除adhoc分支并从最新的开发分支重新创建它以进行同步。