Hitchhikers Guide to Code Development with Git
Production/Development Branches:
- “MASTER” – Always deployable working production code. Important: Never develop on this branch.
- “TEST” – Everyday you’ll be working on this branch, the development codebase. This branch will always have the latest and upcoming release cycle.
- “…..” – This branch(s) can be whatever name you wish. Its suggested they have names:
- “Feature-X” – A feature or experimental branch. Its recommended to name them as your task name or number. hence “Feature-210” or “Feature-EnhanceNavMenu”.
- “Bugfix-X” – A bugfix / code patch for known bug.
- “…..” – Anything else you wish to name your working branch.
* These branches should only be temporary. When you’re done with a branch (merged to TEST or ignoring the branch permanently), you can easily delete the branch with: git branch -D <branch name>
Daily Development Cycle:
You’ll be working on improving the codebase (feature or maintenance) or fixing a bug from TEST branch:
-
git checkout test # Switch to the TEST branch to pull the latest codebase.
-
git pull # Pull changes for all branches to see whats changed.
# For individual branch pull do: git pull origin <branch>
if you’re starting work on a new feature or bug fix, then checkout to a new branch:
- git checkout test # Make sure we’re on the TEST branch.
- git checkout -b <branch name> # Create a new branch from TEST (latest codebase).
- …. continue working on code ….
- git add . # Add all files to index to commit changes.
- git commit -a # Commit changes, this will open up the editor. (See below for commit msgs)
- git push # Push your changes to the server/team.
if you’re already working on a feature/bug branch, then checkout to it to update codebase & continue work:
- git checkout <branch name> # Switch to your existing branch.
- git rebase test
# Update / merge your branch with the latest codebase from TEST.
# Rebase will take all commits from TEST and apply to your branch codebase, then your commits within the branch will be moved to the top of the merged commits. Its called “Fast-Forwarding”.
- …. continue working on code ….
- git add . # Add all files to index to commit changes.
- git commit -a # Commit changes, this will open up the editor. (See below for commit msgs)
- git push # Push your changes to the server/team.
- …. continue working on code ….
NOTE: Before merging branches or pushing changes to the team or server, it’s important to test your application to make sure all features work correctly and/or meet test cases. * Sometimes we forget to test and users or team members suffer. *
Fixing Bugs:
Sometimes a bug is found in production code or during the release (dev) cycle. Follow these steps to fix accordingly.
If found in production and it is a major bug which prevents users from using the application/core features:
- git checkout master # Switch to MASTER branch.
- git checkout -b <Bugfix-X> # Checkout to new branch from MASTER codebase.
- …. fix bug code ….
- git commit -am “Bugfix: <desciption of bug fix / etc….>”
- git checkout master # Switch to MASTER branch.
- git merge <Bugfix-X> # Merge branch changes into MASTER branch.
- git push # Push MASTER branch codebase to server.
- git branch -D <Bugfix-X> # Delete the bugfix branch if no longer needed. If found in production and it is a minor bug (which is maybe irritating on unnoticeable by the user) then you can perform the above steps to fix or suggested to fix in the TEST branch (release cycle). If found in release cycle and it is a major or minor bug, then fix the bug and continue with release cycle. It’ll be pushed to production when all tasks are completed anyways.
Commits & Messages:
Commit messages are important and should describe your fixes, improvements, etc. You can write a brief message or detail commit that outlines important notes and possible files to look at so other team members understand how the code changes affect the partial or entire codebase.
Brief (samples):
- git commit -m “Feature 123: user is able to add comment to profile.”
- git commit -m “Bugfix 456: resolved issue with dropdown menu flickering.”
Detail (sample):
- git commit -a # Default editor will open (nano, vim, etc…) … then you type your message:
Feature 123 – User is able to add comment and assign to friends to profile.
1 – able to add dynamic comment to profile via ajax.
** able to add, edit, delete.
** able to attach friend to commit, then notifies friend via email.
2 – notify user when friends reply to their comment.
URL: http://dev.app.com/profile/1234
DB changes: new table user_comments & user_comment_notify (app/schema/user_comments.sql)
- … save in editor and git commit is done…
Your application environment should always be ready, working code and deployable. The following example is an effortless and plain setup and release cycle, from development to production changes.
Server Environment:
There should be at least three environment setups:
- LIVE – Production code, the real application directory. Should point to git branch “MASTER”.
Document Root: /var/www/app_live/
- TEST – Testing environment, QA server / etc. Should point to git branch “TEST”.
Document Root: /var/www/app_test/
- DEV – You localhost machine. Should always develop in “test” or any other git branch except “master”.
Document Root: /Development/app/
Release Cycle Phases:
- (DEV) Pull & develop code in the “TEST” branch.
- (DEV) push your “TEST” branch changes to the server. Either the project manager or members or QA can test from here.
- (TEST) SSH into the server (app directory) and pull from the “TEST” branch. Also import any db structure updates.
- (TEST) visit the application, http://test.domain.com and test all features and updates. *record bugs*
- (TEST) if everything looks okay and testing went well, then checkout into master branch and then git merge “TEST” branch into “MASTER”, then push changes to “MASTER”.
- (LIVE) move to the production (app directory) or SSH into production server and pull the “MASTER” branch changes.
- (LIVE) for sanity check, visit the live application, http://www.domain.com and quickly test over features. Congrats, your application is now live and updated to your users.
Sit back till bugs are reported or continue next release cycle. Grab yourself a beer & go out and play !!
mitchell amihod, and 
Gregg Williams are discussing. 
A derelict ship floats in space, its troubled crew awakened from stasis with no memories of who they are or how they got on board. Their search for answers triggers the vessel’s deadly security system: a relentless android bent on their destruction. Facing threats at every turn, they have to work together to survive a voyage charged with vengeance, redemption, betrayals, and hidden secrets best left unknown.
Gregg Williams 1:33 pm on February 13, 2012 Permalink
Bless you! I’ve been pursuing the same approach to git developement, but I’m not so adept at git, and sometimes things go wrong. This is an excellent blueprint–thanks!
mitchell amihod 2:22 pm on February 13, 2012 Permalink
nice article. One change i would recommend – using the -d flag for delete. this will help people from accidentally deleting an unmerged branch.