git pro tips
TRANSCRIPT
Git Pro TipsRebase, squash, and fixup, for tomorrow we may merge
Provide as much context on your change as you can. Derek Prior asks for two paragraphs in your commit message
A big ask, but its probably only going to take you 5 minutes to write, and save the reader 30 minutes of researching
Give The Reader a Break
Good or Bad Commit Message?Fix rake db:migrate from scratch
This commit fixes a bug reported by Bindu's team. Currently, since theRake task `db:create_di_sql_views` is not versioned, it refers to the_latest_ state of the database.
This can break stuff if you've dropped your database and are migratingback up from scratch. A field referenced in the Rake task may not yetexist.
The solution we've come up with until we upgrade to Rails 4 is tocomment out earlier migrations, leaving only the most recent one.
“Cleaning”
Good or Bad Commit Message?
[#92611712] CP06 executed_at is now Time.zone.now
We had a purchase that initiated a few minutes before midnight, yetsettled after midnight on the following day. This resulted in a CP06with a transaction value from the previous day (creation date) and wasomitted from the finance_r2 export for the following day range
When a purchase record settles, DiFinanceTransaction.create_from_flubit_purchaseis called for the CP06 generation, effectively the settled at date.
The executed at time is only modified for CP06 purchases, and is notused on SH01 records. For SH01, the dispatched date is used instead
Good or Bad Commit Message?
“Merge branch 'echo'”
Good or Bad Commit Message?
“Turn it to 11 (fix stores.longitude encrypted column precision)”
Good or Bad Commit Message?
diff --git a/db/migrate/20150413183503_add_encryption_fields_to_store.rb b/db/migrate/20150413183503_add_encryption_fields_to_store.rbindex 6e5aacc..498a25f 100644--- a/db/migrate/20150413183503_add_encryption_fields_to_store.rb+++ b/db/migrate/20150413183503_add_encryption_fields_to_store.rb@@ -13,7 +13,7 @@ class AddEncryptionFieldsToStore < ActiveRecord::Migration add_column table, :encryption_migration_latitude, :string
- add_column table, :encrypted_longitude, :decimal, :precision => 10, :scale => 8+ add_column table, :encrypted_longitude, :decimal, :precision => 11, :scale => 8 add_column table, :encryption_migration_longitude, :string
Single Responsibility Principle (SRP)
Commits are free! Make lots of smaller commits instead of one big ball of mud
Try to structure a commit around one logical theme, e.g. new model, bug fix
What Makes a Good Commit?
Presentation is important. The way that you categorize and present your changes is as important as the changes themselves.
Would you rather have 10 smaller commits under cognitive load, or one commit with +312 -592 line changes?
Food For Thought
Problem: How many times have you made edits to an email, term paper, long message, or other before you sent it?
Did your recipient need to know about all of your in between edits, or just the final message?
Keeping A Clean History
Solution: Git allows you to change the past (admit it - you’ve always wanted to have this power)
Rebasing interactively allows you to introduce in between commits, delete, even combine/split separate commits
Git Rebase for a Clean History
git log -pgit add -pgit diff --stagedgit commit --amendgit stash --save
Yeah yeah, I already know this...
Quick Review of the Basics
git reset <target> (unstage file)git reset --hard HEAD@{#} (revert branch)git commit -m “squash! <SHA>”git push origin -f (careful!)git refloggit rebase <target> -i
Advanced Concepts In This Talk
We will be using rebase to tackle (almost) all of the following scenarios
e, edit = use commit, but stop for amendingr, reword = use commit, but edit the commit messages, squash = use commit, but meld into previous commitf, fixup = like "squash", but discard this commit's log message
Lets Change History
Shameless PlugI could demonstrate these scenarios anywhere, but I’m going to plug a pet project called Routastic.
http://routastic.herokuapp.com
Problem: The order of my commits should be rearranged so they make more sense
Possible solution: git rebase, reorder commits
Scenario #1 (Order)
Problem: Your commit message isn’t descriptive enough and you want to improve it
Possible Solution: git commit --amendPossible Solution: git rebase, mark commit as reword
Scenario #2 (Description)
Problem: You have made a change to a file in one commit that you are now modifying again
Possible Solution: git add -p, git commit -m “fixup! <SHA>, git rebaseNote autosquash can help here
Scenario #3 (Multiple Revisions)
Problem: Your commit is too big and you want to break it down
Possible Solution: git rebase, mark commit as edit, git reset HEAD~1, git add -p, git commit, git add -p, git commit, etc, git rebase --continue
Scenario #4 (Decomposing)
To automagically position fixup, squash messages, put this in your gitconfig
# ~/.gitconfig
[rebase] autosquash = true
Git Autosquash
Problem: You’ve committed a change to the wrong commit
Possible Solution: git rebase, mark commit as edit, git reset HEAD~1, git add -p, git commit -m “fixup <SHA>, git commit -a, git rebase --continue, git rebase
Scenario #5 (Conflation)
Interactive rebase can be used in conjunction with basic git commands to completely alter the way your feature branch looks
Use it with the objective of improving comprehensibility for those after you
Reviewing What We’ve Learned
Don’t merge your commits like this guy
Rebase before you mergeTag with annotation (git tag -a)Merge with --logMinimize merge commitsAlways review your commit structure before sharing a PR
More Git Tips
