The dangerous SourceTree setting

The messy one, at any rate.

Looking at a team’s git repository, I see the following evidence of somebody having a bad day:

Those are three commits, in rapid succession, from the same developer, trying to mash files into a compiling state. But why can I see those commits? They should have been squashed or amended to neaten them up before being pushed to the remote repo for me to pull.

This presented an opportunity for coaching, but it’s also a good reminder: If you’re using a tool other than the command line, make sure the setting to automatically push commits is turned off.

This beastie. Don’t check it.

Instead, when you need to fix a mistake, use one of the following options before pushing to the remote repo.

• In SourceTree, the “Commit options…” dropdown list to the right of the commit dialog has an option to “Amend latest commit.” You’ll be asked if you want to replace the commit text in your current dialog with the message of the previous commit. Say yes, since you’re adding a file to the previous commit that you had meant to include all along.
• If you’re using the git gui tool that’s distributed with git, there are radio buttons above the commit message so that you can select “Amend Last Commit.”
• From the command line, accomplish the equivalent rewrite with git commit --amend.
• If you’re cleaning up a bigger mess, use git rebase -i to fix up any commits that haven’t been pushed.
• And my favorite, take a calm and measured stroll through this choose-your-own-adventure-style guide to fixing commits in git.

A common theme in all of these strategies is don’t change commits you’ve pushed somewhere other developers might be using. Which is why you want to uncheck that “automatically push” setting.

Any harm in having multiple flailing attempts to fix a set of files? Not especially, but having a clean, intention-revealing history makes troubleshooting later easier, and I’ll be less likely to cluck my tongue at you.