Wat is de beste (en veiligste) manier om een Git-branch in master samen te voegen?

Er wordt een nieuwe branch gemaakt van master, we noemen het test.

Er zijn verschillende ontwikkelaars die zich ofwel committeren aan masterof andere branches maken en later samenvoegen tot master.

Stel dat het werk aan testenkele dagen in beslag neemt en dat je testcontinu up-to-date wilt houden met commits binnen master.

Ik zou git pull origin masteruit testdoen.

Vraag 1:Is dit de juiste aanpak? Andere ontwikkelaars hadden gemakkelijk aan dezelfde bestanden kunnen werken als ik heb gewerkt.

Mijn werk aan testis klaar en ik ben klaar om het weer samen te voegen tot master. Dit zijn de twee manieren die ik kan bedenken:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

Ik gebruik --rebaseniet omdat, voor zover ik weet, rebase de wijzigingen van masterzal krijgen en de mijne daar bovenop zal stapelen, vandaar dat het wijzigingen van andere mensen kan overschrijven gemaakt.

Vraag 2:Welke van deze twee methoden is de juiste? Wat is daar het verschil?

Het doel van dit alles is om mijn testbranch up-to-date te houden met de dingen die gebeuren in masteren later zou ik ze terug kunnen samenvoegen tot masterin de hoop de tijdlijn zo lineair mogelijk te houden.

Antwoord 1, autoriteit 100%

Hoe ik dit zou doen

git checkout master
git pull origin master
git merge test
git push origin master

Als ik een lokale branch heb van een remote, voel ik me niet op mijn gemak bij het samenvoegen van andere branches dan deze met de remote. Ook zou ik mijn wijzigingen niet pushen, totdat ik tevreden ben met wat ik wil pushen en ik zou ook helemaal geen dingen pushen, die alleen voor mij en mijn lokale repository zijn. In uw beschrijving lijkt het erop dat testalleen voor u is? Dus geen reden om het te publiceren.

git probeert altijd uw en andere wijzigingen te respecteren, en dat geldt ook voor --rebase. Ik denk niet dat ik het goed kan uitleggen, dus bekijk het Git-boek – Rebasenof git-ready: Introductie in rebasenvoor een korte beschrijving. Het is een heel coole functie

Antwoord 2, autoriteit 14%

Dit is een zeer praktische vraag, maar alle bovenstaande antwoorden zijn niet praktisch.

Vind ik leuk

git checkout master
git pull origin master
git merge test
git push origin master

Deze aanpak heeft twee problemen:

1. Het is onveilig, omdat we niet weten of er conflicten zijn tussen testbranch en masterbranch.

2. Het zou alle test-commits “knijpen” in één merge-commit op master; dat wil zeggen dat we in de master-branch niet alle wijzigingslogboeken van de test-branch kunnen zien.

Dus, als we vermoeden dat er conflicten zouden zijn, kunnen we de volgende git-bewerkingen uitvoeren:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Test mergevoor commit, vermijd een fast-forward commit door --no-ff,

Als er een conflict wordt aangetroffen, kunnen we git statusuitvoeren om details over de conflicten te controleren en proberen op te lossen

git status

Zodra we de conflicten hebben opgelost, of als er geen conflict is, commiten pushze

git commit -m 'merge test branch'
git push

Maar op deze manier zal de wijzigingsgeschiedenis die in de testbranch is vastgelegd, verloren gaan, en het zou de masterbranch moeilijk maken voor andere ontwikkelaars om de geschiedenis van het project te begrijpen.

Dus de beste methode is dat we rebasemoeten gebruiken in plaats van merge(stel dat we in deze tijd de branchconflicten hebben opgelost).

Hier volgt een eenvoudig voorbeeld, voor geavanceerde bewerkingen verwijzen wij u naar http ://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Ja, als je de uppers hebt gedaan, worden alle commits van de Test-branch naar de kop van de Master-branch verplaatst. Het grote voordeel van rebasen is dat u een lineaire en veel schonere projectgeschiedenis krijgt.

Het enige dat je moet vermijden is: gebruik nooit rebaseop een publieke branch, zoals master branch.

Voer nooit bewerkingen uitzoals de volgende:

git checkout master
git rebase -i test

Details voor https:// www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

bijlage:

• als je niet zeker bent over rebasen, raadpleeg dan: https ://git-scm.com/book/en/v2/Git-Branching-Rebasing

Antwoord 3, autoriteit 3%

Noch een rebase, noch een merge mag de wijzigingen van iemand overschrijven (tenzij u ervoor kiest om dit te doen bij het oplossen van een conflict).

De gebruikelijke aanpak tijdens het ontwikkelen is

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Als je klaar bent om weer samen te voegen tot master,

git checkout master
git log ..test # if you're curious
git merge test
git push

Als je je zorgen maakt over het breken van iets bij het samenvoegen, is git merge --aborter voor jou.

Duwen en dan trekken gebruiken om samen te voegen is dwaas. Ik weet ook niet waarom je de test naar de oorsprong pusht.

Antwoord 4

Ik zou eerst de te mergen branch zo schoon mogelijk maken. Voer uw tests uit, zorg ervoor dat de staat is zoals u het wilt. Ruim de nieuwe commits op door git squash.

Naast KingCrunches-antwoord, raad ik aan om

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Misschien heb je veel commits gemaakt in de andere branch, wat maar één commit in de master branch zou moeten zijn. Om de commit-geschiedenis zo schoon mogelijk te houden, wil je misschien al je commits van de test-branch in één commit in de master-branch pletten (zie ook: Git: squashen of niet squashen?). Dan kun je het commit-bericht ook herschrijven naar iets heel expressiefs. Iets dat gemakkelijk te lezen en te begrijpen is, zonder in de code te hoeven graven.

bewerken: misschien ben je geïnteresseerd in

• Wat is in git het verschil tussen merge –squash en rebase?
• Samenvoegen versus rebasen
• Een pull-aanvraag rebasen

Dus op GitHub doe ik uiteindelijk het volgende voor een feature branch mybranch:

Ontvang het laatste nieuws van origin

$ git checkout master
$ git pull origin master

Zoek de basishash voor het samenvoegen:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f
$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Zorg er nu voor dat alleen de eerste pickis, de rest s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Kies vervolgens een zeer goed commit-bericht en push naar GitHub. Doe dan het pull-verzoek.

Na het samenvoegen van het pull-verzoek, kunt u het lokaal verwijderen:

$ git branch -d mybranch

en op GitHub

$ git push origin :mybranch

Antwoord 5

Dit is de workflow die ik gebruik in mijn werk met het team. Het scenario is zoals je beschrijft. Ten eerste, als ik klaar ben met test, rebase ik met master om alles binnen te halen wat aan master is toegevoegd gedurende de tijd dat ik aan de branch testheb gewerkt.

git pull -r upstream master

Dit zal de wijzigingen naar de master halen sinds je de testbranch hebt gevorkt en ze toepast, en dan de wijzigingen toepassen die je hebt gemaakt om “bovenop” de huidige status van master te testen. Er kunnen hier conflicten zijn als de andere mensen wijzigingen hebben aangebracht in dezelfde bestanden die u in de test hebt bewerkt. Als die er zijn, moet je ze handmatig repareren en vastleggen. Als je dat eenmaal hebt gedaan, kun je zonder problemen overschakelen naar de master -branch en testsamenvoegen.

Antwoord 6

git checkout master
git pull origin master
# Merge branch test into master
git merge test

Als het bestand na het samenvoegen is gewijzigd, zal het bij het samenvoegen door de fout “Conflict oplossen” gaan

Dus dan moet je eerst al je conflicten oplossen, dan moet je al je wijzigingen opnieuw vastleggen en dan pushen

git push origin master

Dit is beter te doen wie wijzigingen heeft aangebracht in de testbranch, omdat hij wist welke wijzigingen hij heeft aangebracht.

Antwoord 7

Ik zou de rebase-methode gebruiken. Vooral omdat het uw zaak semantisch perfect weerspiegelt, dat wil zeggen. wat je wilt doen is de status van je huidige branch vernieuwen en “doen alsof” het gebaseerd is op de laatste.

Dus, zonder zelfs maar naar masterte kijken, zou ik:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Natuurlijk ververst alleen ophalen van oorsprong niet de lokale status van uw master(omdat het geen samenvoeging uitvoert), maar het is perfect in orde voor ons doel – we willen voorkomen dat er wordt gewisseld rond, om tijd te besparen.

Antwoord 8

@KingCrunch’s antwoord zou in veel gevallen moeten werken. Een probleem dat zich kan voordoen, is dat u zich mogelijk op een andere machine bevindt die het laatste uit de test moet halen. Dus ik raad aan om eerst een test te doen. De revisie ziet er als volgt uit:

git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master

Antwoord 9

Ik zal antwoorden volgens de ontwikkel- en functiebranches,

als je op feature branch zit en het moet updaten met ontwikkel gebruik dan de onderstaande commando’s:

git checkout develop
git pull
git checkout feature/xyz
git merge develop

Je feature/xyzis nu bijgewerkt met de developbranch en je kunt je wijzigingen pushen naar de remote feature/xyz.

Antwoord 10

Zoals de titel al zegt “Beste manier”, denk ik dat het een goed idee is om de
geduldsamenvoegstrategie.

Van: https://git-scm.com/docs/merge-strategies

Met deze optie besteedt ‘samenvoegen-recursief’ wat extra tijd om verkeerde samenvoegingen te voorkomen die soms optreden als gevolg van onbelangrijke overeenkomende regels (bijvoorbeeld accolades van verschillende functies). Gebruik dit wanneer de samen te voegen takken wild uiteen zijn gaan lopen. Zie ook git-diff[1] –patience.

Gebruik:

git fetch
git merge -s recursive -X patience origin/master

Git-alias

Ik gebruik hiervoor altijd een alias, b.v. één keer uitvoeren:

git config --global alias.pmerge 'merge -s recursive -X patience'

Nu zou je het volgende kunnen doen:

git fetch
git pmerge origin/master

Antwoord 11

Je moet de branch uitgecheckt hebben om te kunnen pullen, aangezien pullen betekent samenvoegen in master, en je hebt een werkboom nodig om in te mergen.

git checkout master
git pull

U hoeft niet eerst uit te checken; rebase doet het juiste met twee argumenten

git rebase master test  
git checkout master
git merge test

git push pusht standaard alle branches die hier en op de afstandsbediening bestaan

git push
git checkout test

Antwoord 12

Dit is van GitLab:
Volg gewoon de instructies:

Antwoord 13

Ik krijg altijd samenvoegconflicten als ik gewoon git merge feature-branchdoe. Dit lijkt voor mij te werken:

git checkout -b feature-branch

Voer een aantal codewijzigingen uit…

git merge -s ours master 

git checkout master

git merge feature-branch

of

git checkout -b feature-branch

Voer een aantal codewijzigingen uit…

git checkout master

git merge -X theirs feature-branch