By Greg Hermo

Practical Git

Source code Using Git Commit Guidelines Branching Commit Message Branching Model

Outline

Working together on a large code base

easier, and produce quality,

maintainable code that will be used for

years to come

Team Work

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

Code (Java, JavaScript, CSS, HTML etc) Tests Build scripts Deployment Configuration Deploy scripts Documentation

The source code is

personal configuration IDE configuration compiled code generated code

The source code is not

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

Git is our version control system of choice

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

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

1. Separate subject from body with a blank line2. Limit the subject line to 50 characters3. Capitalize the subject line4. Do not end the subject line with a period5. Use the imperative mood in the subject line6. Wrap the body at 72 characters7. 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/

Git branching model

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

Thank you!

Questions?

@greghermo