Table of Content
- 1 Introduction
- 2 Use Case
- 3 Solution
- 4 Conclusion
- 5 References
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.
We will set up Integration Manager Workflow (IMW) with 2 developers and 1 integration manager scenario.
What we want to do:
- 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 http://git-scm.com/book/en/Getting-Started-Installing-Git
- Download the Avro core and tools into a directory
- Run Avro Tools jar to see what’s included
12$ git –versiongit version 18.104.22.168
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?
- 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
123$ mkdir blessed_repo.git$ cd blessed_repo.git$ git –bare init
- Create a sample working directory and push the master to blessed repo
12345678$ mkdir sample_project$ cd sample_project$ git – init$ vi sample.txt$ git add .$ git commit –m “Initial Project commit”$ git remote add origin firstname.lastname@example.org:/opt/projects/blessed_repo.git$ git push origin master
Set up developers bare and integration repository
- Set up Developers bare repository:
1234$ mkdir developer1.git$ cd developer1.git$ git –bare init$ cd ..
123$ mkdir developer2.git$ cd developer2.git$ git –bare init
- Set up Integration manager repository:
123456$ git clone email@example.com:/opt/projects/blessed_repo.git integration_repo$ cd integration_repo$ git remote add developer1 firstname.lastname@example.org:/opt/projects/developer1.git$ git remote add developer2 email@example.com:/opt/projects/developer2.git$ git push developer1 master$ git push developer2 master
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
123$ git clone firstname.lastname@example.org:/opt/projects/developer1.git developer1_working$ cd developer1_working$ git branch -r
- Switch to master branch and create a new branch
123$ gitbranch –r -> Verify available branches$ git checkout master -> Switch to master branch$ git checkout –b “[feature_name]” -> Creates new branch from master
- Perform difference before staging the files and add/commit the files
123456$ git diff -> To make sure only the differences will reflect$ git status -> To check the status to know staged/unstaged/modified files$ git add file_name -> add individual files instead of git add .$ git status$ git commit –m “commit message” -> use meaningful commit messages$ git log -> verify the commit is displayed
- Push the branch to developer’s bare repository
12$ git remote –v -> To make sure the origin points to developer’s repository$ git push origin [feature_name]
- 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.
123$ cd integration_repo$ git branch$ git checkout master
- Pull new changes from the remote repository to get any new changes before applying developer’s changes
123git remote –v -> To make sure the origin points to actual remote blessed repositorygit pull origin mastergit log
- 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
1234$ git branch –D merge -> Delete already existing merge branch$ git checkout –b merge$ git pull [developer_name] [feature_name]-> Resolve any conflicts$ git log -> Verify developer’s commit log is displayed
- Merge the changes to the master branch.
1234$ git checkout master$ git pull origin master$ git merge merge ->Merge the changes in the merge branch$ git log -> To make sure the developer’s commit is displayed
- Push the changes to the remote destination branch.
1git push origin master
- Push master to all developer’s bare repository
12$ git pull origin master$ git push [developer_name] master
- 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.
- Distributed Workflows: http://rypress.com/tutorials/git/distributed-workflows.html
- Git Workflow Patterns: http://training-course-material.com/training/Git_-_Workflow_Patterns