Home/ Questions/Q 8558919
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T15:55:16+00:00

I’m looking at migrating from TFS (Team Foundation Server) to Git, but can’t find

  • 0

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

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)

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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’):

    enter image description here

    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.

    • 0