Everyone needs to get into the habit of branching when they use GIT. Whether it’s a new feature, a bug fix, or a small improvement to some existing code, every ticket should get its own branch. Do some work on this branch, committing early and often (for instance, whenever your tests pass). Also make sure to use the Atomic Approach to creating commits. It shouldn’t be uncommon for you to have 10-30 commits per day.
Atomic Approach
• Commit each fix or task as a separate change
• Only commit when a block of work is complete
• Commit each layout change separately
• Joint commit for layout file, code behind file, and additional resources
The seven rules of a great Git commit message
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
Examples of poor messages (avoid these):
1. Fixed stuff
2. Whole bunch of changes
3. Minor Changes
4. Bug fix
Releasing Code
In addition, when we need to deploy code, we need to tag the release and then create a release branch. This will ensure that, in the event of a problem, we can modify the release branch without effecting the master branch.
Further Reading and Reference
For more info and details on this workflow check out these resources.
https://www.atlassian.com/agile/git
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
https://gist.github.com/digitaljhelms/4287848
https://chris.beams.io/posts/git-commit/
http://www.codelord.net/2015/03/16/bad-commit-messages-hall-of-shame/