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:
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:
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
push will do it:
git commit -a -m "What I have done" git push ssh://firstname.lastname@example.org/remoterepo.git
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://email@example.com/remoterepo.git git branch temp git checkout temp git pull ssh://firstname.lastname@example.org/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:
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.