Come posso visualizzare in anteprima un'unione in git?

Ho un ramo git (la linea principale, per esempio) e voglio unirmi in un altro ramo di sviluppo. O io?

Per decidere se voglio davvero unire questo ramo, vorrei vedere una sorta di anteprima di ciò che farà l'unione. Preferibilmente con la possibilità di vedere l'elenco dei commit che vengono applicati.

Finora, il meglio che posso inventare è merge --no-ff --no-commit, e quindi diff HEAD.

Ho scoperto che la soluzione che funziona meglio per me è semplicemente eseguire l'unione e interromperla in caso di conflitti . Questa sintassi particolare mi sembra pulita e semplice. Questa è la strategia 2 di seguito.

Tuttavia, se vuoi assicurarti di non confondere il tuo ramo attuale, o non sei pronto a unirti a prescindere dall'esistenza di conflitti, crea semplicemente un nuovo ramo secondario da esso e unisci che:

Strategia 1: il modo sicuro - unire un ramo temporaneo:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

In questo modo puoi semplicemente buttare via il ramo temporaneo se vuoi solo vedere quali sono i conflitti. Non devi preoccuparti di "interrompere" l'unione e puoi tornare al tuo lavoro - semplicemente controlla di nuovo "mybranch" e non avrai alcun codice unito o unisci conflitti nel tuo ramo.

Questo è fondamentalmente una corsa a secco.

Strategia 2: quando vuoi assolutamente unirti, ma solo se non ci sono conflitti

git checkout mybranch
git merge some-other-branch

Se git segnala conflitti (e SOLO SE SONO PRESENTI conflitti) puoi quindi fare:

git merge --abort

Se l'unione ha esito positivo, non è possibile interromperla (reimpostare solo).

Se non sei pronto per unirti, usa il modo più sicuro sopra.

[EDIT: 2016-Nov - Ho scambiato la strategia 1 per 2, perché sembra che la maggior parte delle persone stia cercando "il modo sicuro". La strategia 2 ora è più di una nota che puoi semplicemente interrompere l'unione se l'unione ha conflitti che non sei pronto per affrontare. Tieni presente se leggi i commenti!]

• git log ..otherbranch
  • elenco di modifiche che verranno unite nel ramo corrente.
• git diff ...otherbranch
  • diff da antenato comune (base di unione) alla testa di ciò che verrà unito. Nota i tre punti , che hanno un significato speciale rispetto ai due punti (vedi sotto).
• gitk ...otherbranch
  • rappresentazione grafica dei rami da quando sono stati fusi l'ultima volta.

La stringa vuota implica HEAD, quindi ecco perché ..otherbranchinvece di HEAD..otherbranch.

I due punti rispetto ai tre hanno un significato leggermente diverso per diff rispetto ai comandi che elencano le revisioni (log, gitk ecc.). Per log e altri due punti ( a..b) significano tutto ciò che è dentro bma non ae tre punti ( a...b) indicano tutto ciò che è solo in uno ao b. Ma diff funziona con due revisioni e lì il caso più semplice rappresentato da due punti ( a..b) è una differenza semplice da aa be tre punti ( a...b) differenza media tra antenato comune e b( git diff $(git merge-base a b)..b).

Se sei come me, stai cercando l'equivalente di svn update -n. Quanto segue sembra fare il trucco. Nota che assicurati di fare un git fetchprimo in modo che il tuo repository locale abbia gli aggiornamenti appropriati con cui confrontare.

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

o se vuoi un diff dalla tua testa al telecomando:

$ git fetch origin
$ git diff origin/master

IMO questa soluzione è molto più semplice e meno soggetta a errori (e quindi molto meno rischiosa) rispetto alla soluzione migliore che propone "unisci e poi interrompi".

La maggior parte delle risposte qui richiede una directory di lavoro pulita e più passaggi interattivi (non valido per gli script) o non funziona per tutti i casi, ad esempio fusioni passate che portano già alcune delle modifiche in sospeso nel ramo di destinazione o ciliegie che eseguono il stesso.

Per vedere veramente cosa cambierebbe nel masterramo se ti fossi unito developin esso, proprio ora:

git merge-tree $(git merge-base master develop) master develop

Poiché è un comando idraulico, non indovina cosa intendi, devi essere esplicito. Inoltre non colora l'output né usa il tuo cercapersone, quindi il comando completo sarebbe:

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

- https://git.seveas.net/previewing-a-merge-result.html

(grazie a David Normington per il link)

PS:

Se si ottengono conflitti di unione, questi verranno visualizzati con i soliti indicatori di conflitto nell'output, ad esempio:

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

L'utente @dreftymac ha un buon punto: questo lo rende inadatto per gli script, perché non è possibile individuarlo facilmente dal codice di stato. I marker di conflitto possono essere abbastanza diversi a seconda delle circostanze (cancellati vs modificati, ecc.), Il che rende difficile anche il grep. Attenzione.

Se hai già recuperato le modifiche, il mio preferito è:

git log ...@{u}

Ciò ha bisogno di git 1.7.x credo però. La @{u}notazione è una "scorciatoia" per il ramo a monte, quindi è un po 'più versatile di git log ...origin/master.

Nota: se usi zsh e l'estensione estesa del glog, probabilmente dovrai fare qualcosa del tipo:

git log ...@\{u\}

Aggiungendo alle risposte esistenti, è possibile creare un alias per mostrare il diff e / o il registro prima di un'unione. Molte risposte omettono il fetchda fare prima di "visualizzare in anteprima" l'unione; questo è un alias che combina questi due passaggi in uno (emulando qualcosa di simile a quello di mercurial hg incoming/ outgoing)

Quindi, basandosi su " git log ..otherbranch", puoi aggiungere quanto segue a ~/.gitconfig:

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

Per simmetria, il seguente alias può essere utilizzato per mostrare ciò che è stato impegnato e verrebbe spinto, prima di spingere:

    # what would be pushed (currently committed)
    outgoing = log @{u}..

E quindi puoi eseguire " git incoming" per mostrare molte modifiche, o " git incoming -p" per mostrare la patch (cioè, "diff"), " git incoming --pretty=oneline", per un sommario sintetico, ecc. Puoi quindi (facoltativamente) eseguire " git pull" su fondersi davvero. (Tuttavia, poiché hai già recuperato, l'unione potrebbe essere fatta direttamente.)

Allo stesso modo, " git outgoing" mostra cosa verrebbe spinto se dovessi correre " git push".

git log currentbranch..otherbranchti darà l'elenco dei commit che andranno nel ramo corrente se fai una fusione. I soliti argomenti da registrare che forniscono dettagli sugli commit ti daranno maggiori informazioni.

git diff currentbranch otherbranchti darà la differenza tra i due commit che diventeranno uno. Questo sarà un diff che ti darà tutto ciò che verrà unito.

Questi aiuterebbero?

Richiesta pull: ho usato la maggior parte delle idee già inviate, ma una che utilizzo spesso è (soprattutto se proviene da un altro sviluppatore) fare una richiesta pull che offre un modo pratico per rivedere tutte le modifiche in una fusione prima che posto. So che GitHub non è git ma sicuramente è utile.

A meno che non si esegua effettivamente l'unione a un tiro di schioppo (vedi la risposta di Kasapo), non sembra esserci un modo affidabile per vederlo.

Detto questo, ecco un metodo che si avvicina leggermente:

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

Ciò fornisce un'equa indicazione di quali impegni faranno parte della fusione. Per vedere le differenze, aggiungi -p. Per visualizzare i nomi dei file, aggiungere qualsiasi --raw, --stat, --name-only, --name-status.

Il problema con l' git diff TARGET_BRANCH...SOURCE_BRANCHapproccio (vedi la risposta di Jan Hudec) è che vedrai differenze per le modifiche già nel tuo ramo di destinazione se il tuo ramo di origine contiene unioni incrociate.

Forse questo può aiutarti? git-diff-tree - Confronta il contenuto e la modalità dei BLOB trovati tramite due oggetti ad albero

Non voglio usare il comando git merge come precursore per la revisione di file in conflitto. Non voglio fare un'unione, voglio identificare potenziali problemi prima di unirmi - problemi che l'auto-fusione potrebbe nascondermi. La soluzione che stavo cercando è come fare in modo che git sputi un elenco di file che sono stati cambiati in entrambi i rami che verranno uniti in futuro, rispetto ad alcuni antenati comuni. Una volta che ho quell'elenco, posso usare altri strumenti di confronto dei file per esplorare ulteriormente le cose. Ho cercato più volte e non ho ancora trovato quello che voglio in un comando git nativo.

Ecco la mia soluzione alternativa, nel caso in cui aiuti chiunque altro là fuori:

In questo scenario ho un ramo chiamato QA che presenta molti cambiamenti dall'ultima versione di produzione. La nostra ultima versione di produzione è taggata con "15.20.1". Ho un altro ramo di sviluppo chiamato new_stuff che voglio unire nel ramo QA. Sia QA che new_stuff indicano che "seguono" (come riportato da Gitk) il tag 15.20.1.

git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_files

Ecco alcune discussioni che hanno colpito il motivo per cui sono interessato a scegliere come target questi file specifici:

Come posso fidarmi di Git Merge?

/software/199780/how-far-do-you-trust-automerge