CTL git workflow

Here at the CTL, we run git as our version control system to patch and update the Blogs@Baruch code.

Currently our workflow process is fairly linear: there is an update to a plugin or theme, a new theme needs to be deployed, a patch needs to be applied. It gets added to the codebase and pushed out.

Our GitHub repository hosts multiple branches for this project, including the master branch, development branches, and production branches. The most recent production branch (which is named the date that it was finalized, ie., november-26-2014) should be exactly the same as the master branch. This is for workflow and backup purposes.

The second attempt to map our CTL git workflow
The second attempt to map our CTL git workflow

Each of our developers has their own local cloned instance of the Blogs@Baruch codebase on their computer. This is where our workflow will begin.

[Note: anything in italics below is placeholder text that needs to be replaced with the actual branch name from the git repository]



1. Checkout the most-recently-dated-branch from origin repository to the local system:

          git fetch origin
          git checkout –b most-recently-dated-branch origin/most-recently-dated-branch

Or, if the local files have changes that need to be overwritten by the production files:

          git fetch origin
          git reset --hard origin/most-recently-dated-branch
          git checkout –b most-recently-dated-branch origin/most-recently-dated-branch

2. Checkout a new development branch from the most-recently-dated branch on local

(naming convention is a descriptive title prepended by dev-, ie., dev-pluginupdates)

          git checkout –b dev-branch

3. Checkout a features branch from the local development branch. Each feature being added or updated should have its own branch.

(the reason for this extra step is to make future changes to our workflow more intuitive)

          git checkout –b feature-branch

4. Make changes on the local system files and test them locally (as much as is possible on a local environment)

5. Merge the features branch into the local development branch. Make sure to give a clear commit message explaining the changes.

          git add path/to/changed/file
          git commit -m "Informative message describing the changes"
          git checkout dev-branch
          git merge feature-branch

6. Push the local development branch to the origin repository

          git push origin dev-branch 

*If only a minor change (like a typo), branch a local new-dated production branch from the local development branch, and push to the repository

          git checkout -b new-dated-branch 
          git push origin new-dated-branch



1. Checkout the most-recently-dated branch to the staging server

          git fetch origin
          git checkout –b most-recently-dated origin/most-recently-dated

2. Merge the dev-branch into the staging server

          git merge origin/dev-branch

3. Test to make sure that nothing broke in the migration from your local system to the staging server.

4. If everything is OK, switch back to your local system and checkout a new-dated branch from the dev-branch, and push to the repository

          git checkout –b new-dated-branch
          git push origin new-dated-branch

If the test is not OK, reset the staging server to a working state, and delete the dev-branch from the staging server

          git reset --hard origin/most-recently-dated
          git checkout most-recently-dated
          git branch -d dev-branch

5. Delete the dev-branch on the repository

          git push origin --delete dev-branch



The master branch on the production server is live.

1.  Branch and pull the new-dated branch from the repository into master branch on the production server

          git fetch origin
          git merge origin/new-dated-branch

2. Branch a backup branch from the newly merged master branch (this branch is for quick restore purposes only and hopefully will never need to be use)

          git branch new-dated-backup

3. Push the master branch from the production server to the repository

          git push origin master


This workflow may seem needlessly complicated, given git’s powerful branching and merging capabilities. This is just a starting point workflow for us. Eventually, we will be able to modify this workflow to one that is focused more on specific features, where the development branches are not determined by release date, but but feature. This will allow us to have a less linear and more adaptable workflow where multiple features are simultaneously developed and released whenever they are ready.

Leave a Reply

Your email address will not be published. Required fields are marked *