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?
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.
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.
When working with a team, commits are extremely important.
First and foremost, you need to add the right files to your stage.
Try not to use
git 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 --cached
shows staged changes
Your good friend
git status
is 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.
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.
Take your time with rebase and read the docs as you go.
Rebase with a pair if you can!
There is alot to Git. Here are some fun topics to dig deeper into:
Viewing Your History
Searching Your History
Resetting Your History
