This document outlines best practices for using Git for source code management. It discusses using Git to make team work on large code bases easier and produce high quality, maintainable code. Key points include committing code changes often with detailed messages, using branches for work in progress or features, and following guidelines for atomic commits and commit messages. The document also recommends a Git branching model and provides resources on commit messages and branching strategies.

1. By Greg Hermo
Practical Git

2.  Source code
 Using Git
 Commit Guidelines
 Branching
 Commit Message
 Branching Model
Outline

3. Working together on a
large code base easier,
and produce quality,
maintainable code that
will be used for years to
come
Team Work

4. The source code we produce is our greatest
asset - and it is primarily the asset that the
client pays for. From the source code, the
entire system should be constructible.
Source Code

5.  Code (Java, JavaScript, CSS, HTML etc)
 Tests
 Build scripts
 Deployment Configuration
 Deploy scripts
 Documentation
The source code is

6.  personal configuration
 IDE configuration
 compiled code
 generated code
The source code is not

7.  readable
 maintainable
 changeable
 healthy : compilable and deployable
The way we share access to our greatest asset must protect all the
attributes we list above.
Source code standards

8. Git is our version control system of choice

9.  Commit early, commit often - small, atomic commits
 Commit WIP code to branch (commit as frequently as you like)
 Remove all commented out code before committing
 Rebase from master to continue to test integration
 Commit messages should be meaningful - changing WHAT and
WHY
Commit Guidelines

10.  By atomic, I mean a set of changes that make sense together.
 A "non" atomic commit would be a form with a few fields on it
that does not do anything and can't be submitted - thereby
breaking the usability of the system.
Atomic commits

11. 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
The seven rules of a great git commit message
http://chris.beams.io/posts/git-commit/

12. Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

13. Thank you!
Questions?
@greghermo