Master your git productivityEwan JonesBlockedUnblockFollowFollowingMar 28Run gitk on your repo right now — does your commit history look like this?We all know the best practices of committing code.
Keeping a neat set of commits which explain why the commit is needed and has a purpose, not just “fix a test”.
Every commit should be a step in your development plan (that you planned before you even touched the keyboard) and should contain passing tests for that step.
This is a great way to exercise TDD and is massively helpful for anyone reviewing your code.
Here is a small list of things you can do to speed up and clean up your git usage today.
Addressing review commentsPicture this, you’ve got a beautiful git history which has about 10 small commits in it.
Someone reviews your code and points out a variable they think would be better named.
You agree and make the change at the end of your branch.
“No worries” you say to yourself, “I’ll just interactively rebase this into the right commit and no one will ever know I changed it”.
You go through the steps and :wq your vim browser.
To your horror, one commit has paused and you see the word CONFLICT has appeared all over the stdout.
What you didn’t realise is that in a later commit, you edited one of the parameters in the function call on that line and, because you’re at the end of your branch, you committed that change and you’re attempting to coerce it into your previous commit.
It’s asking you which version you want to keep and you would be forgiven for thinking in your haste “of course I need that parameter in the code” so you leave it in there.
What you also didn’t realise is that this change has now broken a test and god knows which commit you need to edit now.
If there are lots of instances of this, can be quite confusing to the reviewer.
To solve this problem, I like to use a trick of editing my commit in place rather than trying to brute force a commit into it.
To do this is simple:git rebase -i masterYou will be confronted with the usual screen, but instead of changing it to squash or fixup, put an e at the beginning of the commit line.
When the rebase gets to the commit, you should get an output similar toStopped at b4r3736dw3.
Batch task into smaller tasks for scalability.
You can amend the commit now, withgit commit –amendOnce you are satisfied with your changes, rungit rebase –continueYou can make any changes you want to the commit and it will be as if you did it at the time.
You can even do git reset HEAD~ to reset all the files and make as many commits as you want.
This is great for splitting a kraken commit up into smaller parts.
When you’re done with all your edits, you can run git rebase –continue and move through the rest of your commits.
You may still get conflicts but they’ll be a lot easier to understand.
Aliasing commandsFor those micro-productivity nerds, I recommend aliasing every command to the minimum amount of letters possible.
For the above example, it’s so satisfying to run:grbi — git rebase -i mastergcane — git commit –amend –no-editgrbc — git rebase –continuepush — git push origin 'git rev-parse –abbrev-ref HEAD' (but replace quote with backtick)This is good for speed-pushing your code to the CI server to have tests running in parrallel!.It’s good to notice when you’re typing a command a lot and instantly write it in your .
bash_profile, even if you don’t reload your shell at least it’ll be there next time!.git rev-parse is a great way of grabbing names of stuff and the docs make for great bedtime/commute reading!AutosquashIf you want to quickly fixup commits as you make them just type the followinggit commit –fixup <commit>Then when you’re done making commits, automatically squash them into the right places:git rebase -i –autosquashNaturally I have shortened this to gll (git log –oneline –decorate ) to grab the commit SHA and then gcf <commit> and grbasto squash it altogether.
Global gitignoreDo you have any files that only affect your code and no one else?.Maybe it’s editors leaving rogue files around (vim makes *.
swp and *.
swo files for open buffers).
To untrack them for only you, just make a global gitignore file located at ~/.
gitignore_global and add them there.
Then you can blame someone else when they accidentally commit the files.
I thoroughly enjoyed aliasing git blame to blame to inject a bit of sass into my coding.
If you have any git productivity tips that you think trump mine, I’d love to hear them!.No seriously, please get in touch and let me know.
.