Por que você não confirmava alterações mescladas imediatamente?

Meu escritório usa Git e SourceTree para nosso controle de versão. Isso aconteceu porque quando entrei havia zero controle de versão e o SourceTree era o único sistema que eu já havia usado. Eu não sou um especialista de forma alguma, mas sou o mais experiente dos meus colegas de trabalho, por isso sou o especialista de fato responsável por ensinar a todos a usar o Git corretamente e corrigir os erros que estão cometendo.

Estou fazendo um documento tutorial que passa pelo Git e SourceTree e explica todas as etapas do processo. No processo Pull, a caixa de diálogo SourceTree permite selecionar a opção "Confirmar alterações mescladas imediatamente". Eu entendo o que isso faz e por que é útil. O que eu não entendo é por que alguém não gostaria de usar esse recurso.

Alguém poderia explicar por que você nunca gostaria que suas alterações mescladas fossem confirmadas automaticamente? Estou tentando entender o raciocínio para poder explicar melhor a utilidade do recurso e ter uma idéia de quais armadilhas devem ser observadas no futuro.

Editar: não acredito que minha pergunta seja uma duplicata da pergunta vinculada. A questão vinculada está perguntando amplamente com que frequência se comprometer. Estou perguntando por que alguém escolheria não usar um recurso específico relacionado ao comprometimento de mesclagens no SourceTree.

Eu não gostaria de usar esse recurso.

O fato de não haver conflitos significa que as alterações que estão sendo mescladas em minha ramificação não estão aproximadamente nas mesmas linhas de código que as que eu fiz. Isso não significa que essas alterações são compatíveis com as minhas alterações. Isso não significa que o código será compilado, ou que o código funcionará, ou que os testes serão aprovados.

Em outras palavras, ao usar esta opção, eu acabo potencialmente com um commit espúrio de código que pode não estar em bom estado e requer um novo commit para corrigir. Como estou fazendo esse trabalho de qualquer maneira, e como nunca devo enviar esse commit espúrio a montante, nem mesmo por engano (Deus me livre, alguém pode então mesclar isso em algum outro ramo!), Não vejo razão para criar esse commit no primeiro Lugar, colocar.

Após uma mesclagem, pode haver alterações nos arquivos no repositório local. Essas alterações não são confirmadas automaticamente no local, a menos que você defina "Confirmar alterações mescladas imediatamente".

Se você não definir essa opção, os arquivos aparecerão no SourceTree como alterações não confirmadas.

Isso ocorre porque o próprio Git não confirma, a menos que você o explique explicitamente, e o SourceTree é uma GUI do Git. O "Commit mudanças incorporadas imediatamente" opção não é tanto uma opção, já que é um atalho de comando.

Portanto, o motivo para não querer usar esse recurso é evidente: você deseja executar a confirmação manualmente ou não.

Digamos que você puxe o mestre para o seu ramo de recursos. Um colega de trabalho está trabalhando em um ramo de recurso diferente. Este colega de trabalho tem um histórico de quebrar coisas. A mesclagem contém alterações no código comum compartilhado feitas por esse colega de trabalho. Portanto, você - junto com o restante da equipe - não comete alterações mescladas até ter certeza de que não há alterações feitas por esse colega de trabalho que afetarão seu trabalho.

Só porque não há uma boa razão - em teoria - para não usar esse recurso, na realidade, pode haver várias boas razões. No que diz respeito ao seu tutorial, eu diria apenas que "99 vezes em 100, esta é a opção que você deseja usar". Eu não acho que você realmente precise entrar em detalhes sobre não usá-lo, especialmente se os outros são novos no controle de versão. Tudo isso depende de quão profundo você pretende que o tutorial seja.

Se você estiver usando um gancho de confirmação de postagem para enviar automaticamente suas confirmações (como em /programming//a/7925891/6781678 ), poderá ser necessária esta opção para evitar enviar alguma confirmação de qualidade duvidosa.

Eu nunca usaria também.