Git 的门控签入/预测试提交？

Gated check-ins / pre-tested commits for Git?

提问by

I'm looking at migrating from TFS (Team Foundation Server) to Git, but can't find anything matching TFS' support for gated check-ins (also called pre-tested or delayed commits).

我正在考虑从 TFS（Team Foundation Server）迁移到 Git，但找不到与 TFS 对门控签入（也称为预测试或延迟提交）的支持相匹配的任何内容。

Atlassian Bamboo has no support for gated check-ins. TeamCity does support it ("delayed commits" using their terminology), but not for Git. Using Jenkins by itself or Jenkins+Gerrit has huge drawbacks and doesn't come close to the gated check-in functionality in TFS. (Drawbacks explained by the creator of Jenkins himself in this video: http://www.youtube.com/watch?v=LvCVw5gnAo0)

Atlassian Bamboo 不支持门禁登记。TeamCity 确实支持它（使用他们的术语“延迟提交”），但不支持 Git。单独使用 Jenkins 或 Jenkins+Gerrit 有很大的缺点，并且与 TFS 中的门控签入功能不符。（缺点由 Jenkins 的创建者自己在此视频中解释：http: //www.youtube.com/watch?v=LvCVw5gnAo0）

Git is very popular (for good reason), so how are people solving this problem? What is currently the best solution?

Git 非常流行（有充分的理由），那么人们是如何解决这个问题的呢？目前最好的解决方案是什么？

采纳答案by Sam Holder

We have just started using git and have implemented pretested commits using workflows (I finished testing this just today).

我们刚刚开始使用 git 并使用工作流实现了预先测试的提交（我今天刚刚完成了测试）。

basically each dev has a personal repository which they have read/write access. The build server TeamCity in our case, builds using these personal repositories, and then if successful pushes the changes to the 'green' repository. Devs have no write access to 'green', only TeamCity build agents can write to that, but devs pull common updates from 'green'.

基本上每个开发人员都有一个他们有读/写访问权限的个人存储库。在我们的案例中，构建服务器 TeamCity 使用这些个人存储库进行构建，然后如果成功则将更改推送到“绿色”存储库。开发人员没有对“绿色”的写访问权限，只有 TeamCity 构建代理可以写入，但开发人员从“绿色”中提取常见更新。

So dev pulls from 'green', pushes to personal, TeamCity builds from personal, pushes to green.

因此，开发人员从“绿色”中拉动，推向个人，TeamCity 从个人构建，推向绿色。

This blog postshows the basic model we are using, with GitHub forks for the personal repositories (using forks means that the number of repositories doesn't get out of hand and end up costing more, and means that the developers can manage the personal builds, as they can fork and then create the team city build jobs to get their code pushed to 'green'):

这篇博文展示了我们正在使用的基本模型，个人存储库的 GitHub 分支（使用分支意味着存储库的数量不会失控并最终花费更多，并且意味着开发人员可以管理个人构建，因为他们可以分叉，然后创建团队城市构建工作以将他们的代码推送到“绿色”）：

This is more work to set up in TeamCity as each developer has to have their own build configuration. Which actually has to be 2 configurations as TeamCity seems to execute all build steps (including the final 'push to green' step) even if the previous build steps fail (like the tests :)), which meant that we had to have a personal build for the developer, then a another build config which was dependent on that, which would just do the push assuming the build worked.

这是在 TeamCity 中设置的更多工作，因为每个开发人员都必须拥有自己的构建配置。这实际上必须是 2 个配置，因为 TeamCity 似乎执行所有构建步骤（包括最后的“推动绿色”步骤），即使之前的构建步骤失败（如测试 :)），这意味着我们必须有一个个人为开发人员构建，然后是另一个依赖于它的构建配置，假设构建成功，它只会执行推送。

回答by soninob

Check out Verigreen- A lightweight, server side gated check-in system. It verifies each commit before it finds its way into the branches the system protects. Verigreen will not allow any failed CI commit to break the integration, release, or any branch that need be protected. Moreover – it's a free, open-source project.

查看Verigreen- 一个轻量级的服务器端门控登记系统。它在找到进入系统保护的分支之前验证每个提交。Verigreen 不允许任何失败的 CI 提交破坏集成、发布或任何需要保护的分支。此外 - 它是一个免费的开源项目。

How it works: Verigreen intercepts check-ins and runs verification in an ad-hoc branch - so that in case of failed commit, only the relevant developer is affected.

工作原理：Verigreen 拦截签入并在临时分支中运行验证 - 这样在提交失败的情况下，只有相关的开发人员会受到影响。

• A pre-receive hook intercepts and creates an ad-hoc branch of the code.
• Verification is run via a Jenkins job. The verification job content is fully configurable.
• The verified code is merged back into the protected branch whereas a failed commit is blocked with a notification sent to the developer.

• 预接收钩子拦截并创建代码的临时分支。
• 验证通过 Jenkins 作业运行。验证作业内容是完全可配置的。
• 验证过的代码被合并回受保护的分支，而失败的提交会被发送给开发人员的通知阻止。

Decisions are made based on the following flow:

决策基于以下流程：

For more information, please see the wikior Verigreen.iosite

有关更多信息，请参阅wiki或Verigreen.io站点

回答by Stanislav

I think that after October 23, 2013the answer can be - Automatic Merge in TeamCity.

我认为在2013 年 10 月 23 日之后，答案可以是 - TeamCity 中的自动合并。

回答by Buck Hodges

With VS Team Services (fka Visual Studio Online) and TFS 2015 or newer you can use branch policies requiring a passing buildfor a pull request as a gated checkin workflow with Git.

借助 VS Team Services (fka Visual Studio Online) 和 TFS 2015 或更高版本，您可以使用需要为拉取请求传递构建的分支策略作为 Git 的门控签入工作流。

回答by kan

git has different philosophy - commits are easy, commit as you wish. If something wrong, you can change it later. And merges are easy. So, you could organize a appropriate workflow, e.g. developer(s) could commit in a separate branch(es). When a branch is tested, it could be merged into a main branch.

git 有不同的哲学——提交很容易，随心所欲地提交。如果有问题，您可以稍后更改。合并很容易。因此，您可以组织适当的工作流程，例如开发人员可以在单独的分支中提交。当一个分支被测试时，它可以合并到一个主分支中。

回答by MrHinsh - Martin Hinshelwood

Why not use TFS as the central repository and make use of GIT as a local DVCS solution?

为什么不使用 TFS 作为中央存储库并使用 GIT 作为本地 DVCS 解决方案？

This would allow you to build and commit locally and then push what you want to the TFS server and do a gated build.

这将允许您在本地构建和提交，然后将您想要的内容推送到 TFS 服务器并进行门控构建。

Sometimes it is good to have the best of both worlds...

有时两全其美是件好事......