Come creare il ramo da commit specifico in ramo diverso

Question

Ho effettuato diversi commit nel ramo master e li ho uniti al ramo dev.

Voglio creare un ramo da un commit specifico nel ramo dev, che è stato prima commesso nel ramo principale.

ho usato i comandi:

git checkout dev 
git branch <branch name> <commit id> 

Tuttavia, questo crea il ramo dal ramo principale, non il ramo dev che mi aspettavo. L'id di commit è lo stesso nel ramo master e nel ramo dev. Quindi, come posso distinguere lo stesso ID commit in un ramo diverso?

PS: Ho fatto un esempio in github qui https://github.com/RolandXu/test_for_branch

ho usato i comandi:

git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8 

Cosa mi aspetto è che il ramo test contiene aa.txt bb.txt cc.txt. Tuttavia, il ramo di test contiene solo aa.txt e cc.txt. Molto probabilmente ha creato il ramo dal ramo principale.

Answer 1

Se si utilizza questo modulo del comando branch (con punto iniziale), non importa dove sia lo HEAD.

Quello che state facendo:

git checkout dev 
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8 

• In primo luogo, è possibile impostare il vostro HEAD al ramo dev,

• In secondo luogo, si avvia una nuova filiale a commettere 07aeec98. Non c'è bb.txt a questo commit (secondo il repository Github).

Se si desidera avviare un nuovo ramo alla località che hai appena controllato, è possibile ramo correre senza punto di partenza:

git branch test 

o come altri hanno risposto, ramo e checkout lì in una sola operazione:

git checkout -b test 

---

penso che si potrebbe essere co nfused da quel fatto che 07aeec98 è parte del ramo dev. È vero che questo commit è un antenato di dev, le sue modifiche sono necessarie per raggiungere l'ultimo commit in dev. Tuttavia, sono altri commit necessari per raggiungere l'ultimo dev e questi non sono necessariamente nella cronologia di 07aeec98.

8480e8ae (dove è stato aggiunto bb.txt) non è ad esempio nella cronologia di 07aeec98. Se si dirama da 07aeec98, non si otterranno le modifiche introdotte da 8480e8ae.

In altre parole: se si uniscono ramo A e B ramo in ramo C, quindi creare un nuovo ramo su un commit di A, non sarà possibile ottenere le modifiche introdotte in B.

Stesso qui, è ha avuto due rami paralleli master e dev, che sono stati uniti in dev. Branching out da un commit di master (più vecchio dell'unione) non ti fornirà le modifiche di dev.

---

Se si vuole permanentemente integrare nuovi cambiamenti da padrone nella vostra caratteristica rami, si dovrebbe unire master in loro e andare avanti. Ciò creerà commit di unione nei rami delle funzionalità, però.

Se non sono stati pubblicati i rami delle funzioni, è possibile rebase anche sul master aggiornato: git rebase master featureA. Preparati a risolvere possibili conflitti.

Se si desidera un flusso di lavoro in cui è possibile lavorare su questi rami liberi di merge commit ed ancora integrare con i cambiamenti più recenti in Master, vi consiglio il seguente:

• base di ogni nuovo ramo di caratteristica su un commit del maestro
• creare un ramo dev su un impegno di maestro
• quando hai bisogno di vedere come il vostro ramo di caratteristica si integra con nuovi cambiamenti nella padrone, unire sia padrone e al ramo della funzione in dev.

Non eseguire il commit direttamente in dev, utilizzarlo solo per unire altri rami.

Per esempio, se si sta lavorando su funzionalità di A e B:

a---b---c---d---e---f---g -master 
    \  \ 
    \  \-x -featureB 
     \ 
     \-j---k -featureA 

rami si fondono in un ramo dev per verificare se funzionano bene con il nuovo padrone:

a---b---c---d---e---f---g -master 
    \  \   \ 
    \  \   \--x'---k' -dev 
     \  \   // 
     \  \-x---------- / -featureB 
     \     /
     \-j---k--------------- -featureA 

Puoi continuare a lavorare sui rami delle funzionalità e continuare a unire le nuove modifiche da entrambe le diramazioni principale e delle funzioni in dev regolarmente.

a---b---c---d---e---f---g---h---i----- -master 
    \  \   \   \ 
    \  \   \--x'---k'---i'---l' -dev 
     \  \   //  /
     \  \-x---------- /  /-featureB 
     \     /  / 
     \-j---k-----------------l------ -featureA 

Quando è il momento di integrare le nuove funzionalità, unire le funzionalità rami (non dev!) Nella master.

Answer 2

Prova

git checkout <commit hash> 
git checkout -b new_branch 

il commit dovrebbe esistere una sola volta nel vostro albero, non in due rami distinti.

Ciò consente di verificare lo specifico commit e denominarlo come si desidera.

Answer 3

Hai gli argomenti nell'ordine sbagliato:

git branch <branch-name> <commit> 

e per questo, non importa quanto ramo viene estratto; farà quello che dici. (Se si omette l'argomento commettere, il valore predefinito è la creazione di una filiale nello stesso posto come quello attuale.)

Se si desidera controllare la nuova filiale, come lo si crea:

git checkout -b <branch> <commit> 

con lo stesso comportamento se si omette l'argomento commit.

Answer 4

quello che dovete fare:

git branch <branch_name> <commit> 

(si stava scambiando il nome del ramo e si impegnano)

o si può fare:

git checkout -b <branch_name> <commit> 

Se al posto di voi utilizzare il nome ramo , ottieni un ramo dalla punta del ramo.