Git Integration Manager Workflow

Git Integration Manager Workflow


Git is the de-facto distributed versioning control system and we have been extensively using it for variety of projects. Being distributed, it is important to have a proper workflow to ensure developers productivity and code quality so that work in progress items are not committed by accident. Fortunately, Git provides few distributed workflow patterns from simple to complex.

Different types of Workflow Patterns

  • Centralized Workflow
  • Integration Manager Workflow
  • Dictator and Lieutenants Workflow

We have adopted the Integration Manager workflow with slight changes to ensure more quality and responsibility as part of our configuration management practices. We would recommend to check Distributed Workflow to get an idea of different distributed workflow patterns.

Use Case

We will set up Integration Manager Workflow (IMW) with 2 developers and 1 integration manager scenario.

What we want to do:

  • Pre-requisites
  • Explain what changes have we made to IMW
  • Set up bare blessed repository
  • Set up developers bare and integration repository
  • Create developers working repository (private repo) from their bare repository
  • Integration Manager starts branch merges



  • This blog uses Git version 1.7.0 or higher and Ubuntu. There are many references out there on how to install Git on various platforms.
  • One of the good reference is from
  • Verify:
    • Download the Avro core and tools into a directory
    • Run Avro Tools jar to see what’s included

Explain what changes have we made to IMW

  • How does Integration Manager Workflow work?


    • The integration manager clones the integration repository from the blessed repository
    • The integration manager creates bare repository (developer public) for each develop
    • The integration manager creates remote on his repository to each of the developer’s bare repository, and pushes specific branches
    • Each developer will clone their bare repository and pushes their branches to their bare, and notifies the integration manager
    • The integration manager pulls developer’s changes to his repository, resolves conflicts, and pushes the changes to blessed repository
    • Each developer will pull the changes from the blessed repository to get all developers changes.
  • How do we do it?

Work flow

    • Everything is same as the above except the integration manager is responsible for syncing blessed and developer’s public repository instead of developers pulling the changes from the blessed repository directly.
    • This ensures single responsibility principle and also protects the blessed repository for any accidental merges from the developers.
    • The blessed repository is hosted in more secured instance and only the integration manager has access to.

Set up bare blessed repository

  • Create a bare blessed repository
  • Create a sample working directory and push the master to blessed repo

Set up developers bare and integration repository

  • Set up Developers bare repository:
    • Developer1:
    •  Developer2:
  • Set up Integration manager repository:

Create developers working repository (private repo) from their bare repository

The below commands are executed by the developers while working on any feature or bug fix on their local machine.

  • Clone the developer’s bare repository
  • Switch to master branch and create a new branch
  • Perform difference before staging the files and add/commit the files
  • Push the branch to developer’s bare repository
  • Inform the integration manager about the push and provide the branch name

Integration Manager starts branch merges

  • Go to the cloned directory and switch to appropriate branch.
  • Pull new changes from the remote repository to get any new changes before applying developer’s changes
  • Pull changes from each developer’s bare repository. Perform the above steps between each developer’s merge to keep in sync. Resolve any merge conflicts with the team members as necessary
  • Merge the changes to the master branch.
  • Push the changes to the remote destination branch.
  • Push master to all developer’s bare repository


  • Git is very flexible and well suited for distributed versioning control system with well known distributed workflow patterns.
  • The workflow patterns can be tweaked a bit as we did to ensure that developers don’t access the blessed repository directly and causing accidental commits but have the integration manager responsible for the branch merges.
  • The integration manager is not a specialized person but a project lead and also a developer who knows a bigger picture of the project than the other developers.
  • Git has been working great for us and moved many subversion based repositories to Git, and using integration manager workflow extensively.


7380 Views 11 Views Today
  • Guest

    Is this missing the final git push origin master after git push [developer_name] master?

    • Treselle Systems Blog

      “git push origin master” is done in last but one step under the heading “Push the changes to the remote destination branch”