2015-03-05 18 views
8

Quando eseguo git status, questo è quello che sto vedendo:Che cosa significa "Sei nel mezzo di una sessione am"?

$ git status 
On branch master 
Your branch is ahead of 'origin/master' by 1 commit. 
    (use "git push" to publish your local commits) 

You are in the middle of an am session. 
    (fix conflicts and then run "git am --continue") 
    (use "git am --skip" to skip this patch) 
    (use "git am --abort" to restore the original branch) 

Changes not staged for commit: 
    (use "git add <file>..." to update what will be committed) 
    (use "git checkout -- <file>..." to discard changes in working directory) 

    modified: xxx 
    modified: xxx 
    modified: xxx 

Untracked files: 
    (use "git add <file>..." to include in what will be committed) 

    xxx 

no changes added to commit (use "git add" and/or "git commit -a") 

$ git version 
git version 1.9.1 

Quindi, cio' che git sta cercando di dirmi e qual è il modo corretto per risolvere il problema?

Non so se questo è rilevante, ma usiamo e tutte le modifiche passano attraverso il processo di revisione/approvazione.

+1

Questo potrebbe essere rilevante: https://www.kernel.org/pub/software/scm/git/docs/git-am.html – nwinkler

+1

'git am --continue' non è riuscito perché i conflitti nel ramo non sono stati risolti che è requi rosso per continuare ad applicare la patch corrente, 'git am --skip' non è riuscito perché salta la patch corrente e tenta di ottenere il prossimo dalla casella di posta, ma non ci sono stati nuovi messaggi da applicare in modo che la sessione possa continuare. – AlexKey

risposta

5

risolvere i conflitti

fare un git diff per vedere se avete qualsiasi marcatore unione, come:

$ git diff hello.txt 
diff --cc hello.txt 
index 5eb9649,379bd44..0000000 
--- a/hello.txt 
+++ b/hello.txt 
@@@ -1,1 -1,1 +1,7 @@@ 
++<<<<<<< HEAD 
+Hello, master change. 
++||||||| merged common ancestors 
++Hello, Original. 
++======= 
+ Hello, branch b1 change. 
++>>>>>>> b1 

caso contrario, provare e riapplicare git am con l'opzione -3: git am -3

Se si dispone, fare, ad esempio utilizzando kdiff3 (Windows o Linux), git mergetool --tool=kdiff3. Che lancerà uno strumento grafico che consente di scegliere tra local, base and remote

+--------------------------------+ 
| BASE | LOCAL  | REMOTE | 
+--------------------------------+ 
|    MERGED    | 
+--------------------------------+ 

http://tedfelix.com/software/git-mergetool-kdiff3.png

Con:

  • LOCAL: Un file temporaneo che contiene il contenuto del file sul ramo corrente.
  • BASE: un file temporaneo contenente la base comune per l'unione.
  • REMOTE: un file temporaneo contenente il contenuto del file da unire.
  • MERGED: il file contenente i contrassegni di conflitto.

Lo git am --continue deve essere eseguito solo quando lo stato git non segnala alcun file nonstage.

Vedi di più con Git Conflict Resolution da Ted Felix: ha questo pratico sommario:

  1. usare "-3" Sempre con "git am" per essere sicuri di ottenere marcatori di conflitto.
  2. Utilizzare "git status" e "git diff" per scoprire cosa è andato storto.
  3. risolvere i conflitti con uno dei seguenti metodi:
    • Modificare ogni file in conflitto con il vostro editor preferito.
    • "git checkout --theirs" o "git checkout --ours".
    • "git checkout -m" per annullare la risoluzione dei conflitti su file specifici. (ATTENZIONE!)
    • "git mergetool" e uno strumento di interfaccia utente della GUI appropriato come kdiff3.
  4. "git add" i file risolti.
  5. "git am --continue" per continuare l'am.

Con Git 2.17 (Q2 2018), non dimenticate di iniziare la sessione del mattino con git git am --show-current-patch per avere una migliore visione del percorso di modificare in caso di conflitto.
Vedere "Show current git interactive rebase operation".

1

Ciò che è accaduto è che alcuni file nella struttura di lavoro sono stati modificati e hanno iniziato la sessione AM precedente (AM è un modo per applicare patch dai messaggi di posta elettronica in cui le email vengono divise per modifiche e informazioni sull'autore e quindi applicate come patch al repository).

Questo è come se avessi cambiato il file, lo avessi impegnato e poi provato a unire il cambiamento nello stesso file nelle stesse linee in base alla vecchia versione. Git semplicemente non sa quale versione di modifica è valida e quindi finisce nello stato .

Queste linee dirvi che avete un conflitto:

You are in the middle of an am session. 
    (fix conflicts and then run "git am --continue") 
    (use "git am --skip" to skip this patch) 
    (use "git am --abort" to restore the original branch) 

Ci sono diversi modi per risolvere questo tipo di conflitti, e tutti loro sono manuali. Hai bisogno di uno strumento di unione a 3 vie (puoi google per esso) che ti consenta di confrontare le modifiche e scegliere quello che vuoi mantenere. L'editor vim AFAIK ha incorporato questo strumento, ma non l'ho mai usato.

Esistono anche strumenti grafici che consentono di risolvere i conflitti in software come SourceTree o simili, ma tutto dipende da dove si trova il repository e se tali strumenti grafici sono disponibili lì.

UPD: È anche possibile annullare le modifiche alla sessione AM eseguendo git am --abort che è scritto nel messaggio. Ciò ripristinerà il ramo allo stato prima dell'inizio della sessione AM, perdendo effettivamente le informazioni sulla patch.

+0

_AM è un modo per applicare le patch dai messaggi di posta elettronica in cui le e-mail sono divise per le modifiche e le informazioni sull'autore e quindi applicate come patch al repository_ --- La pagina man collegata in OP legge la stessa descrizione, ma qual è quel * messaggio di posta elettronica *? Non ho mai collegato nulla in remoto con la posta elettronica (eccetto l'impostazione della configurazione 'user.email'). – ozbek

+0

@ozbek Questo può essere correlato a come gerrit funziona/configurato. Se il repository si trova su un server Linux e viene gestito da qualche utente (di solito 'git' user), allora è possibile inviare e-mail a questo utente o creare e-mail locali. Alcuni servizi fanno affidamento attivo su questa funzionalità Linux predefinita dell'utilizzo delle e-mail. Quindi la mia ipotesi è che Gerrit fosse configurato per usare le e-mail per accettare le patch e quindi era possibile inviare e-mail a git @ localhost con una patch. Ti consiglio di controllare la documentazione di Gerrit e la tua configurazione per capirlo. – AlexKey

1

Diamo un'occhiata a loro significati ad uno ad uno ...

su Master ramo Il tuo ramo è più avanti di 'origin/master' di 1 commit. (uso "git push" per pubblicare le commit locali)

Questo significa che hai commesso qualcosa a livello locale, ma non hanno sincronizzato con l'origine.

Locale: il repository clonato nel computer e ha iniziato a lavorarci.

origine: il repository principale da dove ogni persona può clonare.

Sei nel bel mezzo di una sessione di am.(Risolvere i conflitti e quindi eseguire "git am --continue") (uso "git am --skip" per saltare questa patch) (utilizzare "git am --abort" per ripristinare il ramo originale)

Si è nel bel mezzo di creare una patch e si sono verificati conflitti, è necessario ripristinare le cose allo stato originale (utilizzando git am --abort) o risolvere i conflitti seguendo questi passaggi.

  1. Tipo git status
  2. Controllare lo stato, se si vede i nomi di file dicendo (both modified)

  3. Aperte quei file, risolvere i conflitti mantenendo ciò che si vuole e scartando l'ciò che si fa non.

  4. questo punto aggiungere i file che si ha risolto il conflitto in digitando git add file1 file2

  5. Ora il suo tempo per continuare la sessione di

  6. Tipo git am --continue

Nel caso in cui si desidera saltare facendo questa patch type

git am --skip 

Hai avuto alcune modifiche ed eri nel bel mezzo di fare una patch di esso. Le modifiche non messo in scena per impegnarsi: (uso "git add ..." per aggiornamento quello che sarà impegnata) (uso "git checkout - ..." per cambiamenti di scarto nella directory di lavoro)

modified: xxx 
modified: xxx 
modified: xxx 

Untracked file: (uso "git add ..." per includere in quello che sarà impegnata )

xxx 

cambiamenti aggiunti a commettere (uso "git add" e/o "git commit -a")

Quindi qui git sta cercando di informarti sui file che sono stati modificati dall'ultimo commit. Quelli che erano vecchi file e hai appena cambiato qualcosa qua e là al suo interno verrà mostrato come modificato.

Quello che si vede sotto i file non tracciati sono quelli che prima non erano noti perché si tratta di nuovi file.

Procedura per risolvere questo passo

1.) Per i file non monitorate

1.1.) git add <filename1> <filename2> and so on... 

2.) Commit i file aggiunti al repository

2.1) git commit -m "Message of your choice" 

Nota

Come lei ha detto che si sta lavorando con un sistema di revisione e (Gerrit). Potresti semplicemente aggiungere una nuova patch a un commit esistente piuttosto che a un nuovo commit. Se questo è il caso è necessario fare questo

git commit --amend 

3.) Ora è il momento di spingere il codice (se si vuole)

git push 

Per Gerrit fare questo

git push review