Wat is GitHub?

GitHub is ons softwareversiebeheerplatform, evenals ons CI/CD-systeem (Continuous Integration/Continuous Deployment). GitHub is gebouwd bovenop Git, een systeem dat elke wijziging in onze software bijhoudt. Met GitHub als platform kunnen we processen creëren voor het ontwikkelen van nieuwe functies, het oplossen van bugs, met codebeoordelingen en geautomatiseerd testen.

Hoewel we een grafische gebruikersinterface gebruiken bij het maken van pull-aanvragen en het beoordelen van code in GitHub, is het belangrijk dat je lokaal leert werken met de opdrachtregelinterface van Git. Dit heeft de voorkeur omdat wanneer je Git lokaal in een grafische app gaat gebruiken, het mogelijk is dat je de tools van Git gebruikt zonder de onderliggende commando's en wat ze doen volledig te begrijpen. Dit kan resulteren in ongewenste samenvoegingen en het creëren van samenvoegconflicten.

Conflicten samenvoegen

Samenvoegconflicten doen zich voor wanneer hetzelfde codeblok wordt bewerkt in een vertakking die wil worden samengevoegd en de vertakking waarin het wil samenvoegen. Samenvoegconflicten moeten handmatig worden opgelost, regel voor regel, en daarom willen we samenvoegconflicten zoveel mogelijk vermijden. Een goed begrip van de commando's van Git is essentieel voor het minimaliseren van merge-conflicten.

Het is belangrijk dat je een goed begrip hebt van Git. Lees de volgende handleidingen voordat je doorgaat met deze handleiding, om er zeker van te zijn dat alle basisbeginselen van Git vers in je geheugen zitten:


Kenmerktakken

In alle Git-projecten is er minstens één "hoofd" -vertakking. Deze tak vertegenwoordigt de huidige status van de softwareontwikkeling en moet altijd inzetbaar zijn. Als er code wordt samengevoegd in de gemaakte branch die het product kapot maakt, zal dit het werk voor alle ontwikkelaars onderbreken, omdat ze nieuwe branches zullen starten door code uit de hoofdbranch te kopiëren.

In veel Git-projecten wordt de hoofdtak "master" of "main" genoemd. Bij DXPR gebruiken we meerdere hoofdtakken die elk verwijzen naar de corresponderende hoofdtakken van Drupal core:

  • 1.x (voor Drupal 8 en hoger)
  • 7.x (voor Drupal 7, een oudere Drupal-versie)

Naamgevingsconventie voor takken

In de bovenstaande documentatie heb je geleerd dat feature branches geïsoleerde branches zijn waarin ontwikkelaars features kunnen ontwikkelen zonder wijzigingen aan te brengen in de hoofdbranch. In feite wordt deze workflow niet alleen gebruikt voor het ontwikkelen van functies, maar ook voor het oplossen van bugs. Bugfixes moeten in een geïsoleerde branch worden getest en pas in de hoofdbranch worden samengevoegd als de fix is getest en gevalideerd.

Omdat onze repository's meerdere hoofdvertakkingen hebben, wordt dit weerspiegeld in onze naamgevingsconventie voor vertakkingen:

persoon / doel-tak / #probleem - beschrijving-van-tak

Hier is een overzicht van de naamgevingsconventie voor vertakkingen:

  • persoon — De naam van de eigenaar van het filiaal. Bijvoorbeeld Jur, Rokaya, Shaaer, Denis, etc.
  • doel-tak   — Een verwijzing naar de doelvertakking waarin u wilt mergen, bijvoorbeeld 1.x .
  • #probleem   — Elke branch moet aan een GitHub-probleem zijn gekoppeld. Vul hier het uitgiftenummer in.
  • beschrijving-van-tak   — Beschrijf wat erin zit, bijvoorbeeld ' fix-for-jumping-controls-bug' of 'new-icon-set-for-parameter-definition'.

Omdat onze geïsoleerde branches voor meer zijn dan alleen de ontwikkeling van functies, zullen we ze vanaf nu Topic Branches noemen.

Voorbeeld van een onderwerptaknaam: jur/1.x/#99-fix-for-jumping-controls-bug


Pull Request-workflow

In de hierboven gelinkte GitHub-handleiding heb je gelezen over de "GitHub-stroom". Deze stroom is in wezen wat een Pull Request-workflow is. Ik zal de zes stappen uit de handleiding kopiëren en de stappen uitwerken met DXPR-specifieke conventies:

  • Maak een vertakking: onderwerpvertakkingen gemaakt op basis van de canonieke implementatievertakking ( 1.x of 7.x ) stellen teams in staat bij te dragen aan veel parallelle inspanningen. Vooral kortstondige onderwerptakken houden teams gefocust en resulteren in snelle schepen. Onderwerpvertakkingen worden lokaal gemaakt en naar de oorspronkelijke repository op GitHub gepusht.
  • Vastleggingen toevoegen: momentopnamen van ontwikkelingsinspanningen binnen een branche creëren veilige, omkeerbare punten in de geschiedenis van het project. Het is belangrijk dat alle commits een beschrijving van de code in de commit hebben. Om pull-aanvragen transparanter en gemakkelijker te beoordelen te maken, verdient het de voorkeur om uw codewijzigingen op te splitsen in geïsoleerde commits die delen van uw werk vertegenwoordigen, in plaats van één grote commit te creëren na dagenlang coderen.
  • Open een pull-request: Pull-requests maken de lopende inspanningen van een project bekend en zetten de toon voor een transparant ontwikkelingsproces. Bij het openen van een pull request plaatsen wij trefwoorden in de omschrijving en het uitgiftenummer. Als een topic branch een bug repareert, moet de beschrijving het fixes trefwoord bevatten en de #id van het probleem dat de bug beschrijft die is opgelost. Bijvoorbeeld 'Fixes #90'. Overzicht van beschikbare trefwoorden .
  • Geautomatiseerde controles: Bij DXPR zullen sommige repositories uw Pull Request automatisch beoordelen door uw code te controleren aan de hand van coderingsstandaarden, of door geautomatiseerde black box-tests uit te voeren met Selenium. De status en uitvoer van de controles zijn te vinden op het tabblad "Checks" van uw pull request-pagina op GitHub. Als uw Pull Request één of meer controles niet doorstaat, moet u deze problemen eerst oplossen, zodat u alle controles doorstaat, voordat u vraagt dat een mens uw code beoordeelt.
  • Code bespreken en beoordelen: Teams nemen deel aan codebeoordelingen door open pull-aanvragen te becommentariëren, te testen en te beoordelen. Code review vormt de kern van een open en participatieve cultuur. Wanneer u een pull-verzoek indient, is het volgende dat u moet doen een beoordeling aanvragen via de gebruikersinterface van GitHub.
  • Samenvoegen: Als je op merge klikt, voert GitHub automatisch het equivalent uit van een lokale 'git merge'-bewerking. GitHub bewaart ook de volledige ontwikkelingsgeschiedenis van de branch op het samengevoegde pull-verzoek. Nadat een onderwerpvertakking is samengevoegd, wordt deze verwijderd uit de oorspronkelijke Github-repository.
  • Implementeren: Teams kunnen de beste releasecycli kiezen of tools voor continue integratie integreren en werken met de zekerheid dat de code op de implementatietak een robuuste workflow heeft doorlopen.


Het up-to-date houden van uw lokale omgeving

Wanneer u in een team werkt dat code naar dezelfde repository pusht, zoals bijvoorbeeld het geval is met de DXPR Builder-repository, is het waarschijnlijk dat wijzigingen worden samengevoegd in de hoofdvertakkingen nadat u de hoofdvertakking hebt gekopieerd om uw onderwerpvertakking te maken . Meestal is dit geen probleem, maar als de wijzigingen worden aangebracht in dezelfde bestanden en codeblokken die u aan het bewerken bent, zullen er samenvoegconflicten ontstaan. Om samenvoegconflicten te minimaliseren, is het belangrijk om op de hoogte te blijven van wijzigingen in de hoofdvertakkingen in de oorspronkelijke repository.

Er zijn drie dingen die u moet doen:

  • Voordat je een kopie van de hoofdvertakking maakt, merge je alle laatste wijzigingen in je lokale kopie ( git pull origin 1.x )
  • Als je langer dan een paar dagen aan een onderwerpbranch werkt, probeer dan aan het begin van elke dag dat je aan deze branch werkt wijzigingen uit de hoofdbranch binnen te halen
  • Wis Drupal-caches op de site nadat u nieuwe code hebt ingevoerd
  • Voer het database-updatescript uit

Database-updates uitvoeren

Soms omvatten wijzigingen aan een Drupal-module wijzigingen in het databaseschema van de siteconfiguratie. Als dit het geval is, heeft de auteur van de wijzigingen een database-updatescript toegevoegd. Als uw site crasht nadat er nieuwe wijzigingen zijn doorgevoerd, is het uitvoeren van het updatescript een mogelijke oplossing. Er zijn twee manieren om dit te doen:

  • In de browser: bezoek /update.php in uw Drupal-installatie. Volg de stappen in de wizard.
  • Ga in de terminal naar de map met uw Drupal-bestanden. Voer vervolgens drush updb uit