Why would you not commit merged changes immediately?

Question

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.

Edit: I do not believe my question is a duplicate of the linked question. The linked question is broadly asking how often to commit. I am asking about why one would choose not to use a specific feature related to commiting merges in SourceTree.

Answer 1

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.

Answer 2

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.

Answer 3

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.