Git merge met remote repository

[Orthodroom]

We zijn op kantoor recent begonnen met het gebruik van Git. Zodoende hebben we GitLab CE op een server gezet en zijn mijn collega en ik enthousiast begonnen. We hebben het volgende artikel als uitgangspunt genomen voor het gebruik van Git.

Het artikel geeft echter niet overal duidelijk weer hoe je met bepaalde dingen moet omgaan. Als ik een feature maak gebaseerd op de branch develop en in de tussentijd mijn collega dat ook heeft gedaan en die al via push naar de remote repository heef gezet zal ik mijn inziens eerst een fetch en merge moeten doen (of pull) van develop zodat ik dezelfde versie heb als mijn collega.

Door die merge komt er een extra commit in de lijst van commits. Mijn collega doet echter het volgende: hij gooit lokaal zijn develop branch weg. Vervolgens haalt hij die weer op van remote zodat hij de laatste versie heeft en doet dan pas een merge met zijn feature.
Hierdoor blijft de lijst van commits schoner, maar ik vraag me af of dit zo kan en we niet kans hebben dat er ergens code verdwijnt.

Heeft iemand hier ervaring mee? Is het allebei goed, maar gewoon een kwestie van voorkeur en/of 'best practice'? Of kan dit in de toekomst tot enorme problemen leiden?

[edxtreem]

Wat je kunt doen is de remote branch fetchen ( git fetch origin development ) en vervolgens je lokale development branch daarop rebasen ( git rebase origin/development ).
Op deze manier worden al jouw wijzigingen 'bovenop' de laatste versie van de development branch gezet, dit kan wel resulteren in conflicts maar die zul je hoe dan ook toch op moeten lossen.

[Xudonax]

Ik heb zelf erg vervelende ervaringen met git rebase in teams groter dan 1 persoon Er is altijd wel iemand die ergens per ongeluk iets doet waardoor een rebase mislukt of een puinzooi ervan maakt. Ik zou gewoon de merge commits voor lief nemen, dat is de simpelste manier om met Git te werken.

Sowieso kun je instellen dat er enkel een merge commit gemaakt word als het niet anders kan. Ik ben even kwijt hoe deze optie precies heet aangezien ik die enkel in Sourcetree en dergelijke grafische clients gezien heb.

[Creepy]

Grappig, hier met ons team gaat rebasen prima. Zo hebben we inderdaad die "loze" merge commits niet. De meeste IDE's hebben hier een optie voor om bij een pull automatisch een rebase te doen. Sterker nog: GIT heeft er zelfs een rebase optie voor omdat automatische bij elke remote branch te doen. Bijna altijd ligt het aan de gebruiker als een rebase faalt.

Wat je collega dus effectief doet, is een git rebase, alleen met verlies van de al gedane, niet gepushte, commits. Hier probeer ik ervoor te zorgen dat iedereen commit in niet al te grote logische stappen. Dan valt aan de hand van de commits ook de gedachten logica te zien, wat met reviewen van code weer kan schelen. Anders krijg je 1 grote commit waar alles in zit, en je alsnog je collega moet gaan lastig vallen waarom zaken op een bepaalde manier zijn opgelost.

[Orthodroom]

Aan de hand van jullie reacties kwam ik via Google uit op: https://www.atlassian.com...rging-vs-rebasing/summary
Daar wordt rebase erg goed uitgelegd en het lijkt erop dat het doet wat wij willen. Echter pas je er volgens mij ook zodanig de geschiedenis mee aan dat je niet meer goed kunt zien welke commits uit een bepaalde feature branch komen?

[Creepy]

Of je remote feature branches weer rebased of niet is weer een heel ander verhaal wat mij betreft, Dat doen wij dan weer wel.

[Orthodroom]

Of ik snap jou niet of ik snap dan kennelijk niet de link die ik had gepost.

In principe houden wij onze feature branches lokaal. Het zijn meestal kleine stappen die we maken die gemakkelijk steeds door 1 persoon kan worden afgehandeld.

Nu zie ik in de visuele weergave van de commits per feature een boog met daarin de bijbehorende commits. Met rebase wordt het zoals ik het begrijp gewoon 1 rechte lijn?

[Creepy]

Met merge krijg je die bogen, met rebase een rechte lijn. (onafhankelijk van of je lokaal wel of niet een feature branch gebruikt)

[Orthodroom]

Okee, dan gaan we eens met rebase testen en kijken of dat prettig werkt.
Bedankt allemaal