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.
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:
Make sure you’re using SSH to connect to Github. See instructions here.
Check that everything is committed on
MYBRANCHand push (to ensure everything is backed up remotely).
git checkout MYBRANCH git status git push origin MYBRANCH
MYBRANCHfrom the old repository into the
devbranch of the new repository.
git push firstname.lastname@example.org:ORGANIZATION/NEWREPO.git MYBRANCH:dev
Checkout the new code.
cd MY_CODE_DIRECTORY git clone email@example.com:Sasa-Development/<REPO>.git git checkout dev
Create a new branch to start feature development
git checkout -b MYFEATURE dev
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
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.