Git workflow en Gerrit

Ik probeer een 'git-flow'-manier van werken met Gerrit te implementeren, maar ik kan het laatste stukje van de puzzel niet vinden.

Er zijn twee voorwaarden voor mijn probleem:

  • Gerrit voert alleen samenvoegen uit naar één branch
  • Ik sta niet toe dat samenvoegcommissies naar Gerrit worden geduwd. Het samenvoegen moet door Gerrit worden gedaan nadat de wijzigingen zijn goedgekeurd

Wat ik wil oplossen, is het volgende. Overweeg deze git-situatie:

Master 0 
        \
         \
Develop   0-----0-----0-----0

Er is een hoofdtak met één commit en een develop branch die van master wordt gesplitst met verschillende extra commits. Na een tijdje wordt de ontwikkeltak weer samengevoegd tot master om de volgende productierelease te maken. De ontwikkelaars werken met topic branches van develop en met strict rebasing. Hun commits worden altijd opnieuw op de nieuwste upstream-ontwikkeling gebaseerd voordat ze worden doorgevoerd. Dit zou moeten resulteren in een lineaire geschiedenis en alleen fast forward commits.

Stel nu dat iemand een hotfix-branch van master maakt en terugvoert naar master:

Master 0--------0 HF 
        \
         \
Develop   0-----0-----0-----0

Deze commit is nu alleen samengevoegd met de master branch, maar de ontwikkelaars hebben deze commit nodig in hun ontwikkeltak om de bugfix in hun wijzigingen op te nemen. Normaal zou je de master branch samenvoegen om de develop branch te ontwikkelen, maar gezien mijn randvoorwaarden is dit niet mogelijk omdat het een lokale merge commit zou creëren.

Mijn vraag is: hoe neem ik de nieuwe commits van de mastertak op in de lokale ontwikkeltak, zodat eventuele nieuwe wijzigingen door de ontwikkelaars de bugfix bevatten? Idealiter zou ik mijn script aanpassen om eerst de bugfix-wijzigingen toe te passen op de lokale ontwikkeltak (samenvoegen maar zonder een samenvoegingsverbintenis) en vervolgens de opdrachten van de dev opnieuw te basen en te pushen. Op deze manier wordt de bugfix automatisch aan hun nieuwe wijzigingen toegevoegd en zal deze als zodanig worden gezien als onderdeel van hun nieuwe commits, niet als een afzonderlijke commit.

Ik heb nagedacht over mogelijke oplossingen:

Ik hoop dat mijn vraag duidelijk is. Laat het me weten als het meer uitleg nodig heeft. Ik weet dat ik behoorlijk rigide ben met mijn workflow, maar het zou ideaal zijn in combinatie met Gerrit. Als het niet mogelijk is, zal ik waarschijnlijk samenvoegcommissies toestaan ​​...

14

3 antwoord

Na de opties bekeken te hebben, heb ik besloten om van deze methode af te zien. Het lijkt me dat Gerrit voor het grootste deel gericht is op de ontwikkeling van een enkele integratietak.

Wanneer wijzigingen moeten worden samengevoegd in twee branches (bijvoorbeeld een hotfix die moet worden onder de knie en zich verder ontwikkelt), spring je door allerlei soorten hoepels die extra werk/beoordeling opleveren. Ik heb besloten om bij één filiaal te blijven.

Ik denk dat het Git flow-model niet echt past in het ontwerp van Gerrit. Als andere mensen Gerrit met Git flow hebben geïntegreerd, zou ik graag horen wat hun methoden zijn.

6
toegevoegd

U zou de hotfix kunnen samenvoegen met uw ontwikkelingstak. U hoeft master niet samen te voegen. We verwerken dit met deze werkstroom (een hotfix wordt beschouwd als een andere release en we basen het werk daar bovenop):

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

4
toegevoegd

De beste oplossing is om de master of de hotfix-branch in uw ontwikkeltak samen te voegen. Ik weet niet zeker wat je 'no merge commits'-voorwaarde is die je probeert op te lossen, maar het zal waarschijnlijk meer moeite opleveren dan het waard is.

Aan de andere kant, als je cherry pick doet, zal git meestal de dubbele commit detecteren tijdens het samenvoegen en het probleemloos automatisch oplossen. Maar als er problemen zijn, zullen ze niet leuk zijn. Ook is het niet zo duidelijk welke fixes kers geplukt zijn en welke niet, waar het zoals bij een fusie heel duidelijk is.

3
toegevoegd
Houd er rekening mee dat eventuele samenvoegingen die uw ontwikkelaars doen, ook in Gerrit moeten worden beoordeeld/goedgekeurd. Dit helpt mijn team om problemen te voorkomen.
toegevoegd de auteur Brad, de bron
De reden voor geen 'merge commits' is dat ik niet wil dat lokale ontwikkelaars de ontwikkeltak (met nieuwe commits) samenvoegen met de mastertak en het resultaat naar de canonieke repository duwen. Nieuwe opdrachten voor ontwikkeling mogen pas na beoordeling in Gerrit worden samengevoegd.
toegevoegd de auteur Ivo, de bron