GIT – Walkthrough the Integration Manager Workflow

Many people switching from Subversion to GIT wonder about the somewhat different workflow. When it comes to collaboration, Subversion users are used to a centralized workflow where we have a single dedicated central repository. In such a scenario, all developers have read and write access to that one central repository. The main issue with this is that a single user committing  buggy code has a heavy impact on all other developers (Of course, you can always revert, but it has cost us so much time and has happened so often that avoiding this is the much better choice) . Hence, it would be much better, if we could have more than a single central repository, in particular, one central repository per developer – to share every developer’s code – plus one main repository, to which write access is granted to an integration manager only. This will prevent the main repository being smashed by buggy code.

In the GIT universe, the latter scenario is referred to as “Integration-Manager Workflow” and the main repository is named “blessed” repository. We found that this workflow is extremely useful. Still, whenever a new member used to Subversion enters our team, he runs into heavy issues. Apparently, it is easier to start a workflow from scratch than to switch from another workflow.

In this article, we will walk through the Integration-Manager Workflow. As always, this is not a tutorial or even a manual. There are excellent documents on the web that explain GIT concepts in details (e.g. a free eBook “ProGit” and an exhausting tutorial by the GIT team). Here, we assume that you are familiar with GIT, branches and local and remote repositories. Also, we assume that you know how to access local and remote repositories.

In the scenario described here it is assumed that we have a local user developing on his own machine while he has access to a remote workstation hosting GIT repositories available to the rest of the team members. Such a scenario is shown in Fig. 1. Since the remote workstation is located in the cloud, we heavily recommend using ssh for communication. As show, the developer has only read access to the blessed repository, while full access is granted to him to his own repository:

GIT - Infrastructure diagram of the integration manager workflow

Fig. 1: Infrastructure diagram of the integration manager workflow

This walkthrough starts at the point, where you have cloned your own remote repository (or created a remote repository from your own). Fig. 2 shows the typical use case where the local developer fulfills two main task: 1. Get changes from the main (blessed) remote repository and 2. Send his changes to his own remote repository to make them available to other developers and, in particular, to the integration manager:

GIT - Integration Manager Use case

Fig. 2: GIT Integration Manager Use case

The integration manager’s workflow is not part of this article. Here, we focus on the local developer’s view and, thus, on the two use cases 1. “Get changes from main remote” (i.e. from the blessed repository) and 2. “Send changes to own remote”.

First, let’s have a look at the shorter “Send changes to own remote” use case. This is, where the user has carried out some changes, preferably in some non-master branches, merged them successfully into his master branch and now wants to share his success with other users. A combination the the two git commands commit and push will do it:

git commit -a -m "What I have done"
git push ssh://user@remote.srv/remoterepo.git
GIT - BPMN notation showing how to push to a remote repository

Fig. 3: GIT - BPMN notation showing how to push to a remote repository

However, in order to get changes from the blessed repository, it turned out that, for the secure daily work, changes should not be pulled to the master branch. Rather than that, a temporary branch should be created and switched to before pulling.

git remote add remoterepo ssh://user@remote.srv/remoterepo.git
git branch temp
git checkout temp
git pull ssh://user@remote.srv/remoterepo.git
git checkout master

Remember that the first command is required only once. Many developers new to this workflow have expressed their lack of understanding what’s behind those commands. Hopefully, the process shown in Fig. 4 may help:

GIT - BPMN notation showing how to pull from a blessed repository

Fig. 4: GIT - BPMN notation showing how to pull from a blessed repository

And that’s it, that’s all the magic. Using these two processes, we have totally decoupled developer’s from one another, i.e. the insufficiency of one does no harm to the others.

There are, of course, other ways to carry out these use cases, for example git fetch with a subsequent git merge into the master branch. For us, the git fetch workflow turned out to be more time consuming than a trial-and-error pull into a temporary branch, since in most cases, there is no need to review changes. In case there should be a need to do so, pulling into a temporary branch will reveal this necessity.


One thought on “GIT – Walkthrough the Integration Manager Workflow

  1. Pingback: GIT – Walkthrough the Integration Manager Workflow

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s