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.
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]
LOCAL SYSTEM
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
STAGING SERVER
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
PRODUCTION SERVER
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.