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

Question

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 co

Answer 1

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

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

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

Answer 2

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.

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.

• 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.

Decisions are made based on the following flow:

For more information, please see the wiki or Verigreen.io site

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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

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'.

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

This blog post shows 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'):

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.