Share
Git biedt talloze voordelen voor de solo-ontwikkelaar, maar het schijnt ook echt als het gaat om teamsamenwerking.
De sleutel tot het opzetten van een geweldige teamworkflow met Git is communicatie. Git is veelzijdig, flexibel en geschikt voor verschillende gebruikspatronen. Door van te voren de workflow-regels van de weg te bepalen, worden wrijvingen en verwarring voorkomen en kan een team profiteren van wat Git het beste doet: de productiviteit verhogen.
Dat gezegd hebbende, dit zou niet echt een tutorial zijn als het geen tastbare, op Git gebaseerde teamworkflow zou bieden die je kunt beoordelen. Het volgende voorbeeld is gebaseerd op een zeer populaire Git-workflow gemaakt door Vincent Driessen, Git-Flow genaamd, hoewel deze op bepaalde belangrijke manieren verschilt. Er zijn verschillende populaire Git-workflows rondzweven op het web - ik zou willen voorstellen zoveel mogelijk te lezen, zodat uw team een regelset kan kiezen die het beste voor hem is.
Laten we beginnen met je onderzoek met de volgende workflow:
De meester branch is altijd inzetbaar. Altijd.
Een inzetbaar meester tak is om vele redenen belangrijk. Ten eerste maakt dit het voor iedereen die nieuw is in een project mogelijk om zonder fouten onmiddellijk te trekken en te bouwen. Niets is zo frustrerend als het niet kunnen bouwen van een onbekend project.
Tweede, meester toont de huidige productietoestand en / of het verzonden product. Als er hotfixes moeten worden gemaakt, is het duidelijk waar vandaan moet worden vertakt.
Ten slotte een inzetbaar meester is een vangnet. Als meester is altijd inzetbaar, dan kunnen we ons zonder zorgen inzetten. Zorg veroorzaakt stress en stress veroorzaakt indigestie. Niemand heeft dat nodig.
De ontwikkelen tak moet de belangrijkste tak van de lopende ontwikkeling zijn. Functietakken worden gemaakt van en samengevoegd in ontwikkelen, en ontwikkelen vertegenwoordigt de bloeding van onze codebase.
Sinds beide meester en ontwikkelen zijn permanente en sterk verhandelde branches, ze mogen nooit rechtstreeks worden bewerkt. In plaats daarvan moet al het werk worden gedaan in functietakken. Bij het implementeren van een nieuwe functie, vertakking van ontwikkelen en hack de functie.
Er zijn geen vaste regels voor het benoemen van filialen, met name voor functietakken. Als een filiaal een oplossing is, is het waarschijnlijk het beste om "fix-" eraan toe te voegen. Als een branch een release is, wordt het over het algemeen aangemoedigd voor de branch om dit formaat te volgen: "release-X.X.X".
Over het algemeen moeten branchenamen beschrijvend zijn. En misschien grappig. De occasionele en tijdige woordspeling zou niet misstaan.
Zodra je nieuwe geweldige functie gecodeerd is, is het tijd om hem terug te halen in een gedeelde branch (laten we aannemen dat we erin fuseren) ontwikkelen). Maar voordat je erin gaat samenvoegen ontwikkelen, zorg ervoor dat uw feature branch de nieuwste wijzigingen heeft ontwikkelen omdat er conflicten kunnen zijn.
Alle conflictoplossing moet in uw featuretak gebeuren. Als u vertakt bent om een kleine wijziging / oplossing te maken en je hebt de tak niet naar de afstandsbediening geduwd, rebase ontwikkelen in uw featuretak en voeg vervolgens uw feature branch samen ontwikkelen. Druk op en vervolgens voel je je vrij om je lokale featuretak te verwijderen.
Als u uw filiaal naar de afstandsbediening hebt geduwd, voegt u eerst samen ontwikkelen in je branche (conflicten oplossen), en dan je branch samenvoegen ontwikkelen. Druk en voel je vrij om zowel de lokale als de externe functietak te verwijderen.
Houd er bij het rebasen rekening mee dat dit een vernietigend actie. Betekenis ... wees voorzichtig! Rebasen is erg handig voor het opschonen van commit-geschiedenissen, maar je wilt de geschiedenis niet herschrijven op iets dat met iemand anders is gedeeld.
Hier zijn een paar regels om je veilig te houden bij het rebasen:
Accentsconagua
ontwikkelen is een gedeelde tak. mijn-awesome-functie is een lokale vestiging. Nu ben ik klaar om te fuseren mijn-awesome-functie om te ontwikkelen, maar ik wil er zeker van zijn dat er veranderingen zijn opgetreden ontwikkelen worden eerst samengevoegd in mijn featuretak:git checkout my-awesome-feature git rebase develop git checkout develop git merge my-awesome-feature
Stel dat we vertakt zijn, we hebben gecodeerd, we zijn samengevoegd / gerebased ontwikkelen, en nu zijn we klaar om onze nieuwe code opnieuw samen te voegen ontwikkelen. Maar zouden we dat moeten doen? Misschien moet iemand eerst onze wijzigingen bekijken ...
Code-reviews zijn goed! Hiermee kunt u waardevolle feedback krijgen op het werk dat u hebt gedaan en, als er niets anders is, de kans vergroten dat fouten worden gepakt en verholpen.
Dit is waar Git's pull-verzoeken (en de interface van Bitbucket) van pas komen. (Voor een opfrissing over het openen en beheren van pull-aanvragen in Bitbucket, bekijk deel twee van deze serie, Pull-requests gebruiken als codereviews.) Pull-aanvragen kunnen veel meer zijn dan alleen het herzien van de code. Omdat pull-aanvragen op het merk zijn gebaseerd, kunnen ze discussies worden voor het bespreken van en samenwerken aan individuele functies. U kunt foto's insluiten om ontwerpen te delen, rechtstreeks commentaar geven op coderegels en zelfs GIF's en emoji's gebruiken om plezier te hebben.
Als het gaat om het samenvoegen van pull-aanvragen, heeft het de voorkeur dat de samenvoeging wordt gemaakt door dezelfde persoon die het pull-verzoek heeft geopend, omdat dat waarschijnlijk de persoon is die de nieuwe code heeft geschreven. Om dit te bereiken, moeten beoordelaars een reactie achterlaten waarin de nieuwe code wordt goedgekeurd, maar niet de knop samenvoegen. Zodra een teamgenoot de code een "duim omhoog" geeft (hetzij figuurlijk, hetzij letterlijk met een :duimen omhoog: emoji), kan de pull-opener dan doorgaan en samenvoegen. Peer review plus schone logboeken - een prachtig iets!
Een keer ontwikkelen is klaar voor een release, doe een samenvoeging meester:
git checkout master git merge --no-ff ontwikkelen
Let erop dat --no-ff vlag? Dat zorgt ervoor dat de samenvoeging geen fast-forward is, dus het zal een nieuwe commit creëren. Waarom willen we dat? We kunnen het dus labelen! Tag die commit als de nieuwe versie:
git tag -a vX.X.X -m 'Version X.X.X'
Voeg dan samen meester terug naar ontwikkelen zodat ontwikkelen heeft de versie commit.
Over versies gesproken, we zouden semantische versies moeten gebruiken. Dat komt neer op MAJOR.MINOR.PATCH. In het algemeen, MAJOR is een volledig versienummer - het wordt gebruikt voor enorme veranderingen en / of mijlpalen. Het is toegestaan om compatibiliteit met eerdere versies te onderbreken. MINOR wordt gebruikt voor nieuwe functies. Het mag geen compatibiliteit met eerdere versies verbreken. PATCH is bedoeld voor kleine wijzigingen en oplossingen, en mag geen compatibiliteit met eerdere versies verbreken. We zouden in een pre-release moeten zitten (0.x.x) totdat we starten.
We mogen nooit fouten verzenden.
... maar als we dat doen, is het het beste om ze snel te repareren. Sinds ontwikkelen kan onvoltooide functies bevatten, hotfixes moeten vertakt zijn van de huidige release-wat is meester (omdat meester is altijd inzetbaar!).
Maak een vertakking om een hotfix te maken meester, maak de oplossing, doe dan a non-fast-forward samenvoegen in meester. Tag het en voeg vervolgens samen meester terug naar ontwikkelen (omdat we willen ontwikkelen om ook de oplossing te hebben). U kunt de hotfix-branch verwijderen.
Laten we het hebben over Git commit-berichten. Het volgen van een gemeenschappelijk formaat maakt het veel gemakkelijker om onze logboeken te doorzoeken. Hier zijn enkele goede regels:
Als je wat meer wilt lezen over het schrijven van Git commit berichten, kijk dan eens naar de post van Tim Pope.
Laat me nogmaals opmerken dat de hierboven geschetste workflow bedoeld is als een richtlijn, niet als harde en snelle regels die u strikt moet implementeren voor uw teams. Als je ze allemaal leuk vindt, gebruik ze dan! Als iets niet voor u werkt, trek dan weg!
Het belangrijkste is dat uw team instemt met een gedefinieerde Git-workflow en er vervolgens aan vasthoudt. Zodra dat gebeurt, volgt de samenwerking en profiteert u van de voordelen die Git te bieden heeft als u in teamverband werkt.
Bekijk enkele alternatieven voor de Git-Flow-workflow in de Git-workflows-gids van Atlassian.
