I was looking through some old material and I found some git tips I presented at the the Haverhill Hackers Meetup during one of the “lighting talks” meetups. I originally put them in a gist, but feel it would be helpful to others to post here. Enjoy!

Alias git and common commands

• at a minimum, alias g="git", it’s a tool you use all the time save those keystrokes!
• go further, alias common commands: ga="git add", gst="git status", gc="git commit", etc
• if you use zsh, the oh-my-zshconfiguration framework has tons of aliases for git(and other
• things) if you don’t want to take a whole framework, you can checkout the aliases it sets here https://github.com/robbyrussell/oh-my-zsh/wiki/Cheatsheet#git

Use git stash or WIP commit messages when changing branches

• git stash is a quick way to just put some changes to the side when you need to change the focus of your work
• if you’re already on your own branch, nothing is stoping you from creating a commit with these changes and noting its WIP
• if you go with the WIP commit message remember to reset or amend that commit so your commmit message can mean something

Setup your .gitconfig to use a personal email address(even at work)

• https://help.github.com/articles/setting-your-email-in-git/ (applies to bitbucket as well)
• Why?
• open source commits will no longer show up for your (GitHub/BitBucket/etc) account if you don’t have access to that email
• if you leave that job, future developers have a path to contact you if the need arise
• if that bothers you, at least set it globally to your personal email and then change the local config per project to be your work email

Use a global .gitignore

• put common OS related files that get generated in here
• put common language/framework/tool related files that get generated
• do this in addition to local a ignore file because you have the added protection of not commiting garbage that other developers may have missed if they setup the ignore file

Try out git plugins for your IDE or text editor of choice

• most should have a plugin for git commands or at a minimum to show that a line has changed in the git history
• I use vim + vim-fugitive -
• https://github.com/tpope/vim-fugitive
• I mostly use it for git diff and git blame with quick shortcuts to access them

Bonus

• store your .gitconfig and .gitignore in source control(hopefully with your other dotfiles)
• check out git rebase if you like that style of working with commit history
• create custom commands by adding them to your git config like this nifty command to remove a branch locally and remotely: nuke-branch = !sh -c 'git branch -D $1 && git push origin :$1' -

I recently gave a talk at the Haverhill Hackers Meetup about “real refactoring” where I went through a few refactorings I had made in our codebase at QueueDr. The examples were dumbed down a bit for simplicity sake, but the motivations and changes made were clearly displayed. The talk went well and I think those who attended(including myself!) learned a few tricks to bring into their own codebases.

When you start a new project and you are the only developer working on it the possibilities seem endless. No worrying about other hands getting into the codebase and messing everything up. No dealing with shitty legacy code. Then a funny thing happens. Your hands get into the codebase and mess everything up. Your code becomes the shitty legacy code you feared. You quickly realize that you are capable of all the things you complain about, and that completely fine.

Business happens. We rush things, skip testing, and write horrible hacks(that we intend to fix sooner and not later). Outside pressures have a direct effect on code quality. At the end of the day though, having something working and shipped today is far better than something perfect weeks/months/years from now. All code can end up being legacy code, even if you wrote it.

This is why refactoring has to be part of your process even if you are the only one touching the code. It’s unrealistic to think you’ll write everything the way it should be the first time around. So, put on your refactoring hat and get going. Start small. There is no need to be afraid and become paralyzed at the thought of embarking on this refactoring journey, no matter how horrible the codebase has become. It’ll be worth it.

Never stop improving, tweaking, and assessing your development process. I think we often get stuck in a certain setup and fear changing it. For example, I often find myself using my mouse while in vim even though I know I shouldn’t. I know I could easily disable the use of the mouse in my .vimrc, but I fear it will slow down my flow. That’s bullshit. I should take the time to learn my tools and improve my skills on a daily basis, not just when it’s convenient. It’s never going to be convenient. So, improve now and never stop.