Di recente ho imparato che quando si uniscono due rami in git, se ci sono cambiamenti su due linee adiacenti , git lo dichiara un conflitto. Ad esempio, se il file test.txtha questo contenuto:

Line 1: A
Line 2: B
Line 3: C
Line 4: D

e in ramo masterlo cambiamo in

Line 1: A
Line 2: B1
Line 3: C
Line 4: D

mentre nel ramo testinglo cambiamo in

Line 1: A
Line 2: B
Line 3: C1
Line 4: D

e quindi tenta di unirsi testingin master, git dichiara un conflitto di unione. La mia ingenua aspettativa era che la fusione sarebbe avvenuta senza conflitti e avrebbe prodotto questo:

Line 1: A
Line 2: B1
Line 3: C1
Line 4: D

Sono sicuro che c'è una buona ragione per cui git non si fonde in questo modo. Qualcuno può spiegare questo motivo?

Supponendo che questo frammento di codice

x=0
x+=1 if foo
x+=1 if bar
return x

è stato modificato in un ramo in questo

x=0
x+=1 if foo && xyzzy
x+=1 if bar
return x

e in un altro ramo in questo

x=0
x+=1 if foo
x+=1 if bar && xyzzy
return x

allora non vorrei che Git lo fondesse in questo

x=0
x+=1 if foo && xyzzy
x+=1 if bar && xyzzy
return x

senza allarmarmi.

Al fine di evitare di causare tali problemi, git di solito si rifiuta di unire automaticamente le modifiche toccando le linee vicine. Ti dà la possibilità di verificare se la logica del programma sarebbe rotta o meno.

Questo esempio è banale, ma quando si uniscono enormi rami il rischio di conflitti "logici" simili è molto più grande. A volte mi piacerebbe persino che il contesto fosse ancora più grande di quello che è attualmente.

Questo comportamento è solo git?

Dopo una discussione con un collega, ho appena provato, e SVN lo gestisce senza problemi: ottieni le 2 righe modificate.

Le funzionalità di unione di diversi VCS sono testate qui per bazar, darc, git e mercurial : https://github.com/mndrix/merge-this

Sembra che solo i darc abbiano unito con successo il caso "linee adiacenti".

L'applicazione di modifiche adiacenti ai file non è un problema difficile. Penso davvero che questo comportamento sia stato scelto apposta.

Perché qualcuno dovrebbe decidere che la modifica delle linee adiacenti produce un conflitto?

Penso che questo sia per costringerti a guardarlo .

int max = MAX_ITEMS;
for(unsigned int i = 0; i < max; i++)
    do_stuff(i);

Modif numero 1, sul master:

int max = MAX_ITEMS/2; // Do stuff only on the first half
for(unsigned int i = 0; i < max; i++)
    do_stuff(i);

Modif numero 2, unito da un ramo:

int max = MAX_ITEMS;
for(unsigned int i = 0; i < max/2; i++) // max/2: only on 1st half
    do_stuff(i);

Dopo l'unione, non vuoi che:

int max = MAX_ITEMS/2; // Do stuff only on the first half
for(unsigned int i = 0; i < max/2; i++) // max/2: only on 1st half
    do_stuff(i);

Vedendo questo comportamento come una caratteristica

È possibile trasformare il comportamento di fusione git in un vantaggio. Quando è necessario mantenere coerenti 2 righe ma non è possibile rilevarle (al momento della compilazione, all'inizio dei test o altro), è possibile provare a unirsi a esse.

Riscrivi questo ...:

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    // Need to do something else
    do_something_else(r);

...a questa:

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    do_something_else(r); // Need to do something else

Quindi quando unisci Modif 1 ...:

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i)/2; // we need only the half
    do_something_else(r); // Need to do something else

... con Modif 2 ...:

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    if(r < 0) // do_stuff can return an error
        handle_error(r);
    do_something_else(r/2); // Need to do something else

..., git produrrà un conflitto e ti costringerai a guardarlo.

Sto indovinando principalmente, ma penso che abbia a che fare con la linea 2 utilizzata come contesto per il cambio di linea 3.

Git non può semplicemente dire che "La linea con C è diventata una linea con C1" perché potrebbe esserci un'altra linea con "C", quindi dice "La linea con C, che è subito dopo l'inizio del file, la linea con A, e la linea con B, è ora C1 "

Se "la linea con B" non è più presente, allora parte del contesto viene persa e git può solo dire approssimativamente dove deve andare la nuova linea.

Le altre risposte qui sono tutte valide, ma per me questo mi è sempre sembrato un limite inutile.

Come altri hanno già detto, in questi casi non vorrai assolutamente che Git unisca le linee senza preavviso.

Ma volevo ancora l'opzione di farlo automaticamente, dopo essere stato avvertito. Così ho scritto un driver di unione git personalizzato che potrebbe unire i conflitti su linee adiacenti (o individuali) in modo interattivo:

Mi fa risparmiare un sacco di tempo, poiché gestisco un progetto in cui le persone lavorano spesso sugli stessi file e refactoring di un sacco di codice.

Lo script è disponibile su GitHub con una licenza GPLv3 +. Forse lo troverai utile:

https://github.com/paulaltin/git-subline-merge