Git-flow是其他人严重依赖的系统 [英] Git-flow for the system that others have heavy dependency on

查看:154
本文介绍了Git-flow是其他人严重依赖的系统的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的团队已经使用SVN很长一段时间了,我们将尽快将我们的源代码回购移动到Git。在我的团队中,至少有10多位专门为系统开发的开发人员和更多经常接触系统代码库的开发人员。

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



使用我们正在尝试使用的Git流模型,我看到一些问题。
1.由于我提到的第二个原因,我们应该为其他团队提供基本的功能来进行他们的测试& QA。此外,某些功能下周只需要1至2天的时间进行开发和部署,而涉及很多部件的大功能则会滞留在开发或质量保证环境中超过几个月。不可能将它合并到QA分支并同时部署其他功能。



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



所以我现在在想什么就像团队在SVN基础上所做的一样。我们将介绍adhoc分支(或测试分支),它允许工程师只将代码转储到分支中,仅用于为他人开发测试并运行它与虚拟机。
这个分支将不会合并,甚至有时分支将从开发分支重新创建。一旦其他系统完成实现,我们将该特性分支推送到开发分支,并且从它开始分发下一个版本QA分支等等。(继Git-Flow之后)

这样做的一个问题是,因为人们会继续在这里抛弃他们的代码,所以不能保证你的代码将保持它们的状态(其他人可以覆盖你的代码)。我会告诉其他人关于这个分支/实例的目的,不要指出这是发布质量保证等,但我想知道是否有任何简单的解决方案。



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



感谢您的阅读。 这个......不相信这是一个好主意,因为我们做了类似于你在我以前的公司中描述的东西,在那里我们有一个一次性分支,人们可以快速推出他们的变化以进行演示。据了解,这个分支可能不稳定并包含错误。我并不完全相信这样的过程是有帮助的,但我不打算在这个答案中讨论这种方法的优点或缺陷。



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




这个问题的一个问题是,由于人们会继续在这里抛弃他们的代码,不保证你的代码将保持它们的状态(其他人可以覆盖你的代码)。我会告诉其他人关于这个分支/实例的目的,不要指出这是发布质量保证等,但我想知道是否有任何简单的解决方案。


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

 #回购
git config receive.denyNonFastForwards true

您可以创建另一个远程实例并设置该配置,然后让开发人员将其工作副本推送到共享分支。仍然有可能通过删除它来覆盖分支,然后推送它的副本,并且还有一个设置可以在单个回购中禁用该设置, receive.denyDeletes ,但是禁用远程分支删除功能可能会让您不便于实际 远程删除分支 ...所以我想这取决于您。


My team has been used SVN for a long time, and we are going to move our source repo to Git soon. In my team, there at at least 10+ dedicated developers for the system and more developers who frequently touch systems codebase.

Since our system has many features like account management, payment, 3rd party connection, etc, almost every systems in the company has dependency on it, and we should always deliver early feature implementation in dev(or QA) to allow others develop their feature.

With Git-flow model we are trying to use, I see some issue. 1. Due to 2nd reason I've mentioned, we should provide basic functionality to other team for their testing & QA. Also, some feature only takes 1~2 days to develop and deployed next week whereas big feature touching many parts would stay in dev or QA environment more than couple of months. It's impossible to merge it to release QA branch and deploy with other features at the same time.

Best way would be asking developers create their own test instances on company's test VM so that other system can point, but unfortunately we have some limited VM resources right now and can't create many VMs as we like.

So What I'm thinking right now is, as team did same way before in SVN based.. We are going to introduce "adhoc branch" ( or "test branch" ) which allows engineers just dump their code into the branch only for "dev testing for others" and run it with VMs. There will be no merge from this branch, and even sometimes branch will be re-created from develop branch. And once other systems finish their implementation, we push that feature branch into develop branch, and brach off next release QA branch from it, etc. ( following Git-Flow)

One problem of this is, since people will keep dumping their code here, there is no guarantee your code will stay their as you initially committed ( others can overwrite yours ). I'll tell other folks about the purpose of this branch/instance and don't point this for release QA, etc.. but I'm wondering if there is any simple solution for this situation.

We definitely don't want cherry-pick for this since we experienced too many pitfall of cherry-pick.

Thanks for reading.

解决方案

I've done something like this...not convinced it was a good idea though

So we did something similar to what you're describing at my previous company, where we had a "throwaway" branch where people could just quickly push their changes for demoing purposes. It was understood that this branch may be unstable and contain bugs. I'm not entirely convinced that it was helpful to have this sort of process in place, but I'm not going to discuss the merits or pitfalls of the approach in this answer.

A solution to overwriting other developers' work

One problem of this is, since people will keep dumping their code here, there is no guarantee your code will stay their as you initially committed ( others can overwrite yours ). I'll tell other folks about the purpose of this branch/instance and don't point this for release QA, etc.. but I'm wondering if there is any simple solution for this situation.

If you're worried about people overwriting other people's work, you can disable force pushes for an entire repo by setting this in the repo's git config:

# In repo
git config receive.denyNonFastForwards true

You could create another remote instance and set that config, then have your developers push a copy of their work to a shared branch there. It's still possible to "overwrite" the branch by deleting it, then pushing your copy of it, and there's a setting that will disable that in an individual repo too, receive.denyDeletes, but disabling remote branch deletion can make it inconvenient for when you actually do want to delete the branch remotely...so I guess that's up to you.

这篇关于Git-flow是其他人严重依赖的系统的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆