Git in Enterprise – Part 2

Continuation of Git in Enterprise – part 1

Setting up a git as the source control management (scm)  in a company is about setting up your development process. Git is powerful since it distributed in nature and  gives each user the ability to change anything without worrying of the consequences. You might say no that wont be good for me, well sure it is unless you wanna get paranoid from the idea that a developer might have changed something to the one and only central repository.

So how to set it up, well there is no one way to do that but here ill describe a way that works well.

Git SCM enterprise setup

The above is a sample server scm setup. In the above illustration we have 5 repositories with different branches and the one in blue being the master branch. Each developer has the master branch (preferable) and the branches he/she is working on.

On the left, we have the central repository which is actually the master repository of the project. This repository holds the latest stable, merged, and tested code of all the development tracks (branches). You can assign a maintainer or couple of maintainers to handle merging into the master repository. Currently in git you cant specify access rights on branches (guess its a coming feature) so if you wanna assign a maintainer to a branch, verbal understanding should be enough.

On the right you see the developers (the hard-workers),  each has the master branch and the branch(s) if any he/she is working on. These repositories have write access to the developer only and read to all others. Now that we have the setup, the process that brings this all togther might look like.

Setup steps:

  1. Each developer clones the master repository and pushes to his repository
  2. Each developer fetches the branch he is to work on (if not master) and pushes it to his repository.


  • Developers: commit changes to the code and push to his repository
  • “Sr.” Developer: Review developer(s) changes, and merges the changes with his repo and pushes to his repository. Which the Developers pulls after the merge.
  • Master repository Branch Maintainer: (could be one of the above)  Review and pull changes after all looks good, and pushes to the central repository.

In this process,  changes that don’t look good can be simply ignored, reverted, or followed with another commit. And when adding a continuous build server to the master repository branches you can insure that everything is always on the right track.

Credits: most of the ideas in this post are from discussions with Sven Gothel, and setup.



Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>