Git Is Communication • With your colleagues • With your clients • With your future or parallel self • A stored conversation about the history of a code base
Write Good Commit Messages • Short first line (less than 50 chars) in the present imperative tense.
• “change” not “changes” • A blank line: • Body, wrapped to less than 80 chars, that provides more information about the commit.
• Describe what applying the change will do, not what was done to create the change.
Example Fixes issue #X in production This change uses a algorithm Y which is faster than than W. - I’m using a bullet point, for a list of changes. - I usually don’t need to list the changed files.
Git Is Not A Silver Bullet
Help Git to Help You • Merge conflicts can still happen. Small commits that affect minimum subsets are easier to manage.
• Git is not a substitute for project management. If
many changes are happening to the same place in the same file, there will be conflicts.
• Branches are cheap. Tags are cheap. Don’t be tempted to clean history too often.
• Multiple repositories as backups are a good idea.
Git Allows History To Be Rewritten
“Git is evil because it lets you change history”
Changing History Is Bad When…
• You change the history of any branch that somebody else is likely to have cloned and made changes to.
Changing History Is Not Bad When… • You are on a local branch that is not shared with anybody else.
• You are on a branch that is synced with a private repository that only you use.
• You roll up your list of small individual commits on
your working branch into a larger atomic commit that you then push.
• rebase is your friend. Seriously.
Reflog Is Your Lifeguard • Every change to HEAD is recorded.
• State can be
reconstructed using the shas.
Avoid pulling changes • Use `git fetch` and then inspect the upstream changes.
• Use `git remote update` to fetch changes if the repository has multiple remotes.
• Merge or rebase onto a temporary branch if you aren’t sure if the changes will apply cleanly.
Risks • Inexperienced team members (or clients) may mess up the repository.
• History may be lost. • It could become hard to track development / test / production branches.
Protections • You don’t need to use every bit of git: add, push,
commit, pull, fetch, checkout, status, are usually enough to get started
• Git objects are immutable, changes are not irrevocable. Errors can be corrected.
• Well named branches and a set of conventions are a great help.
• Make people care, and they will care. Everyone wants to do a good job.
Git Flow • github.com/nvie/gitflow • datasift.github.io/gitflow • A set of scripts and workflows to define branching and merging.
• Not everyone’s cup of tea but it helps when getting used to version control in a team.
Git Does Not Require Branches To Be Related
Independent Branches
• I’m sure you’ve seen the gh-pages feature on github • `git checkout --orphan `
Branches Are Cheap • Never be afraid to create a branch. They are cheap. • Use some sort of naming convention so that you don’t get confused about them.
• You can create a description for a branch • git branch --edit-description • If you want to park a branch - Create an annotated tag with a description.
Related Branches • Keep the main code in one branch. • Create a separate branch for a demo that uses the main code.
• Use rebase liberally when only one branch is being used for development, but be sure to make it clear which the non-development branch is.
• Use `cherry-pick` if changes are made in both branches.