Nerding in Nairobi

A few months travelling, living and hacking in Kenya

Splitting git branches into repos

Soko asked me to look at their current git workflow and suggest any improvements and best practices. They specifically pointed to the fact that they’re currently using branches of a single repository to hold completely separate codebases for different apps. I also noticed that all development occurs on these individual branches with no additional branching for feature development and testing.

I think Vincent Driessen does a great job describing good git practices and the Soko team will move in this direction long term. For now, I suggested that the team move to a model that uses a master branch reflecting the latest production code, a dev branch to stage features and fixes for production and feature branches for all development work. We talked about the idea behind hotfix and release branches but will hold off on using them until the team size and complexity grows.

Splitting Branches

The first step was to split the branches in a single repo into separate repos for each of the 4 apps. Today at 11AM East Africa Time the entire team committed their code and joined a Skype call to execute the split. Each team member was assigned a branch/app and took the following steps:

  1. Make sure you’re using SSH to connect to Github. See instructions here.

  2. Check that everything is committed on MYBRANCH and push (to ensure everything is backed up remotely).

     git checkout MYBRANCH
     git status
     git push origin MYBRANCH
  3. Push MYBRANCH from the old repository into the dev branch of the new repository.

     git push MYBRANCH:dev
  4. Checkout the new code.

     git clone<REPO>.git
     git checkout dev
  5. Create a new branch to start feature development

     git checkout -b MYFEATURE dev
  6. Before merging into master for the first time, create the branch

     git fetch origin master 
     # The fetch should FAIL indicating that no one else has created a master branch
     git checkout -b master dev

Development Workflow

The split process retained all of the commit history and got the team ready to start using the new master/dev/feature branch workflow. The old repository is now deprecated completely and should never need to be touched. Going forward the team will use the following merge process for most of the workflow across their repos.

  • Merge a feature into dev:

      git checkout dev
      git pull origin dev
      git merge --no-ff <FEATURE>
      git push origin dev
  • Merge a feature into master for deployment into production:

      git checkout master
      git merge --no-ff dev
      git push origin master
      # Delete any feature branch you don't need anymore
      git branch -d MYFEATURE


Splitting up separate codebases into their own repos allows us to get much more branch-happy without becoming disorganized and selectively share apps with contractors. All of that branching should make it easier for the team to work concurrently on different features in one app and deploy only tested code into production. Over the next few weeks we hope to move towards faster deploy cycles with the team working concurrently on different parts of the ecommerce front end.