My office uses Git and SourceTree for our version control. This came about because when I joined there was zero version control and SourceTree was the only system I had ever used. I am not an expert by any means, but I am the most experienced out of my coworkers so I am the de facto expert responsible for teaching everyone to use Git properly and fix any mistakes they are making.

I am making a tutorial document that goes through Git and SourceTree and explains every step of the process. In the Pull process, the SourceTree dialogue allows you to select the option "Commit merged changes immediately". I understand what this does and why it is useful. What I don't understand is why anyone would not want to use this feature.

Could someone explain why you would ever not want to have your merged changes committed automatically? I am trying to understand the reasoning so I can explain the feature's usefulness better and get an idea of what pitfalls to look out for in the future.

  • 1
    Do you want good reasons? Because I can provide a variety of reasons to delay checking code that I've heard people say in the wild, but few of them are good reasons. Jan 19, 2018 at 21:23
  • The only reason I can think of is when a merge fails due to merge conflicts. But SourceTree won't commit if that happens anyway. Jan 19, 2018 at 21:53
  • On a side note: Why are you writing your own tutorial? bitbucket has a great tutorial already.confluence.atlassian.com/bitbucket/…
    – winkbrace
    Jan 25, 2018 at 22:19
  • @winkbrace We aren't using Bitbucket; we keep everything on a local network. I do reference Atlassian's great tutorial, but I wanted something a little more concise I could hand to people who were brand new to Git and version control. It's really more an introduction and procedural "this is how and why you commit/push/pull/etc" so people can hit the ground running.
    – David K
    Jan 26, 2018 at 12:45
  • Note: if you set pull to fast-forward, you can avoid creating these merge commits.
    – pjc50
    Sep 17, 2021 at 13:10

4 Answers 4


I would not want to use this feature.

The fact that there were no conflicts means pretty much that the changes being merged in my branch are roughly not in the same lines of code as the ones I've made. It does not mean that those changes are compatible with my changes. It does not mean that the code will compile, or that the code will work, or that the tests will pass.

In other words, by using this option I potentially end up with a spurious commit of code that may not be in a good state and which requires a new commit to fix. As I am doing this work anyways, and as I should never push this spurious commit upstream, not even by mistake (Goodness forbid, someone may then merge that into some other branch!), I see no reason to create this commit in the first place.

  • Presumably, you're creating feature branches, and not merging every little change onto the main branch. Merges are unlikely to cause conflicts on a feature branch unless multiple people are working on the same class on the same feature branch. Jan 19, 2018 at 23:57
  • 5
    @RobertHarvey Yes but I presumably frequently merge the main branch into my branch. There is a hidden assumption in your comment that different features will naturally touch different classes/modules, but not everyone is lucky. By (mis)fortune you have a God class somewhere that everyone who does anything needs to touch, and you cannot do much about it. Also there are cross-cutting features (upgrade some library because of which one of every 10 lines of code needs to change...) I know the argument "try to not get there", but what if you are already there? Better safe than sorry.
    – user285148
    Jan 20, 2018 at 0:02
  • @user285148 If you have that god class, you can reduce the number of conflicts by finding a reasonable place in the source file to add changes, not blindly at the end. So if we bith change the file, we likely change it in different places.
    – gnasher729
    Sep 18, 2021 at 8:17

After a merge, there may be changes to files in the local repo. These changes are not automatically committed to the local, unless you set "Commit merged changes immediately".

If you don't set that option, the files appear in SourceTree as uncommitted changes.

That's because Git itself doesn't commit unless you explicitly tell it to, and SourceTree is a Git GUI. The "Commit merged changes immediately" option is not so much an option, as it is a command shortcut.

So, the reason for not wanting to use this feature is self-evident: you want to perform the commit manually, or not at all.

Let's say you pull master to your feature branch. A co-worker is working on a different feature branch. This co-worker has a history of breaking things. The merge contains changes to shared common code made by this co-worker. So, you -- along with the rest of the team -- don't commit merged changes until you are sure that there are no changes made by this co-worker that will affect your work.

Just because there is no good reason -- in theory -- to not use this feature, in reality, there can be any number of good reasons. With regard to your tutorial, I would just say that "99 times out of 100, this is the option you want to use". I don't think you really need to go into detail about not using it, especially if the others are new to version control. That all depends on how in-depth you intend for the tutorial to be.


If you are using a post commit hook to auto push your commits (as in https://stackoverflow.com/a/7925891/6781678), you might need this option to avoid pushing some commit of dubious quality.

I would never use either.


You never want anything checked in that doesn’t compile. Something where X is broken (compiles, but doesn’t work) is temporarily ok for someone who doesn’t care about X right now. But a broken build means I have to take action right now if I want to do anything.

And it is quite possible that we have a conflict free merge, and the result doesn’t compile. So at the very least the changes can only be submitted if everything compiled.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.