🏆Eindproject: Bouw een volledige projectlevenscyclus

Er zijn geen klaargezette bestanden en geen oude commits om te volgen. Je staat in een geïnitialiseerde repository op main en de hele geschiedenis die je achterlaat wordt van jou.

Dit is de eindopdracht van de cursus. Je doorloopt met één piepklein project van gewone tekst een volledige Git-levenscyclus: beginnen, lokale paden beschermen, ontwikkelen op een branch, een conflict oplossen, weggegooid werk herstellen en eindigen met een schone repository die iemand anders kan begrijpen.

Lees het lege beginpunt

Voer gewone git status uit voordat je iets maakt. Die hoort main te melden, nog geen commits en geen wijzigingen.

git status

Kies een project dat klein genoeg is om af te maken

Kies iets dat werkt als één of twee korte tekstbestanden: een leeslijst, paklijst, veldlogboek of een ander klein idee dat je interesseert. Kies je eigen bestandsnamen en inhoud. Het project is alleen de omgeving; het bewijs in zijn Git-geschiedenis is wat telt.

Gebruik nano -w met je gekozen bestandsnaam om het project te maken en te bewerken, zoals eerder in de cursus. Sla elke betekenisvolle wijziging op voordat je die bekijkt en staget.

Je hebt minstens zes commits nodig die vanaf de uiteindelijke main bereikbaar zijn. Laat elke commit één begrijpelijke wijziging voorstellen en geef die een bruikbaar onderwerp op de eerste regel. Een onderwerp is bruikbaar wanneer een lezer kan zien wat veranderde zonder de commit te openen; een leeg onderwerp of de standaardwoorden wip, update en fix doen dat niet.

Gebruik tijdens het werken de controlecyclus uit hoofdstuk 9: bekijk met git status en git diff, stage alleen de bedoelde wijziging met git add, bekijk de gestagede momentopname met git diff --staged en commit die daarna. Het aantal commits kan tijdens alle mijlpalen hieronder groeien, dus je hebt geen zes basiscommits nodig voordat je een branch maakt.

Bescherm lokale en gegenereerde paden

Voeg een gewoon bestand .gitignore toe en commit het. De regels horen virtuele omgevingen in .venv/, Python-cachemappen met de naam __pycache__/ en bestanden waarvan de naam eindigt op .env buiten Git te houden.

Gebruik git check-ignore op representatieve paden voordat je de regels vertrouwt. De laatste geschiedeniscontrole bekijkt elke bereikbare commit. Een van die privé- of gegenereerde paden committen en later verwijderen is dus niet veilig genoeg. Het mag nooit in bereikbare geschiedenis terechtkomen.

Laat twee werklijnen samenkomen

Maak een featurebranch met git switch -c en maak daar een betekenisvolle commit. Kies één al getrackt projectbestand om op de branch te bewerken, want datzelfde bestand draagt straks het bewijs van je oplossing.

Ga terug naar main, bewerk hetzelfde deel van dat gedeelde bestand op een andere manier en commit de wijziging aan de main-kant. Nu bevat geen van beide kanten de andere: de twee branches lopen echt uiteen.

Merge de featurebranch in main met git merge. Git hoort te stoppen bij een conflict in het gedeelde bestand. Lees de gemarkeerde delen, bewerk ze tot één bewust gekozen resultaat dat verschilt van beide ouderversies, stage het opgeloste bestand en maak de mergecommit af. Bruikbare ideeën van beide kanten behouden is vaak de duidelijkste oplossing, maar de precieze woorden kies je zelf.

Als de merge zonder conflict een fast-forward uitvoert, liepen de geschiedenissen niet op de vereiste manier uiteen. Lees git log en git branch en voeg dan het ontbrekende onafhankelijke werk aan de main-kant en featurekant toe voordat je de mijlpaal opnieuw probeert. Het uiteindelijke bewijs moet een echte merge met twee ouders bevatten, niet alleen dezelfde bestanden na een lineaire reeks.

Gooi een commit weg en herstel daarna het echte werk

Maak nog één echte projectwijziging en commit die. Bevestig die commit in git log en gebruik daarna de destructieve techniek git reset --hard uit hoofdstuk 4 om main terug te zetten naar een eerdere commit. Dat is hier opzettelijk: de eindopdracht heeft bewijs nodig dat een echte commit de branch heeft verlaten.

Lees direct git reflog. Zoek de vermelding van de commit waarvan de reset weg bewoog en herstel dat echte werk met git cherry-pick, de herstelroute uit hoofdstuk 4. Vergelijkbare inhoud opnieuw typen in een nieuwe commit is geen herstel, omdat de herkomst uit de weggegooide commit dan verloren gaat.

Gebruik de revisie die jouw reflog toont. Kopieer geen voorbeeldhash uit een les en gok geen vaste positie van HEAD@{...}; jouw eigen geschiedenis bepaalt beide.

Lees de geschiedenis als de volgende samenwerker

Gebruik git log om het verhaal van nieuw naar oud te lezen. Een toekomstige samenwerker hoort de kleine beginwijzigingen te herkennen, de twee werklijnen die in een merge samenkomen en de echte wijziging die je hebt hersteld. Vage onderwerpen vallen veel eerder op als je de geschiedenis als verhaal leest in plaats van als score telt.

Bekijk .gitignore en gebruik git check-ignore nogmaals voor de representatieve paden die alleen lokaal horen. Voer daarna git status uit op main en handel alles af wat gestaged, gewijzigd, ongetrackt of onopgelost is en bij het project hoort. Brengt een van die controles een gat aan het licht, herstel dan de repository met de opdrachten die je al kent in plaats van een tweede project op te bouwen.

Je projectidee, bestandsnamen, featurebranchnaam, meldingen en route door het werk zijn bewust van jou. De gedeelde maatstaf is een leesbare geschiedenis die beide werklijnen bewaart, bewijst dat vastgelegd werk kan worden hersteld, computergebonden bestanden buiten houdt en de volgende persoon een schoon beginpunt geeft.

Voeg voor deze eindopdracht geen remote toe en gebruik geen hostingdienst. Samenwerking is in hoofdstuk 8 beoordeeld; deze laatste levenscyclus blijft binnen één lokale repository zonder netwerk.

Sluit af door git status nog één keer te lezen. Een schoon antwoord is de overdracht: het project heeft een geschiedenis die vertrouwen verdient en de volgende persoon kan beginnen zonder eerst jouw werk te ontwarren.