Git en GitHub (2)
Inleiding
Deze post is een vervolg op de Git en GitHub-post waarin we het hebben gehad over Git, GitHub en het doen vullen van een GitHub remote repository.
In deze post gaan we in op het .gitignore-bestand, de local Git repository en de remote GitHub repository, branches en pull requests. We illustreren het één en ander aan de hand van een index.html waarin we een tekst veranderen.
De .gitignore
Het doel van een versiebeheersysteem is dat we bestanden kunnen volgen zodat we weten of de bestanden zijn gewijzigd en wat er aan de bestanden is gewijzigd en wanneer. Voor dat doel maken we bestanden “tracked” zodat Git de bestanden kan volgen, maar het kan wel eens zo zijn dat dat we juist niet willen dat Git bestanden volgt.
We willen bijvoorbeeld dat in een repository alleen broncode komt te staan omdat de noodzaak voor het aanwezig zijn van gecompileerde bestanden in een repository er vaak niet is zodat we die gecompileerde bestanden ook niet hoeven te volgen.
Zo kan de broncode, eenmaal aanwezig in de working directory, alsnog gecompileerd worden op de desbetreffende PC door bijvoorbeeld een Visual Studio.
Ook bij het deployen naar een web server hoeven gecompileerde bestanden niet aanwezig te zijn in de repository. Zo kan een Azure DevOps pipeline als onderdeel van haar deployment-proces broncode compileren naar een build.
In een .gitignore-bestand geven we op welke bestanden “untracked” mogen blijven en genegeerd mogen worden door Git. Je kunt in GitHub een .gitignore-bestand toevoegen waarbij je gebruik kunt maken van een .gitignore template. GitHub heeft diverse templates waarin voor verschillende ontwikkelplatformen is gedefinieerd welke bestanden niet “getracked” hoeven te worden. In dit voorbeeld gebruiken we een .gitignore-Visual Studio-bestand.
Local en Remote
Voor het bijwerken van de GitHub remote repository en de local Git repository zijn de volgende Git-commando’s van belang:
- de Commit
“tracked” working directory bestanden –> local Git repository
is voor het doen opnemen van “tracked” working directory bestanden in de local Git repository. - de Push
local Git repository –> GitHub remote repository
is voor het doen üpdaten van de GitHub remote repository vanuit de local Git repository. - de Pull
GitHub remote repository –> local Git repository
voor het doen üpdaten van de local Git repository vanuit de GitHub remote repository (is wat anders dan een pull request) - de Fetch
GitHub remote repository –> local Git repository
voor het doen üpdaten van de local Git repository vanuit de GitHub remote repository met een branche die nog niet aanwezig is in local Git repository.
De branche wordt dan in de local Git repository toegevoegd naast de hoofdbranche (main of master). Met name van toepassing op situaties dat een reviewer de nieuwe dingen in een aparte branche op de lokale PC wil bekijken.
local naar remote
In de vorige post werkten we de master-branche bij van de GitHub remote repository vanuit de local Git repository. We hebben daarvoor in Git Bash een origin remote verbinding nodig omdat we anders vanuit Git Bash niet bij de GitHub remote repository kunnen komen. We gebruiken de url van de remote repository voor het doen maken van een remote verbinding:
# defineer remote verbinding origin:
git remote add origin https:... .git
# toon de remote verbinding:
git remote -v
We kunnen, nadat de remote verbinding is gemaakt een push commando doen voor het doen üpdaten van de GitHub remote repository vanuit de local Git repository (in dit voorbeeld gaat het om datgene wat in de master branche staat):
# update de github remote repository
git push -u origin master
Parameter -u staat voor upstream en koppelt de lokale Git repository aan de remote GitHub repository (de origin) zodat je nadien geen extra argumenten meer hoeft op te geven bij o.a. git pull en git push commando’s.
Als je de -u parameter nog niet eerder hebt gebruikt in een Git-commando dan moet je wel extra parameters opgeven bij de pull (en push) Git-commando’s (bijvoorbeeld dit voor een pull: git pull origin master).
Meestal synchroniseer je de local Git repository altijd met eenzelfde remote GitHub repository, maar je kunt met git remote -v de koppeling verwijderen naar de remote GitHub repository (die je bij een volgende keer dan wel weer moet activeren met get remote add origin https:/…. .git). In folder .git in bestand config vind je de remote settings (voor zover je die niet hebt verwijderd met git remote -v).
remote naar local
Aan de GitHub remote repository voegen we voor dit voorbeeld via de GitHub website een README.md-bestand toe. We doen vervolgens een pull commando om de local Git repository te laten doen üpdaten vanuit de GitHub remote repository. Vervolgens voegen we via de GitHub website een .gitignore-bestand toe en we doen weer een pull zodat de local Git repository nogmaals wordt bijgewerkt.
Ook hier moeten we eerst een origin remote verbinding maken omdat we anders vanuit Git Bash niet bij de GitHub remote repository kunnen komen.
We gebruiken onderstaande Git pull commando (in dit voorbeeld gaat het om datgene wat in de master branche staat):
# update de local git repository
# met de remote github remote repository
git pull origin master
Te zien is dat we een origin remote verbinding maken alvorens we de pull doen.
In het voorbeeld hebben we na elke toevoeging / aanpassing in de GitHub remote repository een pull gedaan om de local Git repository bijgewerkt te krijgen. Dat hoeft niet per se want je kunt ze “opsparen” waarna met één pull meerdere mutaties worden meegenomen naar de local Git repository.
Branches
Tot dusver hebben we dingen gedaan met één hoofdbranche en die heeft in onze voorbeelden nog de oude naam master (de defaultnaam voor de hoofdbranche is inmiddels gewijzigd naar main omdat de oude naam blijkbaar te veel associaties opriep met met nare plantages en daarop tewerkgestelde slaven).
De bedoeling van branching is dat een hoofdbranche (master of main) alleen maar broncode bevat dat zo ‘zuiver’ en stabiel mogelijk is. De broncode in de hoofdbranche zou getest en bug-free moeten zijn (alhoewel code dat voor 100% vrij is van bugs een utopie is).
Voor installaties naar bijvoorbeeld productiemachines wordt dan de broncode uit de hoofdbranche gebruikt door bijvoorbeeld een Azure DevOps pipeline.
Sub Branches
En nu komen de sub branches in beeld. Een “best practice” is dat je eerst je aanpassingen doet in een sub branche waarbij je het één en ander test en evalueert. Je neemt na goedbevinding de aanpassingen op in de hoofdbranche.
Sub branches geven ook mogelijkheden om meerdere personen aan een software project te laten werken. Iedere ontwikkelaar heeft dan zijn eigen branche en de aanpassingen worden per branche / ontwikkelaar geëvalueerd en na goedbevinding samengevoegd met de hoofdbranche.
We illustreren het één ander aan de hand van pagina index.html. Op die pagina staat de tekst “De wereld is rond en draait om de zon” en we gaan een aanpassing doen in een andere branche (een sub branche).
In die andere branche gaan we de tekst aanpassen naar “De wereld is rond en draait om de zon en de zon maakt deel uit van de melkweg en de melkweg is één van de vele sterrenstelsels in het universum.“. De sub branche gaan uiteindelijk samenvoegen met de hoofdbranche.
De sub branche geven we de naam “hubble” naar astronoom en kosmoloog Edwin Powell Hubble (1889 – 1953) die baanbrekend werk heeft verricht en naar wie later een ruimtetelescoop is vernoemd.
# Welke branches hebben we en
# in welke branche zitten we nu?
#(aangegeven met een *)
git branch
# aanmaken branche 'hubble'
git branch hubble
# ga naar een andere branche
# (van hoofdbranche master naar
# sub branche hubble)
git switch hubble
We gaan naar branche ‘hubble’ (met git switch hubble) en we doen in die branche een aanpassing:
En we slaan alles op en we doen een commit om alles opgeslagen te doen krijgen in de local Git repository. Let wel, we hebben de aanpassing alleen in sub branche hubble gedaan.
git commit -a -m "<tekst>"
Hoofdbranche master is nog onaangetast en dat is ook iets wat we willen. Er is nog niks doorgezet en de hoofdbranche is er nog niet mee “verziekt” als blijkt dat de aanpassing toch niet zo’n goed idee is.
En we hebben nu lokaal in Git onze aanpassingen gedaan in branche ‘hubble‘. Een ‘best practice’ is dat we voor onze aanpassingen een ‘pull request‘ (zie verder hieronder) gaan doen waarbij de aanpassing wordt bekeken door een reviewer en alles na een goedbevinden wordt samengevoegd met de hoofdbranche.
Pull Requests
Een Pull Request moet niet verward worden met Git-commando pull. Met een Pull Request doe je in feite het verzoek of de hoofdbranche bijgewerkt mag worden met jouw aanpassingen.
In situaties waarin meerdere personen betrokken zijn bij een project gaat meestal een ander persoon (de reviewer) naar de aanpassingen kijken waarna de pull request wordt goedgekeurd en je aanpassingen worden opgenomen in de hoofdbranche.
We “pushen” branche hubble naar de GitHub remote repository met git push origin hubble en we zien dat in de Git Bash CLI iets geroepen wordt over het aanmaken van een pull request in GitHub.
Ook hier hebben we een origin remote verbinding nodig omdat we anders vanuit Git Bash niet bij de GitHub remote repository kunnen komen.
# update de github remote repository
git push origin hubble
De GitHub remote repository is nu bijgewerkt met de hubble branche en we doen wat voorgesteld wordt in de Git Bash CLI. We gaan alles verder afhandelen in GitHub middels een pull request.
In GitHub ziet we dat na de push meerdere branches aanwezig zijn en dat een pull request gecreëerd kan worden:
We creëren een pull request om de hoofdbranche (master) bij te werken en GitHub vindt het ook allemaal prima want het ziet geen “merge conflicten” die een samenvoeging in de weg zouden staan:
We kunnen aan de pull request wat extra commentaar toevoegen:
En wat precies anders is t.o.v. de hoofdbranche (master) dat kan ook bekeken worden (door bijvoorbeeld een reviewer). GitHub toont daarvoor een link in de Pull Request dat (in dit voorbeeld) het volgende toont:
We vinden het allemaal prima en uiteindelijk bevestigen we dat de Pull Request het één en ander mag samenvoegen:
De hubble branche is niet meer nodig zodra alles succesvol is samengevoegd in de hoofdbranche. We bedanken de hubble branche voor zijn diensten en de branch kan van het toneel verdwijnen:
We hebben de GitHub remote repository bijgewerkt vanaf een lokale PC met een local Git repository en we kunnen het volgende doen om het één en ander weer synchroon te laten lopen met de GitHub remote repository.
We verwijderen de hubble branche met deze Git-commando want ook hier hebben we de desbetreffende branche niet meer nodig:
git branch -D hubble
En met de Git pull-commando üpdaten we de local Git repository met de up-to-date GitHub remote repository waamee alles weer synchroon loopt:
git pull origin master
Git commando’s
Samenvattend de Git commando’s die we in deze post gebruikt hebben. Zie hier voor een overzicht van de andere gebruikte commando’s.
# Welke branches hebben we en
# in welke branche zitten we nu?
# (aangegeven met een *)
git branch
# aanmaken branche
# met de naam 'hubble'
git branch hubble
# ga naar een andere branche
# bijvoorbeeld naar branche 'hubble'
git switch hubble
# update de github remote repository
# zet branche 'hubble' over naar
# de remote repository
git push origin hubble
# verwijder branche hubble
# uit de local git repository
git branch -D hubble
# update de git local repository
# met de remote repository
git pull origin master
Slot
Deze post is na deze post het tweede deel over Git en GitHub. We zijn ingegaan op het niet hoeven te volgen van bestanden door Git middels Git .ignore-bestanden, Branches en het doen bijwerken van de local Git repository en de remote GitHub repository waarbij we uit zijn gegaan van een scenario waarin we het doorvoeren van wijzigingen afhandelen in GitHub middels Pull Requests.
Mijn twee postings over Git en GitHub zijn hopelijk voldoende voor het aan de slag kunnen gaan met Git en GitHub, maar het is nog maar een topje van de ijsberg. Op het internet zijn veel tutorials over Git en GitHub te vinden en allerlei (niet gratis) on-line cursussen zijn ook te vinden over Git en GitHub. Een YouTube video waar ik voor het schrijven van de posts over Git en GitHub veel aan heb gehad is de YouTube video van Kevin Stratvert die zeker de moeite van het bekijken waard is.
We zijn in deze post ingegaan op een branching strategy dat in de meeste bedrijven wordt toegepast, maar je kunt daar helemaal in doorslaan wat Viktor Farcic op een hilarische manier toelicht. Ook die YouTube video is een aanrader.
Hopelijk ben je met deze posting weer wat wijzer geworden en ik hoop je weer terug te zien in één van mijn volgende blog posts. Klik op de Home-button om te zien wat ik nog meer geschreven heb…