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:
Git log with three fix-bad-merge commits in a row

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.
SourceTree commit dialog offers a checkbox to push automatically; uncheck 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.

About Sharon Cichelli

I am a Principal Technical Lead at Headspring, developing enterprise-changing software and coaching teams to deliver value without death marches. I am a .NET developer, open-source contributor, user group organizer, technical blogger, pinball fan, and Arduino enthusiast.
This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • SourceTree’s interactive rebase tool is surprisingly slick, too, for the less consolely-inclined in need of a bigger clean-up.
    You can right-click on a commit and select “rebase children of X interactively…” and it gives you a nice menu for removing, combining, and re-messaging the subsequent commits.

    • scichelli

      Ooh, nice to know. Thanks.

    • ziplock9000

      It’s never, ever, works for me. I always get errors.

  • Alper

    This presented an opportunity for coaching vs saying “Actually, you’re doing it wrong”. The attitude of an experienced developer makes a huge difference.

    • scichelli

      Aw, thanks. Trying to pay it forward for all the mentors who never made _me_ feel dumb.

  • Matt

    I used amend for the first time yesterday thanks to Sharon.

  • OrangeKing89

    Isn’t half of the point of source control to have a backup of your code on a different system?

    Yes if you push your changes immediately you can’t amend your commits if you forget something but if the commit is on;y on your computer it is no safer than when it is not committed at all.

    At my work we have a setup to each person works on their own code branch and if you need to get what someone else has written you pull their branch so we don’t have to worry about our commit breaking the build for someone else.

    If it were easier I would prefer to have a source control client that automatically generated a commit and push every time I saved a file.

    • Nicholas Easler

      I think that’s a bad habit to get into. If you commit every time you change a file it makes it very difficult to cherry pick a change atomically or to make sense of what the developer was doing by looking at the commit history. Better to only commit when you have code that compiles, passes tests, and represents a logical chunk of changes. Nothing makes your stomach sink like finding out production’s broken and seeing a hundred “WIP” commits while investigating the cause.

  • zhuravl

    Btw, SourceTree for Windows just sucks… Unfortunately. It’s so beautiful for Mac. So I used Ungit for the last couple of years and loved it!