Diciamo che abbiamo la seguente situazione in Git:

1. Un repository creato:

   mkdir GitTest2
   cd GitTest2
   git init
   

2. Alcune modifiche nel master avvengono e si impegnano:

   echo "On Master" > file
   git commit -a -m "Initial commit"
   

3. Feature1 branched master e alcuni lavori sono stati eseguiti:

   git branch feature1
   git checkout feature1
   echo "Feature1" > featureFile
   git commit -a -m "Commit for feature1"
   

4. Nel frattempo, viene rilevato un bug nel codice master e viene stabilito un ramo hotfix:

   git checkout master
   git branch hotfix1
   git checkout hotfix1
   

5. Il bug viene corretto nel ramo hotfix e riunito nuovamente nel master (forse dopo una richiesta pull / revisione del codice):

   echo "Bugfix" > bugfixFile
   git commit -a -m "Bugfix Commit"
   git checkout master
   git merge --no-ff hotfix1
   

6. Lo sviluppo su feature1 continua:

   git checkout feature1
   

Supponiamo che abbia bisogno dell'aggiornamento rapido nel mio ramo delle funzionalità, forse perché il bug si verifica anche lì. Come posso raggiungere questo obiettivo senza duplicare gli commit nel ramo delle mie funzioni?

Voglio impedire di ottenere due nuovi commit sul mio ramo di funzionalità che non hanno alcuna relazione con l'implementazione della funzione. Ciò sembra particolarmente importante per me se utilizzo le richieste pull: tutti questi commit saranno inclusi anche nella richiesta pull e dovranno essere rivisti anche se ciò è già stato fatto (poiché l'aggiornamento rapido è già presente nel master).

Non posso fare un git merge master --ff-only: "fatale: impossibile avanzare velocemente, abortire", ma non sono sicuro che questo mi abbia aiutato.

Come uniamo il ramo principale nel ramo della caratteristica? Facile:

git checkout feature1
git merge master

Non ha senso forzare una fusione in avanti veloce qui, poiché non può essere fatto. È stato eseguito il commit sia nel ramo funzionalità che nel ramo principale. L'avanzamento veloce è impossibile ora.

Dai un'occhiata a GitFlow . È un modello di ramificazione per git che può essere seguito, e inconsciamente lo hai già fatto. È anche un'estensione di Git che aggiunge alcuni comandi per i nuovi passaggi del flusso di lavoro che fanno automaticamente cose che altrimenti dovresti fare manualmente.

Quindi cosa hai fatto nel tuo flusso di lavoro? Hai due rami con cui lavorare, il tuo ramo feature1 è sostanzialmente il ramo "sviluppo" nel modello GitFlow.

È stato creato un ramo hotfix dal master e lo si è unito indietro. E ora sei bloccato.

Il modello GitFlow richiede di unire l'hotfix anche al ramo di sviluppo, che è "feature1" nel tuo caso.

Quindi la vera risposta sarebbe:

git checkout feature1
git merge --no-ff hotfix1

Ciò aggiunge tutte le modifiche apportate all'interno dell'aggiornamento rapido al ramo della funzionalità, ma solo quelle modifiche. Potrebbero entrare in conflitto con altri cambiamenti di sviluppo nel ramo, ma non entreranno in conflitto con il ramo principale se alla fine dovessi unire nuovamente il ramo della funzione al ramo principale.

Fai molta attenzione al rebasing. Rifare solo se le modifiche apportate sono rimaste locali nel proprio repository, ad esempio se non si è spostato alcun ramo in un altro repository. Rebasing è un ottimo strumento per te per organizzare i tuoi impegni locali in un ordine utile prima di spingerlo fuori nel mondo, ma in seguito il rebasing rovinerà le cose per i principianti git come te.

Dovresti essere in grado di rifare il tuo ramo sul master:

git checkout feature1
git rebase master

Gestisci tutti i conflitti che si presentano. Quando arrivi ai commit con le correzioni dei bug (già in master), Git dirà che non ci sono state modifiche e che forse sono già state applicate. Quindi continui il rebase (saltando i commit già nel master) con

git rebase --skip

Se esegui un comando git logsul ramo della tua funzione, vedrai apparire il commit dei bug solo una volta e nella parte principale.

Per una discussione più dettagliata, dai un'occhiata alla documentazione del libro Git su git rebase( https://git-scm.com/docs/git-rebase ) che tratta questo esatto caso d'uso.

================ Modifica per contesto aggiuntivo ====================

Questa risposta è stata fornita specificamente per la domanda posta da @theomega, tenendo conto della sua situazione particolare. Nota questa parte:

Voglio impedire [...] il commit nel mio ramo di funzionalità che non ha alcuna relazione con l'implementazione della funzione.

Rebasing del suo ramo privato su master è esattamente ciò che produrrà quel risultato. Al contrario, la fusione di master nel suo ramo farebbe esattamente ciò che in particolare non vuole accadere : aggiungere un commit che non è correlato all'implementazione delle funzionalità su cui sta lavorando tramite il suo ramo.

Per indirizzare gli utenti che leggono il titolo della domanda, saltare il contenuto e il contesto effettivi della domanda, quindi leggere solo la risposta principale alla cieca supponendo che si applichi sempre al loro (diverso) caso d'uso, permettimi di elaborare:

• rifare solo le filiali private (ovvero che esistono solo nel repository locale e non sono state condivise con altri). Rebasing delle filiali condivise "spezzerebbe" le copie che altre persone potrebbero avere.
• se vuoi integrare le modifiche da un ramo (sia esso master o un altro ramo) in un ramo che è pubblico (ad es. hai spinto il ramo per aprire una richiesta pull, ma ora ci sono conflitti con il master e devi aggiornare il tuo ramo per risolvere quei conflitti) dovrai fonderli (ad es. con git merge mastercome nella risposta di @ Sven).
• puoi anche unire le filiali nelle tue filiali private locali se questa è la tua preferenza, ma tieni presente che si tradurrà in impegni "esteri" nella tua filiale.

Infine, se non sei soddisfatto del fatto che questa risposta non sia la migliore per la tua situazione anche se era per @theomega, aggiungere un commento qui sotto non sarà particolarmente utile: non controllo quale risposta è selezionata, fa solo @theomega.

Sulla base di questo articolo , dovresti:

• creare un nuovo ramo basato sulla nuova versione di master

  git branch -b newmaster

• unisci il tuo vecchio ramo di funzionalità in uno nuovo

  git checkout newmaster

• risolvere i conflitti sul nuovo ramo di funzionalità

I primi due comandi possono essere combinati a git checkout -b newmaster .

In questo modo la cronologia rimane chiara perché non hai bisogno di fusioni posteriori. E non devi essere così cauto poiché non devi fare un rebase di Git.

git merge

puoi seguire i passaggi seguenti

1. unione origin/masterramo a featureramo

# step1: change branch to master, and pull to update all commits
$ git checkout master
$ git pull

# step2: change branch to target, and pull to update commits
$ git checkout feature
$ git pull

# step3: merge master to feature(⚠️ current is feature branch)
$ git merge master

2. merge featureramo in origin/masterramo

origin/masterè il ramo principale remoto, mentre masterè il ramo principale locale

$ git checkout master
$ git pull origin/master

$ git merge feature
$ git push origin/master

La risposta di Zimi descrive questo processo in generale. Ecco i dettagli:

1. Crea e passa a un nuovo ramo. Assicurarsi che il nuovo ramo sia basato in mastermodo da includere gli aggiornamenti rapidi recenti.

   git checkout master
   git branch feature1_new
   git checkout feature1_new
   
   # Or, combined into one command:
   git checkout -b feature1_new master
   

2. Dopo essere passati al nuovo ramo, unisci le modifiche dal ramo di funzionalità esistente. Ciò aggiungerà i tuoi commit senza duplicare i commit di hotfix.

   git merge feature1
   

3. Nel nuovo ramo, risolvere eventuali conflitti tra la funzionalità e il ramo principale.

Fatto! Ora usa il nuovo ramo per continuare a sviluppare la tua funzionalità.

Ecco uno script che puoi utilizzare per unire il tuo ramo principale al ramo corrente.

Lo script procede come segue:

• Passa al ramo principale
• Tira il ramo principale
• Torna al ramo corrente
• Unisce il ramo principale nel ramo corrente

Salvare questo codice come file batch (.bat) e posizionare lo script in qualsiasi punto del repository. Quindi fai clic su di esso per eseguirlo e sei pronto.

:: This batch file pulls current master and merges into current branch

@echo off

:: Option to use the batch file outside the repo and pass the repo path as an arg
set repoPath=%1
cd %repoPath%

FOR /F "tokens=*" %%g IN ('git rev-parse --abbrev-ref HEAD') do (SET currentBranch=%%g)

echo current branch is %currentBranch%
echo switching to master
git checkout master
echo.
echo pulling origin master
git pull origin master
echo.
echo switching back to %currentBranch%
git checkout %currentBranch%
echo.
echo attemting merge master into %currentBranch%
git merge master
echo.
echo script finished successfully
PAUSE

Potresti essere in grado di eseguire una "selezione" per estrarre i commit esatti di cui hai bisogno nel ramo della funzione.

Fare un git checkout hotfix1per ottenere il ramo hotfix1. Quindi fai un git logper ottenere l'hash SHA-1 (grande sequenza di lettere e numeri casuali che identifica in modo univoco un commit) del commit in questione. Copia quello (oi primi 10 caratteri circa).

Quindi, git checkout feature1per tornare al ramo delle funzionalità.

Poi, git cherry-pick <the SHA-1 hash that you just copied>

Questo attirerà quel commit, e solo quel commit, nel tuo ramo di funzionalità. Quel cambiamento sarà nel ramo - lo hai semplicemente "selezionato". Quindi, riprendi il lavoro, modifica, impegna, spingi, ecc. Al contenuto del tuo cuore.

Quando, alla fine, esegui un'altra unione da un ramo al ramo della tua funzione (o viceversa), Git riconoscerà che ti sei già unito a quel particolare commit, sapendo che non è necessario farlo di nuovo, e semplicemente "salta".

Sono nel ramo delle funzionalità e ho effettuato i refactoring. Voglio unire le modifiche principali ora al mio ramo di funzionalità. Sono molto indietro. Nota Non voglio trasferire le modifiche principali al mio locale perché il mio ramo di funzionalità ha i moduli spostati da una posizione all'altra. Ho scoperto che esibirsi di seguito senza pull non funziona. dice "Già aggiornato."

 //below does not get the latest from remote master to my local feature branch without git pull
    git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge master

Questo sotto funziona, nota usa git merge origin / master:

 git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge origin/master