Perché non commettere immediatamente le modifiche unite?

Il mio ufficio utilizza Git e SourceTree per il controllo delle versioni. Ciò è avvenuto perché quando mi sono iscritto non c'era controllo della versione zero e SourceTree era l'unico sistema che avessi mai usato. Non sono un esperto in alcun modo, ma sono il più esperto dei miei colleghi, quindi sono l'esperto di fatto responsabile dell'insegnamento a tutti di utilizzare Git correttamente e correggere eventuali errori che stanno facendo.

Sto realizzando un documento tutorial che attraversa Git e SourceTree e spiega ogni fase del processo. Nel processo Pull, la finestra di dialogo SourceTree consente di selezionare l'opzione "Conferma modifiche unite immediatamente". Capisco cosa fa e perché è utile. Quello che non capisco è perché qualcuno non vorrebbe usare questa funzione.

Qualcuno potrebbe spiegare perché non vorresti mai che le tue modifiche unite fossero impegnate automaticamente? Sto cercando di capire il ragionamento in modo da poter spiegare meglio l'utilità della funzione e avere un'idea di quali insidie ​​cercare in futuro.

Modifica: non credo che la mia domanda sia un duplicato della domanda collegata. La domanda collegata si sta generalmente chiedendo quanto spesso impegnarsi. Sto chiedendo perché si dovrebbe scegliere di non utilizzare una funzionalità specifica relativa al commit delle fusioni in SourceTree.

Non vorrei usare questa funzione.

Il fatto che non ci siano conflitti significa che le modifiche che vengono unite nel mio ramo non sono più o meno nelle stesse linee di codice di quelle che ho fatto. Ciò non significa che tali modifiche siano compatibili con le mie modifiche. Ciò non significa che il codice verrà compilato o che il codice funzionerà o che i test verranno superati.

In altre parole, usando questa opzione potrei finire con un commit spurio di codice che potrebbe non essere in buono stato e che richiede un nuovo commit da correggere. Come sto facendo questo lavoro in ogni modo, e come non avrei mai spingere questo spuria monte impegnarsi, nemmeno per sbaglio (bontà non voglia, qualcuno potrebbe quindi unire che in qualche altro ramo!), Non vedo alcun motivo per creare questa impegnarsi nella prima posto.

Dopo un'unione, potrebbero esserci delle modifiche ai file nel repository locale. Queste modifiche non vengono automaticamente assegnate al locale, a meno che non si imposti "Conferma modifiche unite immediatamente".

Se non si imposta tale opzione, i file vengono visualizzati in SourceTree come modifiche non impegnate.

Questo perché Git stesso non si impegna a meno che tu non lo dica esplicitamente a, e SourceTree è una GUI di Git. L' opzione "Conferma modifiche unite immediatamente" non è tanto un'opzione, ma è una scorciatoia da comando.

Quindi, il motivo per cui non si desidera utilizzare questa funzione è evidente: si desidera eseguire il commit manualmente o per niente.

Supponiamo che porti master nel ramo delle funzionalità. Un collega sta lavorando a un ramo di funzioni diverso. Questo collega ha una storia di rottura di cose. L'unione contiene modifiche al codice comune condiviso apportate da questo collega. Quindi, insieme al resto del team , non commetti modifiche unite finché non sei sicuro che non ci siano modifiche apportate da questo collega che influiranno sul tuo lavoro.

Solo perché non c'è una buona ragione - in teoria - per non usare questa funzione, in realtà, ci possono essere molte buone ragioni. Per quanto riguarda il tuo tutorial, direi semplicemente che "99 volte su 100, questa è l'opzione che vuoi usare". Non penso che tu abbia davvero bisogno di entrare nei dettagli sul non usarlo, specialmente se gli altri sono nuovi nel controllo delle versioni. Tutto dipende da quanto in profondità intendi che il tutorial sia.

Se si utilizza un hook post commit per eseguire il push automatico dei commit (come in /programming//a/7925891/6781678 ), potrebbe essere necessaria questa opzione per evitare di eseguire un commit di dubbia qualità.

Non userei nemmeno.