Hide Your Fat Fingers With Git
May 21, 2020
Git used to freak me out. When I started using it to collaborate with other developers, it was a really great tool to make me feel like an idiot. For the longest time, I would fill myself with dread and a sense of impending doom every time I’d type
git into my console. But the whole point of git and online repositories is to provide a reliable backup of code for collaboration with others. I started at FinanceIt a couple of months ago, and here are a few things that I’ve learned (mostly the hard way) that might aid you in preventing a git related freakout.
- Before you
git commitanything to prepare it for being pushed up to a remote repository, always run a
git diffand make sure that the changes you’re preparing to push are the changes you want. Look for any errant
debuggerstatements, trailing whitespace, bad formatting or any other easy to fix low-hanging fruit. Do you really want other developers to know about your fat fingers? If you aren’t seeing your changes, chances are you’ve already committed them (staged them to be pushed), so pass a flag to see them:
git diff --staged. Use the command
git statusto show the current status of your working tree, and look for any files you didn’t mean to change. I usually use the VSCode version control tool called Source Control to highlight all the changes I’ve made since the last commit, looking for accidental deletions (they happen!), messy additions (like whitespace cruft), or even just to reflect on exactly what changes have stuck. The git desktop client provides similar functionality.
- When you start a new feature branch, make sure that you’re branching off of the starting branch that you intend to. It’s pretty easy to be on branch
bugfix-1, finish work on it and then forgetfully start work on branch
feature-Awithout first moving back to
master. It might not cause any issues to branch your feature off of the bug fix branch, but when someone goes to review your code they’ll likely be confused about the unrelated commits. You don’t always want to branch off of
master, but you really need to be aware of your starting point when you build a new branch with
git branch -b <name of new branch>. But it’s much more fun to learn things the hard way. To fix this mistake, the easiest solution is probably to do an interactive rebase with
git rebase -i <branch name>and delete the “pick” lines from the unwanted branch. It will be your secret.
- If you accidentally change a file while poking around in a bunch of different files trying to uncover the source of your troubles, it’s a really easy fix. From the command line, all you need to do is
git checkout master -- path/to/fileand the file will be reset to whatever it is in
master. You can choose any commit hash, it doesn’t have to be master. In VSCode source control, you can use “discard changes” (the bent arrow icon) to revert all changes to the file.
git reset --hard <commit hash>is how you abandon all your changes and go “back in time” to a commit hash (i.e.
git reset —-hard master). It is destructive, so you’ll lose all your local changes, but that’s the point right?
HEADis the last commit in the currently checked out branch, and this is resetting
HEADto a previous commit.
- If you’re working on a team, remember to merge
master(or whatever branch you’re merging into) back into your feature branch before you try to issue a pull request to merge it in. If there are any conflicts, you should be able to resolve them yourself.
git fetch origin, then
git merge origin/<branch you're merging into>.
- Take a second to make your commit messages have meaning. If you can’t easily summarize the changes you’ve made in the commit, your commit is probably too large and you should be committing more often. Keep in mind that other people will actually read those messages!
How to Revert A File That You’ve Already Pushed
If you’re like me and can write an article of what not to do and then still do a bunch of that stuff, read on. It’s a technique I recently learned on how to secretly revert a file that got accidentally changed several commits ago. Essentially what you do is create a new commit to revert the file, then
rebase your branch to re-arrange the new “fix commit” to happen right after the accidental commit. Then you
squash the two commits together. Don’t rebase and force push if other people are working on the branch, because that is just mean. Force pushing will overwrite any remote changes with your local copy, and that’s not how we make friends. But if you are the only person contributing to the branch, it should be fine.
The reason why you would want to do this kind of cleanup is because if you modify a file accidentally in a PR that has nothing to do with that file, it clutters up the git history of the file, which makes it confusing and annoying for anyone looking at the history of the file. Also, anybody reviewing your pull request will be pretty happy if they don’t have to wonder why you made changes to unrelated files.
- In your PR where the other developer really politely said “Hey, can you revert this nonsense change?”, look at the files changed tab, locate and copy the filename of your mistake.
- From the terminal on a fresh commit, use
git checkout master path/to/fileto revert those nasty changes. Run a quick
git statusto confirm that the file (and only that file) has changed.
git commit -am 'revert unwanted changes'to add the commit and give it a nice message (we’ll just delete later).
- Open the github desktop app and count how many commits back you want to rebase to. Count from the top, and include the commit you want to rebase to.
git logworks too if you don’t like pretty things.
- Back on the command line, if your number from the above step is 3, use
git rebase -i HEAD~3to interactively rebase
HEADthat many steps. Your code editor will open up.
- Move the new “revert unwanted changes” commit up to just below the commit with the unwanted change, and change it from
squash(on the left). Save and close your editor.
- Your editor will pop up again. Delete the lovely ‘revert unwanted changes’ message you just wrote, save and close. You got into this mess by not being careful, so now’s a good time to open github desktop and double check that this new commit is the one you actually want.
git push --force-with-leaseto force push your changes up to the remote repository somewhat safely, which will overwrite the remote branch with your local branch and hopefully not make you any new enemies in your organization. Don’t just
forceyour local branch onto the remote… I’ve never done that… This article explains why you should use
—-force-with-lease, but basically it’s because this way your push will (imperfectly) be rejected if anyone else has pushed to the remote branch since you pulled it, while plain
forceis like a honey badger.
Because you will inevitably still have yourself a git freakout:
- For a deeper dive into git, read this book (free).
- This page has a nice explanation of
- It’s a page called Oh Shit, Git!?! so you’re probably going to click it.
Thanks to S.Blondal for the pictures to plunder and display, and to dubroe for the lesson on rebasing.