Integrazione di indentazione e modifiche dei contenuti in Git durante l'unione: best practice?

Question

Sto usando Git per tracciare qualche codice MATLAB. Un esempio di giocattolo illustra meglio il problema. Il progetto finora sembra così.

C 
/
A-- 
    \ 
    B 

contenuto di A sono x=5

Facciamo commettere C, dove la linea viene modificato in x=6

Abbiamo poi facciamo commettere B, dove il nostro contenuto diventa come di seguito

if flag==1 
    x=5 
end 

Se tentiamo un'unione con l'obiettivo del progetto che assomiglia a

con il risultato di unione in D, otterremo un conflitto, perché la riga principale è stata modificata in entrambi (il rientro aggiunto in B, 5 è cambiato in 6 in C).

Esiste un modo migliore per integrare le modifiche all'indentazione da un ramo e le modifiche del contenuto da un altro ramo per ottenere un risultato di unione?

Ho letto su una strategia in https://stackoverflow.com/a/5262473/288545 e, mentre ciò eviterebbe il conflitto, eliminerebbe il rientro a favore della modifica del contenuto (che è un miglioramento, ma rende ancora più difficile leggere il codice).

Suppongo che potrei semplicemente risucchiarlo e non cambiare indentazione durante la scrittura del mio codice. Questo lo rende meno leggibile, ma non è un grosso problema in MATLAB. Comunque, in Python, l'indentazione conta davvero, quindi come si comportano le persone di Python? Questo diventa molto più brutto se ci sono grandi blocchi di codice che in seguito cambiamo per essere all'interno delle strutture di controllo, quindi la differenza tocca molte linee e rende i conflitti di fusione un enorme mal di testa.

Esiste una strategia di unione che gestirà separatamente le modifiche di spaziatura e le modifiche del contenuto e quindi le integrerà? Mi piacerebbe il risultato della fusione di essere

if flag==1 
    x=6 
end 

Answer 1

La chiave per risolvere il tuo problema è il trattamento ripuliture di spaziatura e la funzione riscrive commit come separati.

Come qualcuno che fa un sacco di integrazione di filiali, posso dire onestamente che le due cose più fastidiose per gli integratori sono: 1) i codificatori che desiderano riformattare i file che non hanno autore o funzioni che non hanno riscritto, e 2) IDE che riformattano interi file semplicemente aprendoli e salvandoli. Certo, i file sono più leggibili in entrambi i casi, ma sconfigge completamente il punto di controllo della versione: i commit devono essere dimensionati, costruiti e revisionati in modo intelligente. Il loro ordine dovrebbe avere un significato. Il lavello della cucina commette una storia inutile, e la storia non dovrebbe essere altro che utile.

Questa filosofia implica "Non scaricare le modifiche dello spazio bianco nei commit in cui non appartengono". Se stai riscrivendo la funzione toccata, certo, migliora la spaziatura. Altrimenti lasciatelo al proprio commit e assicuratevi che gli altri che lavorano su quel file sappiano che i cambiamenti dello spazio bianco stanno arrivando. Ciò ti farà risparmiare fastidi durante l'integrazione.

Inoltre, è possibile evitare errori casuali degli spazi bianchi (spazi finali, tabulazioni dopo spazi e simili) con il gancio di pre-commit di git.Emettere questo comando nel vostro archivio per configurarlo:

mv .git/hooks/pre-commit.sample .git/hooks/pre-commit 

E 'più o meno problemi git diff --check, che è anche incredibilmente utile per rilevare questi tipi di problemi.

Answer 2

Alcuni strumenti diff sono migliori di altri. Io uso KDiff3 e ho impostato per essere invocato automaticamente usando git mergetool. Non è ancora perfetto, ma può spesso rilevare le fusioni del tipo che descrivi e produrre automaticamente un'unione sensata.