Laptop back up maken van je code: stappenplan voor GitHub

Een laptop back up maken van je code doe je in twee stappen: committen en pushen. Een commit bewaart een versie van je werk, maar enkel op je eigen toestel. Pas na een push staat die versie veilig op GitHub. Hieronder leg ik uit waarom dat verschil telt, hoe je werkt zodat je altijd kunt terugvallen, en waar het meestal misgaat.

Is een commit hetzelfde als een back-up?

Nee. Git bewaart je geschiedenis in een verborgen map in je projectmap, op dezelfde schijf als de rest van je werk. Gaat je laptop kapot of wordt hij gestolen, dan verdwijnen je bestanden én je volledige geschiedenis.

Een push maakt een kopie op een andere plek. Dat is wat een back-up is: dezelfde gegevens op minstens twee plaatsen.

Het kost je niets om dat te doen. GitHub Free bevat onbeperkt publieke en private repositories. Kies bij een bedrijfsproject altijd Private, tenzij je bewust open source wilt gaan.

Wat bewaart GitHub wel en niet?

GitHub bewaart alles wat Git volgt. Dat is je code, je configuratiebestanden en je geschiedenis. Wat je in je .gitignore zet, gaat niet mee. Dat is ook de bedoeling voor wachtwoorden en API-sleutels, maar het betekent dat je die ergens anders moet bewaren, bijvoorbeeld in een wachtwoordmanager.

Er zijn ook grenzen aan wat je kunt pushen:

• GitHub blokkeert bestanden groter dan 100 MiB. Video's, grote databases en zware exports horen er dus niet in.
• GitHub raadt aan om repositories klein te houden, liefst onder 1 GB.

GitHub is een back-up van je code, niet van je hele laptop. Je foto's, boekhouding en offertes bewaar je op een externe schijf of in een cloudopslag.

Hoe vaak moet je committen en pushen?

Commit na elke afgewerkte taak. Push op het einde van elke werkdag, of vaker als je dat liever hebt. Dat is alles.

Stel dat je een contactformulier toevoegt aan een website. Dan zijn dat drie commits: het formulier zelf, de validatie en de bevestigingsmail. Gaat de bevestigingsmail later stuk, dan draai je enkel die commit terug.

Eén grote commit per week werkt niet zo. Je weet niet meer wat wanneer stuk ging, en terugdraaien betekent alles of niets.

Hoe schrijf je een commit-bericht dat je later nog begrijpt?

Schrijf één zin die zegt wat je veranderde en waarom. Over drie maanden weet niemand meer wat "fix" betekent, ook jijzelf niet.

Vergelijk deze twee:

• Slecht: "fix"
• Goed: "Corrigeer btw-berekening in offerte: bedrag werd twee keer afgerond"

Met het tweede bericht vind je de oorzaak van een fout in minuten. Met het eerste zoek je uren. Je schrijft het bericht voor jezelf over een half jaar.

Waarom werk je op een aparte branch?

Op de hoofdtak (main) staat je werkende versie. Sommige hostingdiensten rollen je site automatisch uit zodra er iets op die tak verschijnt. Pushen zonder controle betekent dan dat een foutje meteen live staat en je klanten het eerst zien.

Maak daarom voor elke taak een aparte branch. Test daar, bekijk je eigen wijzigingen in een pull request op GitHub en voeg pas daarna samen met main. Ook als je alleen werkt, zie je in zo'n pull request precies wat je hebt aangepast. Je merkt zo vaak nog een vergeten testregel of een bestand dat er niet in hoort.

Heb je een website die klanten leads of bestellingen oplevert? Dan is deze werkwijze het goedkoopste verzekeringspakket dat je kunt nemen. Wil je er een laten bouwen die van meet af aan zo is opgezet, bekijk dan hoe ik werk bij een website laten maken.

Welke fouten maak je makkelijk bij het project op GitHub zetten?

Geheimen mee pushen. Een API-sleutel in je repository blijft in je geschiedenis staan, ook als je het bestand later verwijdert. Zet je .env in je .gitignore vóór je eerste commit. Is het toch misgegaan, vervang de sleutel dan.

Een publieke repo aanmaken. Controleer bij het aanmaken of Private aanstaat. Je kunt dit achteraf wel wijzigen, maar dan is je code al een tijd zichtbaar geweest.

Je eerste push forceren. Sommige tutorials geven een push met -f. Daarmee overschrijf je wat op GitHub staat. Bij een lege repo heb je dat niet nodig, dus laat het weg.

Master in plaats van main. Krijg je een foutmelding over een branch die niet bestaat? Dan heet je lokale tak waarschijnlijk anders dan op GitHub. Met git branch -M main zet je dat recht.

Je back-up nooit testen. Een back-up is pas een back-up als je er iets mee kunt herstellen. Maak één keer in een lege map een git clone van je repo en kijk of het project opnieuw draait.

Je login kwijtspelen. Zonder je herstelcodes en met een kapotte laptop kom je soms niet meer op je account. Bewaar die codes dus elders.

Voorbeeld: je laptop valt morgen in het water

Stel dat je een kleine website onderhoudt voor een bakkerij. Je werkt dagelijks, commit per taak en pusht elke avond. Maandagochtend is je laptop onbruikbaar.

Je neemt een andere laptop, installeert Git en clonet de repository. Je zet je sleutels uit je wachtwoordmanager terug in een nieuw .env-bestand en je werkt verder vanaf je laatste push. Je verliest hooguit de uren sinds die push.

Had je enkel gecommit, dan was alles weg geweest. Dat verschil is alles wat dit stappenplan uitmaakt.

Wanneer is dit niet genoeg?

GitHub dekt je code. Draai je een webshop of CRM met een database vol klantgegevens, dan heb je daarnaast aparte database-back-ups nodig, op een ander systeem dan waar de database draait.

Bouw je automatisaties en koppelingen, bijvoorbeeld met AI-automatisering? Dan bewaar je die scripts en configuraties in Git, en hou je je sleutels elders. Zit je vast bij de opzet of wil je dat iemand meekijkt, dan kun je via contact een vrijblijvend gesprek aanvragen.