While it’s not actually programming, working with version control is almost always a core part of your daily life as a developer. And though Git can seem intimidating at first, I would argue that being comfortable with Git can make your life as a developer a whole lot easier and pay dividends down the road when you or others might be reading through your repo’s history, undoing something, or just trying to accomplish something outside of a prototypical, happy-path Git workflow. I’ve compiled a list of tips that I believe anyone can make use of to ensure their relationship with Git remains healthy over the long run.
Patch Mode Everything
When Git basics are taught, I think it’s most common to see people demonstrate staging some code changes by typing git add some/file/name. Committing large swaths of code like this can often be problematic because, ideally, our Git histories should tell a story that someone should be able to read through and get a detailed picture of the changes. Huge file-wide commits like these can dilute a repo’s history, and it can make tracking down the original thought behind a specific commit difficult, if not impossible. To remedy this “large commits problem,” Git has what it calls “patch mode” on many commands that allow you to make changes in small “hunks.” Commands like add, commit, checkout, and reset have a -p flag which specifies that you’d like to use patch mode when stepping through code changes. This makes it so much easier to create commits, unstage commits, or check out working changes from the command line in a much more cohesive and granular way. And if you want to get really fancy, you can even manually edit a potential change yourself for maximum granularity.
While still in the spirit of having specific and detailed commits, I feel like I should touch on the value of a good commit message. Traditionally, a commit message should be 50 characters or fewer. This is important for ensuring someone can quickly scan through a commit history without having to read a novel to digest every commit. Though, occasionally, you might feel the need to add some color and provide a bit more context or justification for a commit so that others in the future (or even you!) aren’t left scratching their heads trying to figure out what’s going on in your commit. Git actually allows for an additional commit message of arbitrary length after that initially 50-character line. Most people are used to just typing git commit -m “…” when composing a commit message, but my preferred way to write a commit message is by simply typing git commit. This will take you to your default command line editor where you can then write your commit message. If you want to add your additional explanatory paragraph (or even just a quick sentence!), all you need to do is hit Enter two times after your mandatory first line and begin typing, and Git will include that second paragraph in your overall commit message. After saving and quitting out of your editor, your commit will be complete, and you’ll be able to see your long message in git log. If you just absolutely love the -m approach and hate working on a command line editor, you can just use -m twice in one command: git commit -m “my first message” -m “my longer message that provides context/explanation”. To be clear, I’m absolutely not suggesting that you need to do this two messages thing every single time you make a commit, but it is handy to have the ability to exceed that pesky 50 character limit every once in a while.
Quick Copying a Commit
This command might sound a bit scary, but I promise it’s simple. If you ever write some code, make a one-off commit, and then realize you’re on the wrong branch, it can sometimes be annoying, depending on the relative states of the branches, to have to check out the correct branch, make the exact same change in that branch, and then commit that change. Using cherry-pick makes this process a lot quicker. Just grab the hash of the commit you want to copy, and type git cherry-pick <your-hash> while on the correct branch, and that exact change will be automatically committed to that branch, assuming there are no conflicts. This is also great when digging out a fix from deep in your Git history and not wanting to tediously copy the code over manually.
Amending Commit Messages
This a quick one, but if you ever misspell something in a commit message, you can simply re-edit the most recent message by using git commit –amend. This will save you from having to reset and recommit the changes.
Saving Your Progress
If you ever need to drop all your working changes and work on a clean branch, you can always git stash, but more importantly, git stash -m will allow you to save your progress while also writing a message about what you’ve stashed for later. Trust me, you do not want to have multiple non-trivially sized stashes pushed onto the stash stack and have no idea what each of them really do. Having that list of easily readable messages is great for your peace of mind.
Aliases in Git can be handy, but they’re often not as concise and helpful as they could be since you have to type the preceding “git ” every single time you want to do a Git command. What I’ve taken to instead is simply using shell aliases so that I can slim down common commands to just a few characters. Here’s a quick list of mine, specifically for bash shell:
alias gap='git add -p'
alias gs='git status'
alias gd='git diff $1'
alias gco='git checkout $1'
alias gc='git commit $@'
alias gp='git pull'
alias gl='git log'
Wiping Your History
Have you ever committed and pushed a password or some other secret to a repo only to later realize that it really shouldn’t be living in source control at all? You should remove it, right? Yes, but even after you remove it, someone could simply look back in the Git history and see what the secret was before it had been removed, so you haven’t truly wiped the secret from your repo. In order to truly write your secret out of history, consider using BFG Repo-Cleaner: https://rtyley.github.io/bfg-repo-cleaner/
When You Stumble…
If you ever find yourself in a sticky situation with Git, a great reference I’ve found to help walk you through a potential solution is Git Pretty. It’s a mildly humorous, yet useful flowchart that will eventually lead you to the correct Git command(s) to rectify your issue.
Another resource I’ve found myself going back to every couple of years is this talk by Tim Berglund that digs a little deeper into Git internals. It’s definitely not a talk for beginners, but once you’ve become comfortable with Git, this talk is super illuminating and can make you think about Git in a whole new way.
Hopefully, these tips will make your life as a developer a bit easier. Enjoy!