Tinker's thoughts~

About Blog GitHub

24 Jan 2014
Better management of git code bases

In this blog post I want to explain about how we manage our codebase of Enterprise Mobility platform at WSO2. One of the reasons why I want to express my opinion in the subject is because I don’t want you guys to fall into the same pitfalls I fell when we were starting off with git. I am not saying we have the best management process for git (We are getting there :) ) but the current workflow significantly increased our productivity.

Multiple Repos to rule them all

First when we got started our whole product was just another JavaScript application (JaggeryJS actually). But soon it got complicated with

Now we needed a process to manage it and after playing around with submodules and git-tree I figured git tree offered the best method.

Git repos overall view

Our current workflow has the server repo as our main repo and it is what everyone will build. It contains codebase that is regarding carbon and Jaggery modules. It also has our application repos as well. These application repos points to the master branch of each repo. When I want to get new updates from the child projects - I have to only pull the master branch inside the child project. I can go back to my server directory and commit the pulled codebase to the server codebase as updates from submodules. By having multiple projects in our workflow - dependencies created by child projects to each another is reduced.A minus point about this approach is that we have to pull changes from child projects. I’ll be address this later in the blog post. But next comes the other important aspect of git.

Branching for good

Git is nothing without it’s powerful branches. I like to quote Jeff Atwood on this -

Branching is widely misunderstood, and rarely implemented– even though branching, like versioning, lies at the very heart of source control, and thus software engineering

I like the example where he brings out the parallel world’s concept. How we did our implementation of branching was - Branch per Release. The master branch has always the latest released code. Branches are frozen once the development is stopped and we merge the development branch to master branch. When we do a General Availability release - we tag the release so that it can be retrieved at a later stage if it required to be patched for bugs.

Branching strategy

Couple of experiments I am trying out these days is the git-freeze plugin that allows us to retire a branch.

Automate it :)

With all the child projects comes the rearing. After couple of times pulling-pushing-merging becomes a headache. You start to scratch your head and wonder what command you need to do next. In our case it requires couple of additional cases.

  • Merging submodules in parent project
  • Getting new development branches from github
  • Merging development branch to master and pushing to Github

I wrote a couple of scripts that can be used inline with oh-my-zsh that helps me do all of this.

admin.zshlink
# Merge development branch to master branch
function merge_projects(){
# Path to child project
cd /Users/dulitharasangawijewantha/Development/WSO2/apps/mdm
git checkout master
git pull origin master
git merge $1
git push origin master
}
# Get updates from master for child projects in parent project
function merge_submodule(){
# Child project location in parent project
cd /Users/dulitharasangawijewantha/Development/WSO2/wso2mobile-server/products/mdm/modules/jaggery-apps/mdm
git pull origin $1
}
# Push all child projects to development branch
function pull_all_projects(){
# Path to child project
cd /Users/dulitharasangawijewantha/Development/WSO2/apps/mdm
git pull origin $1
}
# Push code from current branch to remote branch
function push_all_projects(){
# Path to child project
cd /Users/dulitharasangawijewantha/Development/WSO2/apps/mdm
git push origin $1
}
# Get the new development branch from github
function get_new_dev_branch(){
# Path to child project
cd /Users/dulitharasangawijewantha/Development/WSO2/apps/mdm
git fetch origin
git checkout remotes/origin/$1
git checkout -b $1
}

Conclusion

Thinking about how git can be better used will lead you and your team to become more productive.


Till next time mate,
Dulitha at 04:05

About Blog GitHub