presentation-history-of-a-thriving-codebase

History of a Thriving Codebase

Brett Chalupa

Hi, my name is Brett.

You can follow me on Twitter @brettchalupa.

Thank you for coming out tonight!

I live in Burlington, Vermont.

I help organize the Burlington Ruby Conference. You should come!

August 1st, 2nd & 3rd http://burlingtonruby.com @btvrubyconf

I work at FullStack.

http://gofullstack.com

I am really excited to be here.

I cannot imagine working without Git.

It is a tool most of us use on a daily basis.

How often do we think about it besides when we are fighting it?

merge conflicts, amirite?

I think Git is something we should think about more often.

Here is why!

What is a thriving codebase?

A thriving codebase is under active development and in a healthy state.

a.k.a. tests are passing.

It is that project you work on from 9-5.

It is that gem you hack on when you cannot sleep.

It is code that you care about.

Let's explore how we can create and leverage our Git history to the fullest.

Crafting Your History

Commits have a lot of value.

But they are so easy to do hastily.

Your commits tell a story.

They are a journal of where your code has been.

When you are wondering 'why the heck did I make this change?' two years in the future, your commits have got your back.

When your company hires someone new and you are too busy in meetings to help, your commits have got your back.

When you take on a new client with an existing codebase, their commits have got your back*.

*In this case probably not.

When you open source your project, your commits have got your back.

When working alone, commits are pretty important.

IDK about you, but I have the _worst_ memory.

When working with a team, commits are extremely important.

It is important to think of the future when writing history.

First and foremost, you need to add the right files to your stage.

Try not to usegit add --all

Do use git add -p

It walks you through what has changed, allowing you to add or skip hunks.

git diff shows unstaged changes

git diff uses less to show changes, man less to utilize using it

git diff --cached shows staged changes

Your good friendgit statusis always helpful.

Your commits are important documentation.

Treat your commits like they matter as much as your tests.

They should explain the motivation surrounding what changed and why.

They should be intention revealing.

The best way to accomplish this is by writing Wonderful Commit Messages.

A Wonderful Commit Message follows three rules.

1. It has a concise description under 50 characters.

2. It has a summary that describes what changed and why.

3. It is written in the present tense.

Think about your future self reading it!

Let's look at some wonderful commit messages.

Have you ever done?git commit -m 'Quick change'

git commit -m is the leading cause of Lazy Commit Messages.

Try hard not to use -m, instead use -v.

git commit -v opens your default git editor for writing a wonderful commit.

There are three types of commits.

1. Progress commits

Progress commits show how devs are working through their feature.

Progress commits should be granular and specific.

Do not make sweeping progress commits.

Make your progress commits early and often.

It is much easier to squash commits than to split them.

Progress commits get squashed down into...

2. Anchor commits

Anchor commits should be Wonderful Commits.

They are the commits that will be merged into master.

They are set in stone.

3. Merge commits

Merge commits show the story of when branches got merged in.

Git allows you to rewrite history to create a better history.

You should be less concerned with maintaining a 'true' history and more concerned with creating a 'useful' history.

There are two commands that I find indispensable when working with history.

1. git commit --amend

2. git rebase -i

How many times do you make a commit but realize you forgot to write the docs?

How many times do you make a commit but realize you forgot to add that one file?

git commit --amend allows you to add changes to your stage and adjust your last commit.

Do not fear the rebase.

Embrace the rebase.

git rebase --abort

Abort quits out of the rebase, sending you back to before the rebase.

git rebase origin/master

Fix those conflicts and do not look back.

When you are ready to squash your progress commits into anchor commits, look no further than...

git rebase -i

git rebase -i origin/master

It is easier to squash commits than to separate commits.

It is possible to edit and separate commits, but you may find yourself asking if it is worth the hassle.

History of a Thriving Codebase – Hi, my name is Brett. – What is a thriving codebase?

brettchalupa