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.
Best Answer
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.