2011-12-27 25 views
234

E 'possibile fare un "git merge", ma senza un commit?git unione senza auto commit

"man git merge", dice questo:

With --no-commit perform the merge but pretend the merge failed and do not autocommit, 
to give the user a chance to inspect and further tweak the merge result before 
committing. 

Ma quando provo ad usare git fondersi con il --no-commit ancora auto-commit. Ecco quello che ho fatto:

$> ~/git/testrepo$ git checkout master 
Switched to branch 'master' 

$> ~/git/testrepo$ git branch 
* master 
    v1.0 

$> ~/git/testrepo$ git merge --no-commit v1.0 
Updating c0c9fd2..18fa02c 
Fast-forward 
file1 | 1 + 
1 files changed, 1 insertions(+), 0 deletions(-) 

$> ~/git/testrepo$ git status 
# On branch master 
# Your branch is ahead of 'origin/master' by 1 commit. 
# 
nothing to commit (working directory clean) 

Un successivo "git log" rivela tutti i commit dal ramo v1.0 fuse in master.

risposta

385

nota l'uscita mentre si fa l'unione - si sta dicendo Fast Forward

In tali situazioni, si vuole fare:

git merge v1.0 --no-commit --no-ff 
+3

cosa succede se c'è un confitto. – Michelle

+14

@PineappleUndertheSea I forward veloci non causano mai conflitti. In caso di unione "reale" senza avanzamento veloce, l'opzione '--no-commit' è efficace solo se non si verifica alcun conflitto, in caso di conflitto git non effettuerà mai il commit automatico. – gronostaj

+17

FYI: Se vuoi unire le modifiche e poi commettere _as se avevi digitato manualmente tutte le modifiche che hai unito in_ (al contrario di un'unione tradizionale) devi eseguire 'rm.git/MERGE_HEAD' dopo, che costringerà git a dimenticare che l'unione è avvenuta. – Jonn

32

si sta fraintendendo il significato dell'unione qui, il --no-commit impedisce che MERGE COMMIT si verifichi e ciò accade solo quando si uniscono due storie di rami divergenti; nel tuo esempio non è il caso dato che git indica che si trattava di un'unione "avanti veloce" e quindi git applica solo i commit già presenti sul ramo in sequenza.

+10

Ciò non dovrebbe (imo) necessariamente chiarire la confusione; Penso che questo sia un (relativamente raro) momento in cui i documenti sono in realtà chiari: 'git help merge' =>" Con '--no-commit' esegui l'unione ma fai finta che l'unione non sia riuscita e non l'autocommit, per dare all'utente un possibilità di ispezionare e ulteriormente modificare il risultato di fusione prima di impegnarsi. " La chiave ovviamente è usarla in congiunzione con '--no-ff' – michael

+3

... forse sarebbe meno confusionario uscire dalla rigida terminologia e descriverla in questo modo: una" git merge "che fa un fast forward non È possibile eseguire un merge commit perché in realtà non esiste un'unione. Questa è in effetti la situazione ideale: i fast-forward sono una buona cosa, e non avere questo "merge commit" extra rende Senso. Questo è un buon comportamento predefinito e non dovrebbe essere disabilitato. (Nel linguaggio corretto, un avanzamento rapido è un tipo di unione, ma non è una "vera unione".) – michael

+3

è relativo alle politiche del progetto, in alcuni casi è utile avere/forzare quelle "extra" si fondono commette "anche quando è una ff perché è necessario contrassegnare l'inclusione della funzione nel ramo principale. –

12

Se si desidera solo a commettere tutti i cambiamenti in un commit come se digitato te stesso, --squash farà troppo

$ git merge --squash v1.0 
$ git commit 
+0

È lo stesso effetto di 'git merge v1.0 --no-commit --no-ff' – jpierson

+0

No, effetto diverso. Squash crea un nuovo commit con un nuovo hash. Combina tutti i commit di un ramo in un commit per l'unione. –

7

preferisco in questo modo quindi non ho bisogno di ricordare i parametri rare.

git merge branch_name 

Sarà quindi dire la vostra filiale è in vantaggio di # impegna, è ora possibile pop questi impegna fuori e metterli nei cambiamenti di lavoro con il seguente:

git reset @~# 

Per esempio, se dopo l'unione è 1 impegnarsi in anticipo, utilizzare:

git reset @~1