Quando si uniscono i file sarà utile (come per me) mostrare un autore di ogni riga. C'è qualche strumento di diff o di fusione che lo supporta?Strumento di unione/diff che può mostrare autori (supporta la colpa o annotazione) nei file sotto controllo di versione
No. E, credo, non sarà mai - quando ci uniamo, pensiamo contenuto, non la paternità
Così che cosa si vuole veramente è uno strumento che può facilmente identificare le modifiche rispetto ad di altri cambiamenti in un conflitto di fusione, piuttosto in realtà identificare l'autore di ogni riga (che sarebbe un mezzo per ottenere ciò), giusto?
Se ho capito bene, ho alcune notizie relativamente buone: Si può fare con git + kdiff3. Per la fusione è sufficiente utilizzare git mergetool (che è possibile configurare per utilizzare kdiff3). Ma non è supportato in modo nativo se si verifica un conflitto di merge quando si esegue il rebase interattivo, quindi per quello è necessario uno script manuale.
Invece di creare il mio semplice esempio di conflitto di unione, userò http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/ come base. Segui quella pagina per git merge test. Da dopo il comando di unione divergo un po 'da quell'esempio eseguendo diversi comandi (ma fondamentalmente facendo lo stesso lavoro). Prima farò tutti i passaggi del manuall.
quindi abbiamo un conflitto di unione e Git ha inserita contenuti provenienti da entrambe le fonti che contribuiscono nel file in questo formato <<<<<<<...>>>>>>>, che davvero non mi piace a tutti e non considero nemmeno guardarlo. Invece io uso il mio strumento di fusione preferito, kdiff3.
Per prima cosa dobbiamo trovare quali versioni sono coinvolte.
$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1 README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2 README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3 README
$
imbastito che le informazioni si può eseguire una stampa a tre vie:
$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$
che dà la seguente vista in cui è possibile selezionare da cui antenato si desidera unire da.
Afterwords (se si è soddisfatti del risultato di fusione) è necessario
$ rm v1 v2 v3
$ mv merge_result README
$ git add README
vengono eseguite automaticamente tutte le fasi manuali di cui sopra con git mergetool. Allora perché mostrare tutto questo allora? Bene, perché se si ottiene un conflitto corrispondente durante git rebase -i, allora deve essere fatto in questo modo (prima di eseguire git rebase --continue).
In questo piccolo esempio c'è solo un conflitto linea, in modo che non mostra il caso più tipico dove un sacco di linee vengono risolti automaticamente, lasciando a poco risolvere manualmente i quelli che non è stato fatto automaticamente. Un altro esempio di vita reale potrebbe essere più simile al seguente:
Si noti che nel risultato di fusione voi ora vedere chiaramente l'origine dei C linee che sono stati risolti automaticamente. Penso che questo sia un po 'quello che stavi chiedendo quando chiedi di ottenere l'autore per ogni riga, giusto? Queste informazioni sono completamente assenti nel testo <<<<<<<...>>>>>>> (ed è difficile/impossibile individuare che è necessario aggiornare la stringa stampata nella funzione ciao).
Non posso raccomandare abbastanza kdiff3. Utilizzando uno strumento di fusione grafico simile a quello di alcune linee di entrambe le fonti, il file in linea nel file è come utilizzare uno excavator rispetto a uno spade.
Lo strumento gitk in bundle non è realmente uno strumento di unione, ma mostra linee in conflitto con rosso e blu e "+" di fronte, e puoi Rightclick -> "Mostra origine di questa linea" su qualsiasi di esse , per andare al commit che ha introdotto la linea:
è possibile eseguire il mergetool, o semplicemente un editor di testo con diffmarks in parallelo
sono d'accordo, ma in alcuni casi può essere utile. Ad esempio, c'è un file sorgente in cui aggiungo del codice. Lascia che il file sia stato modificato sul repository mentre stavo facendo delle modifiche. Quindi, ho bisogno di unirlo, ma tutto ciò di cui ho bisogno è aggiungere solo le mie modifiche. Sarà più facile localizzarli quando saranno firmati. – ASten
@ASten: in questo caso, è sufficiente vedere il file "mio" in merge-window (e lo strumento di unione deve definire titoli Windows separati) –
Quando si uniscono i conflitti, il livello di controllo viene quasi sempre regolato in base all'anzianità dell'autore. Questo non è l'ideale, ma i vincoli temporali spesso lo richiedono. – bartekbrak