Git-takken bijwerken vanaf master

Ik ben nieuw bij Git, en nu zit ik in deze situatie:

• Ik heb vier takken (master, b1, b2 en b3).
• Nadat ik aan b1-b3 had gewerkt, realiseerde ik me dat ik iets moest veranderen aan de branchmaster die in alle andere branches zou moeten staan.
• Ik heb veranderd wat ik nodig had in masteren… hier is mijn probleem:

Hoe update ik alle andere branches met masterbranchcode?

Antwoord 1, autoriteit 100%

Je hebt twee opties:

De eerste is een merge, maar dit creëert een extra commit voor de merge.

Elke vestiging afrekenen:

git checkout b1

Vervolgens samenvoegen:

git merge origin/master

Druk vervolgens op:

git push origin b1

U kunt ook een rebase uitvoeren:

git fetch
git rebase origin/master

Antwoord 2, autoriteit 77%

Je hebt in principe twee opties:

1. Je fuseert. Dat is eigenlijk heel eenvoudig, en een perfect lokale operatie:

   git checkout b1
   git merge master
   # repeat for b2 and b3
   

   Hierdoor blijft de geschiedenis precies zoals het is gebeurd: je hebt geforkt van master, je hebt wijzigingen aangebracht in alle branches en uiteindelijk heb je de wijzigingen van master in alle drie branches verwerkt.

   gitkan deze situatie heel goed aan, het is ontworpen voor fusies die tegelijkertijd in alle richtingen plaatsvinden. U kunt erop vertrouwen dat het in staat is om alle threads correct bij elkaar te krijgen. Het maakt gewoon niet uit of branch b1mastersamenvoegt, of masterb1samenvoegt, de merge-commit ziet er helemaal hetzelfde voor git. Het enige verschil is welke branch naar deze merge commit wijst.

2. Je rebaset. Mensen met een SVN of vergelijkbare achtergrond vinden dit intuïtiever. De commando’s zijn analoog aan de merge case:

   git checkout b1
   git rebase master
   # repeat for b2 and b3
   

   Mensen houden van deze aanpak omdat het een lineaire geschiedenis in alle branches behoudt. Deze lineaire geschiedenis is echter een leugen, en je moet je ervan bewust zijn dat het dat is. Overweeg deze vastleggingsgrafiek:

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1
   

   De samenvoeging resulteert in de ware geschiedenis:

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1
   

   De rebase geeft je echter deze geschiedenis:

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1
   

   Het punt is dat de commits E', F'en G'nooit echt hebben bestaan ​​en waarschijnlijk nooit zijn getest . Ze compileren misschien niet eens. Het is eigenlijk vrij eenvoudig om onzinnige commits te maken via een rebase, vooral wanneer de wijzigingen in masterbelangrijk zijn voor de ontwikkeling in b1.

   Het gevolg hiervan kan zijn dat je niet kunt onderscheiden welke van de drie commits E, Fen Gdaadwerkelijk zijn geïntroduceerd een regressie, die de waarde van git bisectvermindert.

   Ik zeg niet dat je git rebaseniet moet gebruiken. Het heeft zijn toepassingen. Maar wanneer u het toch gebruikt, moet u zich bewust zijn van het feit dat u over de geschiedenis liegt. En je zou op zijn minst de nieuwe commits moeten compileren en testen.

Antwoord 3, autoriteit 32%

git rebase masteris de juiste manier om dit te doen. Samenvoegen zou betekenen dat er een commit zou worden gemaakt voor de samenvoeging, terwijl rebasen dat niet zou doen.

Antwoord 4, autoriteit 9%

Als je af en toe aan een branch hebt gewerkt, of er is veel gebeurd in andere branches terwijl je aan iets werkte, is het het beste om je branch te rebasen op master. Dit houdt de geschiedenis netjes en maakt het een stuk gemakkelijker om te volgen.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Opmerkingen:

• Rebase geen branches waaraan je met anderen hebt samengewerkt.
• Je moet rebasen op de branch waarmee je gaat mergen, die niet altijd master hoeft te zijn.

Er is een hoofdstuk over rebasen op http://git-scm.com/book/ch3-6.html en tal van andere bronnen op internet.

Antwoord 5, autoriteit 3%

@cmaster heeft het best uitgewerkte antwoord gegeven. In het kort:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Je moet de filiaalgeschiedenis niet herschrijven, maar ze in de werkelijke staat bewaren voor toekomstige referenties. Tijdens het samenvoegen tot master, creëert het een extra commit, maar dat is goedkoop. Vastleggen kost niets.

Antwoord 6, autoriteit 2%

Om andere branches zoals (back-up) bij te werken met je master branch kopie.
Je kunt beide kanten op volgen (rebase of merge)…

1. Doe rebase(er wordt geen extra commit gedaan aan de back-up branch).

2. Vertakkingen samenvoegen(er wordt automatisch een extra commit toegevoegd aan de
   back-uptak).

   Opmerking: Rebase is niets anders dan het opzetten van een nieuwe basis (een nieuwe kopie)

git checkout backup
git merge master
git push

(Herhaal dit voor eventuele andere branches zoals backup2 & etc..)

git checkout backup
git rebase master
git push

(Herhaal dit voor eventuele andere branches zoals backup2 & etc..)

Antwoord 7

Je kunt samenvoegen, of je kunt individuele commits toepassen op branches door git cherry-pick.

Antwoord 8

1. git checkout master
2. git pull
3. git checkout feature_branch
4. git rebase master
5. git push -f

Je moet krachtig duwen nadat je tegen master hebt gerebaseerd

Antwoord 9

om je branch bij te werken vanaf de master:

 git checkout master
  git pull
  git checkout your_branch
  git merge master

Antwoord 10

Er zijn twee opties voor dit probleem.

1) git rebase

2) git merge

Alleen diff met bovenstaande beide in geval van samenvoegen, zal een extra commit in de geschiedenis hebben

1) git checkout branch(b1,b2,b3)

2) git rebase origin/master (In geval van conflicten lokaal oplossen door git rebase –continue te doen)

3) git push

Als alternatief is de git merge-optie vergelijkbaar

1) git checkout “your_branch”(b1,b2,b3)

2) git merge master

3) git push