Minister Hugo de Jonge pusht git-commit op Github

De Nederlandse minister van Volksgezondheid, Welzijn en Sport Hugo de Jonge heeft vrijdag een git-commit gepusht op de Github-pagina van de CoronaMelder-app. Het is voor zover bekend de eerste keer dat een minister een push to master verricht heeft.

De Jonge heeft bij de commit de status van de site coronamelder.nl aangepast van work in progress naar 'gepubliceerd'. In de toelichting schrijft de minister dat hij iedereen die heeft geholpen bij de ontwikkeling van de CoronaMelder-app en bijbehorende projecten zoals de website wil bedanken.

"Een speciaal bedankje gaat uit naar de vrijwilligers die hebben geholpen met het design, de code, documentatie, beveiliging, privacy en constructieve feedback", meldt hij. Hij hoopt dat de app mensen in Nederland gaat helpen gezonder en vrijer te leven. "Dat deze commit een bevestiging van jullie toewijding aan dit doel mag zijn."

Op de ontwikkeling van de app is veel kritiek geweest, maar ook lof voor de transparante manier en de samenwerking met de community voor een overheidsapplicatie. Meer over de ontwikkeling van CoronaMelder is te lezen in het achtergrondartikel Veilige en nuttige corona-app: kan dat? Het is de bedoeling dat de app vanaf 17 augustus te downloaden is voor alle Nederlanders. De app kan vanaf 1 september ook daadwerkelijk gebruikt worden voor contact tracing. Momenteel wordt deze getest door een beperkte groep gebruikers in de regio Twente.

Lees meer

IT Banen

Deel je skills voor jouw droombaan Meld je aan!

Reacties (140)

aequitas
17 juli 2020 15:09

Nu hoeft dit natuurlijk niet de minister zelf geweest te zijn maar gewoon een medewerker van het project. Op Git is het namelijk heel makkelijk om je als iemand anders voor te doen als je gewoon maar wat bij de auteur van de commit invult. Zo ben ik heel trots dat de minister ook meewerkt aan mijn Corona project: https://github.com/aequit...8e3e4bb9a4dad38a368472d87

Dankzij code signing is dit trouwens niet een heel groot probleem: https://docs.github.com/e...to-github/signing-commits

[Reactie gewijzigd door aequitas op 17 juli 2020 15:09]

Jogai
@aequitas • 17 juli 2020 15:22

Haha, is dat waarom op zijn profiel staat dat ie 2 contributions heeft?

aequitas
@Jogai • 17 juli 2020 15:29

Voor zover Github het betreft wel ja. Die controleert de authenticiteit van non-signed commits verder niet. Die neemt de naam en email die jij opgeeft voor waar aan. Dit heeft te maken met waar Git vandaan komt. Het is een tool om samen te werken. Zo kan het zijn dat ik bijvoorbeeld een aantal commits "opgestuurd" krijg van iemand (buiten Github om) en dat ik die dan weer (eventueel met toevoeging van mijn eigen commits) pushen naar Github. Dit zijn dat niet opeens allemaal mijn commits geworden. Ik ben alleen degene die ze pushed.

[Reactie gewijzigd door aequitas op 17 juli 2020 15:59]

Qunix
@aequitas • 17 juli 2020 19:06

Een commit kan natuurlijk ook via zoiets als https://github.com/jayphelps/git-blame-someone-else gedaan zijn. Maar code signing gaat via die tool niet werken.

Overigens is de sleutel "4AEE18F83AFDEB23" de GitHub website zelf. Dus hij heeft het via de website gedaan.

Edit.. Wacht.. Hij pushed op master op een vrijdag!

[Reactie gewijzigd door Qunix op 17 juli 2020 19:11]

aequitas
@Qunix • 17 juli 2020 19:35

Overigens is de sleutel "4AEE18F83AFDEB23" de GitHub website zelf. Dus hij heeft het via de website gedaan.

Daar lijkt het wel op ja. De web interface van Github (en Gitlab ook trouwens) is een ideale manier om leken toch deel te laten nemen aan een Git workflow. Want zelfs voor sommige techneuten is het te lastig of omslachtig om direct in Git te werken van de commandline.

Hellboy!
@aequitas • 18 juli 2020 11:27

Soms een kwestie van ff rustig nadenken

psyBSD
@Qunix • 18 juli 2020 21:34

Pushen naar master doe je minstens 1x per dag, ongeacht de dag van de week.

Als je dat niet durft zijn je changes te groot en neem je te veel risico.

WhatsappHack
@aequitas • 18 juli 2020 00:02

Haha, held.

Toch zou ‘t ergens wel fijn zijn als ‘t niet zo simpel was. Ik bedoel... Ik kan me wat trollgrapjes indenken om 5G conspiracy-wappies op stang te jagen.

PdeBie
@WhatsappHack • 18 juli 2020 12:28

een commit doen op naam van een anti-5G persoon in een pro-5G applicatie. Kan je flinke rel mee oplaaien.

Vraag mij af of je dan voor smaad aangeklaagd kan worden.

MarvinJames
17 juli 2020 14:24

Voor de non-programmeurs, wat is een commit?
Is dat een soort versie 1.0 of zoiets? Een Google opdracht levert wat definities, maar die variëren nogal.

[update]
Fantastisch en complimenten voor alle antwoorden en reacties in alle soorten en maten!

Het is misschien maar een woordje, maar ben toch veel wijzer geworden van alle antwoorden!

[Reactie gewijzigd door MarvinJames op 18 juli 2020 23:51]

mjz2cool
@MarvinJames • 17 juli 2020 14:45

Ik weet niet of ik het zo goed uitleg, maar ik doe een poging:

Een commit is letterlijk gezien een bijdrage.
Je hebt een lokale repository, en een remote repository. De remote repository staat op een host zoals Github, en wanneer je een repository cloned (soort van downloaden naar je computer), staat op je computer de lokale repository. Daarin staan alle bestanden van het project.

Wanneer je code aanpast, sta je niet meer gelijk met je lokale repository. Om dit weer gelijk te trekken kun je je gewijzigde bestanden toevoegen en committen (dus eigenlijk een bijdrage leveren aan je lokale repository). Daarmee is je lokale repository weer up-to-date.

Op dit moment loopt de remote repository achter op je lokale repository. Als je dan de juiste rechten hebt, kun je een push doen naar de remote, om deze ook weer up-to-date te maken.

Je kunt commits gebruiken als een soort historie, en je kunt hiermee ook terugdraaien naar een specifieke commit, wanneer je toch nog iets verkeerd gedaan hebt.

Normaal push je nooit naar de master branch, maar naar een aparte branch, wanneer zo'n branch compleet getest is, kun je een pull request doen om deze samen te voegen met de master branch. (dan "pull" je de branches samen).

Hier een kort filmpje met wat uitleg:
https://www.youtube.com/watch?v=hwP7WQkmECE

ApexAlpha
@mjz2cool • 17 juli 2020 15:58

Sterker nog, normaal staat pushen naar master branche uit als mogelijkheid.

Maar aangezien dit van een ministerie af komt zal een team ambtenaren alles hebben gecheckt voordat dit gebeurde... Al kun je geen kwaad erover spreken bij een kleine commit als deze.

De commit was zelfs 'signed'! Nog een first voor een Minister in Nederland denk ik.

https://i.imgur.com/OdcynyS.png

dashorst248
@ApexAlpha • 17 juli 2020 16:09

Sterker nog, normaal staat pushen naar master branche uit als mogelijkheid.

Citation needed. Ik moet nog mijn eerste repository tegenkomen met pushen naar master branch uit, en ik werk toch al weer wat jaartjes met git.

Het is dan ook organisatie/team afhankelijk hoe je met git en branches overweg gaat.

Mink Z.
@dashorst248 • 17 juli 2020 16:21

Voor zover ik weet staat niet pushen, maar force pushen, uit als default. Dit is in ieder geval zo bij GitLab, waar de master branch standaard protected is.

dashorst248
@Mink Z. • 17 juli 2020 17:41

Niet op github. Daar staan standaard geen protection rules aan. Wanneer je een protection rule aanmaakt kan je meteen niet meer force-pushen--maar daar kan je weer een uitzondering op maken. Kennelijk staat op mijn huidige project force-push naar master uit

(weer wat geleerd).

Op de meeste projecten waar ik op gewerkt heb is er eigenlijk nooit een major copulatie-op geweest (ik heb een keer per ongeluk een git mirror gedaan), en dat is altijd weer te repareren geweest.

Bij de meeste projecten van mijn bedrijfsonderdeel wordt er op het moment van naar productie gaan een versie-branch getrokken van master, ontwikkeling gaat door op master en fixes worden op de versie- en master branches doorgevoerd. Versie staat een maand op productie voor die weer vervangen wordt door de volgende release train.

Uiteindelijk willen we werken naar CD maar daarvoor moet nog een hoop gebeuren om de applicatie (en ons ontwikkelproces) daar geschikt voor te maken.

Mink Z.
@dashorst248 • 17 juli 2020 17:45

Bij de projecten waar ik aan werk wordt ook betreurenswaardig weinig gecopuleerd...

Raymond Deen
@dashorst248 • 17 juli 2020 16:20

Ben er al een heel aantal tegen gekomen en heb zelf ook al een paar keer pushen naar master uit gezet voor de standaard developer rol; teveel fuck-ups mee gemaakt met mensen die git niet helemaal snapten...

pietjuhhh1990
@dashorst248 • 17 juli 2020 16:55

Hangt af van hoe strikt je bent met de security en je CI/CD.
Bij ons kan het alleen via een PR (pull-request) deze moet door minimaal 2 personen geverifieerd worden omdat de master nooit een failing build of iets mag hebben.

Alles is geverifieerd voordat de PR kan worden uitgevoerd omdat het (volgende stap) direct naar productie gepushed moet worden.

Jeffrey_KL
@pietjuhhh1990 • 17 juli 2020 17:29

Dan is jullie CI/CD vreemd opgezet. Een falende build zou überhaupt niet naar productie gepushed moeten worden en gewoon de oude build laten draaien.

RWasseneuseraar
@Jeffrey_KL • 17 juli 2020 20:54

Er staat ook nergens dat de build voor produktie is. Een build gaat na goedkeuring van de PR naar een non-prod, een test systeem.

Als die build failed, houd je dus iedereen tegen.

Jeffrey_KL
@RWasseneuseraar • 18 juli 2020 17:20

Ik weet niet hoor maar pietjuh heeft het toch echt over direct naar productie pushen

pietjuhhh1990
@Jeffrey_KL • 20 juli 2020 10:43

"Alles is geverifieerd voordat de PR kan worden uitgevoerd"

Alles is geverifieerd houd natuurlijk in dat:
Unit tests,
Integration tests
System tests

Allemaal succesvol, een falende test en je PR kan niet uitgevoerd worden.

mjz2cool
@ApexAlpha • 17 juli 2020 16:03

Nee klopt, zo'n wijziging als deze kan niet zoveel kwaad. Alleen moet je dan volgens mij die wijziging in alle andere branches doen wanneer je weer wilt mergen met de master branch, of kan dit met rebase? Ik ben nog niet zo ver met Git verder.
Maar pushen naar de master branche staat volgens mij niet standaard uit, want zo begin ik meestal met een nieuwe repo, dan maak ik een nieuwe lege repo aan, en push ik vanuit een nieuwe local repo naar de master branch. Daarna maak ik nieuwe branches waar ik in ga werken.

[Reactie gewijzigd door mjz2cool op 17 juli 2020 16:28]

ApexAlpha
@mjz2cool • 17 juli 2020 17:23

Nee het staat niet standaard uit. Je kan uiteraard naar de Master branch pushen als je wil.

Wat ik eigenlijk had moeten schrijven:

Pushen naar Master zou uit moeten staan normaal gesproken.

In de meeste grote ontwikkelomgevingen van volwassen teams staat het wel uit. Vaak heb je een PR nodig waar minimaal 2 mensen naar krijgen.

Eén klein foutje naar Master kan fataal zijn. Maar om je eerlijk toe te geven heb ik dat thuis en op de studie ook niet gedaan hoor. Maar je zou willen (en verwachten) dat het bij een groot en belangrijk traject als deze niet kan.

Jeffrey_KL
@mjz2cool • 17 juli 2020 17:25

Als je een aanpassing aan master maakt pull je de master branch weer terug in je develop branches welke op dat moment achterlopen. Maar het maakt niet uit of dit nou een commit rechtstreeks op de master is of gewoon een branch die in de master gepulled wordt.

kakanox
@mjz2cool • 17 juli 2020 16:37

Perfect uitgelegd.
Voor de vraagsteller misschien nog een leuke toevoeging:

Een IT-commit heb je niet alleen op het gebied van version control, maar ook in een database systeem. Werkt meestal net een klein beetje anders; de "commit" is dan het doorvoeren van de bijdrage. Deze ligt daarmee dichter bij de andere betekenis van het Engelse woord commit (to pledge or to bind) - je geeft als programmeur eigenlijk aan bereid te zijn de consequenties van je wijziging aan de database te dragen.
Andere optie is "rollback", dan worden de wijzigingen weggegooid.

Klein voorbeeldje met een record in een adresdatabase:

Piet Puk - Computerstraat 1 - 1234AA Amsterdam - telnr. 020-1234567

Nu komen de wijzigingen:
- verwijder telnr. van Piet Puk
- voeg telnr. 06-12345678 toe
- voeg e-mailadres pietpuk@gmail.com toe

De adresdatabase op dit moment:

Piet Puk - Computerstraat 1 - 1234AA Amsterdam - telnr. 020-1234567

Dan voeren we nu de opdracht Commit uit:

Piet Puk - Computerstraat 1 - 1234AA Amsterdam - telnr. 06-12345678 - e-mail pietpuk@gmail.com

[Reactie gewijzigd door kakanox op 17 juli 2020 16:39]

Great egret
@kakanox • 17 juli 2020 17:24

Sterker nog, als je het adres vervangt met code heb je precies beschreven wat een commit is. Github is een database met code.

pizzafried
@Great egret • 19 juli 2020 11:43

Ja, alleen is een rollback niet meer mogelijk na de commit en is er geen history, tenzij je dat zo inricht natuurlijk.

LuBJe
@mjz2cool • 17 juli 2020 21:52

Toch komt ook http://trunkbaseddevelopment.com/ nog veel voor.

woopdiedoo
@mjz2cool • 18 juli 2020 20:12

Normaal push je nooit naar de master branch, maar naar een aparte branch, wanneer zo'n branch compleet getest is, kun je een pull request doen om deze samen te voegen met de master branch. (dan "pull" je de branches samen).

Als ik naar de commit history kijk (https://github.com/minvws...pp-website/commits/master) dan zie ik een hele sloot aan commits die geen branch of pull request merges zijn. Zijn dit niet ook gewoon commits direct naar master? En is dit niet hartstikke normaal? Ik heb persoonlijk nog nooit een repo gezien waarin elke commit in de master branch van ofwel een pull request ofwel een andere branch af komt.
Maar misschien begrijp ik het niet goed, ik heb slechts oppervlakkige kennis van git. Net genoeg om lokaal wat projectjes te managen maar meer ook niet.

mjz2cool
@woopdiedoo • 20 juli 2020 07:43

Meestal hou je de master branch als meest recente werkende versie (vanuit mijn eigen ervaring). Ik weet niet hoe je bij Github kunt zien of commits vanuit een merge komen, ik werk zelf met Gitlab. Bij Gitlab heb je dan een heel mooi overzicht (graph), waar je heel goed kunt volgen hoe je branches lopen.

Juicy
@MarvinJames • 17 juli 2020 14:28

Een commit is een change van een persoon die een bijdrage levert met daarin nieuwe en/of gewijzigde resources.

David Mulder
@Juicy • 17 juli 2020 14:56

Bedankt voor de 'juistere' definitie. Het feit dat hier een hele serie programmeurs een commit omschrijven als het opslaan van code maakte me enigszins bang.

Een commit (in git) is enkel iets dat zegt:
[Pak versie XYZ123 van de code]
Voer de volgende diff uit:
Verwijder deze en deze lijn(en)
Voeg deze en deze lijn(en) toe
[Noem het nieuwe resultaat XYZ124]

Die 'diff' is de verandering die de programmeur heeft uitgevoerd. In het geval van deze minister veranderde dat dus 1 woordje ergens. Die commit beschrijft enkel de verandering. Het deel 'pak deze versie' en 'noem het nieuwe resultaat' zijn als ik goed begrijp technisch gezien niet deel van de commit, maar het is makkelijker om er wel degelijk zo over te praten.

'to commit' als werkwoord verwijst dus naar het process waar je kijkt naar alle wijzigingen die je momenteel sinds de laatste 'versie', en die wijzigingen worden daarna omschreven en opgeslagen in een commit.

Voor de programmeurs hier die het omschreven als opslag van code: De reden waarom het zo belangrijk is om te begrijpen dat een commit enkel een 'diff' is, is omdat acties zoals een rebase (pak een serie van commits (diffs) en voer ze uit op een andere 'versie') en een cherry-pick (pak een commit uit een andere branch of moment en voer hem uit op de huidige code) dan een stuk makkelijker te begrijpen zijn. Niet dat dat een belangrijk onderscheid is voor MarvinJames, maar als programmeur zijnde is het extreem belangrijk om goed gebruik te maken van git.

[Reactie gewijzigd door David Mulder op 17 juli 2020 14:56]

Ayporos
@David Mulder • 17 juli 2020 15:23

'To Commit' kun je definiëren als:
besluiten iets te doen of je ergens voor in te zetten (I commit myself to this cause)
iets uitschrijven/noteren/opslaan op een bepaald medium (to commit to paper)
het uitvoeren van een actie (to commit a crime)

Het is dan ook, mijns inziens, begrijpelijk dat men het interpreteert als:
"ik commit deze code aan de code-base" met de connotatie dat het 'opslaan' ervan een integraal onderdeel is. i.e. Ik heb een verandering gemaakt gedurende een week lang coderen en nu 'vereeuwig' ik deze verandering in deze commit.

In jou voorbeeld is het dus vooral het stukje [Noem het nieuwe resultaat XYZ124] dat relevant is, want dat is, mijns inziens, het stukje 'vereeuwiging' wat het gebruik van het woord 'commit' rechtvaardigt.

[Reactie gewijzigd door Ayporos op 17 juli 2020 15:25]

robvanu
@David Mulder • 17 juli 2020 16:47

Behalve dat een commit in Git technisch gezien geen diff is maar een volledige snapshot. Een commit wordt altijd getoond als een diff maar dat is slechts een visualisatie van de commit tov de parent commit.

David Mulder
@robvanu • 18 juli 2020 13:20

Dat is juist het ding, een commit is geen snapshot. Dat was het hele punt van m'n comment. Een commit is een diff en alle diffs bij elkaar zorgen voor een specifiek resultaat. Natuurlijk heeft git bepaalde caches enzo, maar een commit an sich is enkel een diff met metadata. En duidelijke consequentie hiervan is dat dezelfde commit op twee branches kan worden toegepast (via cherry pick bijvoorbeeld), alhoewel het resultaat wel twee verschillende commit hashes vanwege de verschillende geschiedenis.

[Reactie gewijzigd door David Mulder op 18 juli 2020 13:22]

robvanu
@David Mulder • 18 juli 2020 16:52

Nee, zie bijv. https://shafiul.github.io...the_git_object_model.html

Kees
@MarvinJames • 17 juli 2020 14:39

Heel erg simpel gezegt is een 'commit' het opslaan van je code. De minister heeft dus de code van de website gedownload, daar een verandering in aangebracht en dat opgeslagen.

Omdat je vaak met meerdere mensen gelijktijdig aan zo'n project werkt is het opslaan van zo'n wijziging meestal aan regels gebonden. Zo moet je vaak uitleggen wat je veranderd hebt en waarom.

De combinatie van het opslaan in github + de uitleg van wat er veranderd is is een 'commit'. Het voordeel van een systeem als git is dat elke commit een punt in de geschiedenis van de code is. Als je dus een foutje hebt gemaakt dan kun je de veranderingen in de code terugdraaien door naar een oudere 'commit' te gaan.

En je kan ook makkelijk twee of meer 'commits' met elkaar vergelijken en zo eenvoudig de veranderingen te zien. Zo kun je zien dat de minister deze veranderingen in de tekst heeft gedaan:
- **Status:** work in progress
+ **Status:** [published](https://coronamelder.nl)
hij heeft de regel 'work in progress' weggehaald en vervangen door de tekst 'published' met een link naar de website.

Deze wijziging is overigens puur symbolisch. Zie het als het knippen van een lint om een gebouw te openen. Al het werk is al gedaan, en deze verandering doet niets anders dan een lintje doorknippen.

COW_Koetje
@Kees • 17 juli 2020 15:00

Zou het geen mega grap zijn dat die avond the compile compleet vast zou lopen na die commit.
Ik weet dat het een comment veld is maar zoals zoveel niet technische mensen dingen weten te slopen die dummyproof zijn zou dit wel sarcamse ten top zijn.

Toevoeging ... vergeten humor is hier niet gewaardeerd.

[Reactie gewijzigd door COW_Koetje op 17 juli 2020 16:03]

SPee
@COW_Koetje • 17 juli 2020 18:32

Humor??
Paar jaar geleden kreeg ik op een nieuw project een falende build op master, terwijl ik alleen een lege regel in een properties bestand had toegevoegd.

Toegegeven, de tests waren op dat moment niet stabiel. Dus elk team had er last van en het was meer geluk dan dat het lukte. Dat is gelukkig nu beter.

ookhoi
@Kees • 17 juli 2020 15:08

Als je dus een foutje hebt gemaakt dan kun je de veranderingen in de code terugdraaien door naar een oudere 'commit' te gaan.

Je kan niet terug naar een oude commit. Je kan een commit enkel effectief terugdraaien met een nieuwe commit die de changes terugdraait: https://git-scm.com/docs/git-revert

git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one).

raptorix
@ookhoi • 17 juli 2020 15:17

Het kan wel, maar is niet heel gebruikelijk, er kunnen situaties zijn waarin bijvoorbeeld iemand per ongeluk credentials heeft mee gecommit.

Pizzalucht
@ookhoi • 17 juli 2020 15:12

Je kan (als je de rechten hebt) terug naar een specifieke commit met "git reset" en een force push.

DenBeke
@ookhoi • 17 juli 2020 15:12

Je kan niet terug naar een oude commit. Je kan een commit enkel effectief terugdraaien met een nieuwe commit die de changes terugdraait

Alles kan met git

git reset --hard HEAD~1

[Reactie gewijzigd door DenBeke op 17 juli 2020 15:12]

khoatran
@MarvinJames • 17 juli 2020 14:28

Een commit is een soort van save momentje van de code. Net alsof je tijdens je word documentje op ctrl+s drukt zodat je het niet kwijtraakt!

Bij een commit hoort vaak een beschrijving. Zo houdt git alle commits bij, en kun je zien wat er is gebeurd bij welke commit. Mocht er op een gegeven moment iets fout gaan, dan kun je altijd teruggaan naar een eerdere commit waarvan je weet dat die wel werkte.

Sammiege
@khoatran • 17 juli 2020 16:43

Dit is toch echt de beste uitleg in lekentaal. Nice

sympa
@Sammiege • 17 juli 2020 22:07

Alleen in Word ben je alle vorige versie "kwijt". Maar Git houdt het allemaal bij.
(Wanneer wordt dat 'save' paradigma eens aangepast? Het is niet handig, en ook niet logisch als je van document A document B wil maken. Je moet eerst 'save as B' doen - maar dan heb je document B met de inhoud van A. Waarom niet continu opslaan, en "Label this version as A"?
Schijfruimte is goedkoop. Al jaren.

Gamebuster
@MarvinJames • 17 juli 2020 16:55

Ik ga meedoen met de uitleg-stroom:

Een commit is een groep aan wijzigingen relatief aan een andere commit.

Een commit is meestal een set aan wijzigingen gedaan door 1 persoon in een relatief korte tijd. Software die op deze manier ontwikkeld wordt bestaat dus uit een gigantische stroom aan "commits". De 1e commit voegt bijv. een set bestanden toe. Een 2e commit zegt "neem de 1e commit, en doe deze wijzigingen". Een 3e commit kan vervolgens weer dingen wijzigen over het resultaat uit de 2e commit.

In sommige gevallen kunnen commits ook verwijzen naar niet-de-laatste commit. Je bent volledig vrij commits te maken in de keten aan commits, en dit wordt ook veel gedaan. Zo kan je 2 commits hebben op basis van dezelfde commit. Deze 2 commits kan je vervolgens weer samenvoegen in een 3e commit en op basis van deze 3e commit kan je weer verder bouwen.

Zo kan men meerdere versies van hetzelfde programma hebben, met kleine (of minder kleine) wijzigingen, en kunnen deze wijzigingen effectief beheerd, gecontroleerd en samengevoegd worden.

Commit A van Jan is bijv. "voeg README toe (12 regels tekst)"
Commit B van Jan is bijv. "Neem Commit A, maar wijzig regel 4 in README"
Commit C van Piet is bijv. "Neem Commit A, maar wijzig regel 8 in README"
Commit D van Jan is bijv. "Neem Commit B en C en voeg deze samen" (en hiermee is dus zowel regel 4 als 8 aangepast)
Commit E van Piet kan bijv. weer zijn "Neem Commit C, maar wijzig ook regel 9".
Commit F weer samenvoegen: "Neem Commit D en E, en voeg deze samen"

Belangrijk detail bij Git specifiek is dat het mogelijk is dat commits dus niet na elkaar volgen. Er kunnen vele takken zijn van de software die parallel worden ontwikkeld die later weer moeten worden samengevoegd.

[Reactie gewijzigd door Gamebuster op 17 juli 2020 17:00]

ro8in
@MarvinJames • 17 juli 2020 14:27

Een commit in het geval van git is eigenlijk heel simpel gezegd dat je het opslaat in je lokale repository.

Om het te begrijpen kan je het beste gewoon even lezen over wat git inhoud en het concept van version control. Dan snap je eigenlijk ook meteen wat een commit is.

[Reactie gewijzigd door ro8in op 17 juli 2020 14:28]

mjz2cool
@ro8in • 17 juli 2020 15:09

Het is niet echt opslaan. Het bevat je wijzigingen. In een commit kun je precies zien wat er gewijzigd is, en je kunt bijvoorbeeld terug naar een commit, waarmee al de wijzigingen in recentere commits ongedaan gemaakt worden. Een commit zegt alleen maar wat er is gewijzigd in welk bestand.

ro8in
@mjz2cool • 17 juli 2020 15:19

En toch is dat wel opslaan. Je slaat je wijzigingen op op je opslagmedia. Het gebeurd alleen op zo een manier dat je ook vorige versies nog opgeslagen hebt. Je schrijft er niet overheen.

vickypollard
@ro8in • 17 juli 2020 16:25

Een set van wijzigingen opslaan is niet hetzelfde als code opslaan. De wijzigingen kun je niet correct uitvoeren als je niet de juiste basis hebt. Als je code zou opslaan zou dat niet zo uitmaken.

Zo begrijp ik het althans.

Xm0ur3r
@MarvinJames • 17 juli 2020 14:27

Bijdrage, als ik het goed heb

ThijsImmink
@MarvinJames • 17 juli 2020 14:36

Vaak wordt Git (https://git-scm.com/) gebruikt als versie control system. Als je lokale code wilt opslaan in een extern systeem gebruik je git add, commit & push. De add voegt files toe en met commit kan je dat bundelen en vertellen wat het bevat met een bericht. De push stuurt dan 1 of meerdere commits op. In zijn commit zat een README file die geupdate is en hij heeft daarbij een 'commit' bericht getypt wat in het blauw erboven te zien is.

[Reactie gewijzigd door ThijsImmink op 17 juli 2020 14:37]

arianvp
@MarvinJames • 17 juli 2020 14:28

Commit Zou ik vertalen naar "aanpassing"

Redsandro

@arianvp • 17 juli 2020 14:57

"Bijdrage"

mjz2cool
@arianvp • 17 juli 2020 15:12

De aanpassing doe je al in je IDE of texteditor. Deze aanpassingen "commit" je dan naar de branch waar je in werkt.

dez11de
@MarvinJames • 17 juli 2020 14:31

Een developer bewerkt een bestand op zijn eigen computer, slaat dat op, doet een commit, daarna nog een push naar de repo(github server) en dan is het voor iedereen beschikbaar.

dutchgio
@MarvinJames • 17 juli 2020 14:37

Een wijziging.

darkfader
@MarvinJames • 17 juli 2020 14:52

in het half-Engels.. een snapshot van de (source)files.
Daar hoort een commit-ID bij. meestal verkort tot eerst 7 of 8 hexadecimale cijfers.
Je kunt ook nog wijzigingen maken bovenop de commit en is je commit "dirty". Ook nieuwe files of executables kunnen er voor zorgen dat de checkout "dirty" is. Meestal gebruik je hiervoor een ignore file.
Wijzigingen kun je (gedeeltelijk of volledig) "stagen" en staan dan in de wachtrij om een nieuwe commit van te maken.
Daarna moet je de commits pushen naar de repository (in een bepaalde branch) zodat andere mensen er weer meer verder kunnen.

StefanJanssen
17 juli 2020 14:23

Zomaar op vrijdag in de master branch pushen.

bazzi

@StefanJanssen • 17 juli 2020 14:43

dat is vragen om problemen

Gebeurd meestal met een biertje in de hand en dan hoor je in ene K*T

Giant87
@bazzi • 17 juli 2020 15:42

Hahaha, opeens bekruipt dan je dat nare gevoel 'uh oh', zweet breekt uit et cetera et cetera.

Blokker_1999

Overheid
Software development

@Giant87 • 17 juli 2020 16:44

Snel naar huis want het is weekend.

Jay-v
@StefanJanssen • 17 juli 2020 15:10

Geen pull request, code review, tests, etc. Gewoon direct naar master. Cowboy hoor die Hugo 😁

vickypollard
@Jay-v • 17 juli 2020 17:14

Het is slechts een comment, kan toch niks fout gaan.

*2 seconden later*: database klapt eruit, server in de fik, app doet niks meer en de Belastingdienst is op een of andere manier alle aangiftes van de afgelopen 10 jaar kwijt

[Reactie gewijzigd door vickypollard op 17 juli 2020 17:15]

dejeroen
@Jay-v • 17 juli 2020 17:26

Dat is de nieuwe normaal.

mjz2cool
@StefanJanssen • 17 juli 2020 15:15

Dat vond ik wel bijzonder, ik ben niet anders gewend dan te pushen naar een aparte branch (meestal per nieuwe feature), en wanneer dit door de tests is gekomen wordt dit weer gemerged met een volgende branch, om vervolgens weer gemerged te worden met een "RC" branch, en dan als laatste met de master branch.

sircampalot
17 juli 2020 14:21

Goed dat dit opensource is, maar hoe kan je checken of de package die je krijgt uit de store, dezelfde code bevat/is als published op github?

mjz2cool
@sircampalot • 17 juli 2020 14:25

Dat heb je altijd, de enige manier om 100% zeker te zijn is door zelf de sourcecode te downloaden en te compilen.

The Zep Man
@mjz2cool • 17 juli 2020 14:30

Dat heb je altijd,

Niet met reproducible builds. Toegegeven, je moet nog steeds iets compileren. Het resultaat hoef je echter niet te gebruiken zolang het maar gelijk is aan de geleverde gecompileerde en ondertekende code.

[Reactie gewijzigd door The Zep Man op 17 juli 2020 14:32]

arianvp
@The Zep Man • 17 juli 2020 14:38

Zie ook de discussie hier: https://github.com/minvws...app-coordination/issues/6

mjz2cool
@The Zep Man • 17 juli 2020 14:33

Klopt, maar dan moet je dus inderdaad nog wel compilen. Als je deze mogelijkheid hebt is het natuurlijk wel een goeie optie, dan kun je gewoon de Playstore/Appstore versie gebruiken.

PPie
@mjz2cool • 17 juli 2020 17:03

Dat heb je altijd, de enige manier om 100% zeker te zijn is door zelf de sourcecode te downloaden en te compilen.

Helaas, zelfs dan niet.

Uit Reflections on Trusting Trust van Ken Thompson (die van de taal C):

The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

En quote 2:

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.

(Wel heerlijke zelfspot

)

sircampalot
@mjz2cool • 17 juli 2020 14:28

Levert de signing bij zelf compilen dan geen verschil in output blob op?

mjz2cool
@sircampalot • 17 juli 2020 14:35

Jawel, maar ik bedoel meer dat je dan de zelf gecompilede app kunt gebruiken (als deze mogelijkheid er is tenminste).

84hannes

@sircampalot • 17 juli 2020 14:47

Niet per sé.
https://en.m.wikipedia.org/wiki/Reproducible_builds

watercoolertje

Software development

@84hannes • 17 juli 2020 15:01

Werkt dat ook voor OSen die juist afhankelijk zijn van in de app gebakken certificaten die je in principe nooit vrij wil geven? Zoals iOS en Android dus.

[Reactie gewijzigd door watercoolertje op 17 juli 2020 15:02]

84hannes

@watercoolertje • 17 juli 2020 15:16

Ik neem aan dat die certificaten niet voortdurend veranderen. Een groot probleem voor reproduceerbaarheid is vaak dat ergens de tijd/datum van compilatie wordt vermeld, of dat verschillende versies van de compiler of gebruikte bibliotheken een rol spelen. Het is in mijn beperkte ervaring bij grote projecten eerder uitzondering dan regel dat een binary herproduceerbaar is.

edit:
Vraag verkeerd begrepen

De overheid zal wel een certificaat hebben waarmee ze de app ondertekenen. In het beste geval kan de overheid de binaries reproduceren maar voor ons stervelingen kan dat waarschijnlijk niet, tenzij de ondertekening in een apart bestand gebeurt. Wel is het denkbaar dat je met een HEX-editor precies kan inzien waar de verschillen zijn en kan concluderen dat alleen de ondertekening anders is.

[Reactie gewijzigd door 84hannes op 17 juli 2020 15:56]

Snake
@84hannes • 17 juli 2020 17:19

Ja maar de builds in de App Store en Play Store zijn signed.

Kewne
@sircampalot • 17 juli 2020 19:42

Reproducible builds zijn vooral begonnen op distributie niveau. Daar hebben ze de lat heel hoog gezet: het moet eigenlijk volledig geautomatiseerd tot op de bit kunnen gebeuren. Niet zo gek als je denkt aan distros als Debian met ver boven de 10000 pakketten die het als het even kan op ieder pakket willen hebben.

In de vertaling naar andere platforms is het heel normaal geworden om dat soort gegevens in de vergelijkingen aan beide kanten ofwel helemaal weg te strippen door een eigen diff script te gebruiken, of te kopiëren van de officiële release (daarna zou het een geldige signature moeten zijn), of specifiek kijken naar de verschillen met speciale tools (bv diffoscope, tooltje dat recursief naar de inhoud kijkt) en de verschillen per release met de hand te beoordelen. Dat maakt het een stuk lastiger om het op schaal automatisch te doen, maar voldoet als het gaat om enkele projecten als deze.

Bobby Rifler
@sircampalot • 17 juli 2020 14:24

Goede vraag. Waarschijnlijk kan je dat zien door de app te decompilen.

walteij

@Bobby Rifler • 17 juli 2020 15:23

App zelf compilen (met dezelfde compiler) dan van alle bestanden een MD5 sum genereren, de app zelf downloaden van de store en daar ook van alle bestanden een MD5 sum van genereren.

De MD5 sums zouden dan met elkaar overeen moeten komen.

Wat je ook zou kunnen doen, is sideloaden toestaan op je device, de code downloaden en compileren en op die manier op je toestel installeren.

01--Rolf--01
@sircampalot • 17 juli 2020 14:36

Misschien moet je het even compileren op de zelfde manier doen als de ontwikkelaars. Denk dat dit probleem ook bij bank-app of digid-app speelt, denk dat er gewoon oplossingen voor zijn.

mysterion1989
@sircampalot • 17 juli 2020 14:38

daar kun je wel van uit gaan

Ikheetchris
@sircampalot • 17 juli 2020 14:49

Herpoduceerbare builds maken? Alhoewel dit lastiger gaat als je API-sleutels enzovoorts je applicatie induwt.

Als de buildsystemen het toelaten, zou jij als gebruiker precies dezelfde binary moeten krijgen als die op Google Play staat. Deze zul je dan wel van je telefoon af moeten halen, maar dan zou je ze wel moeten kunnen vergelijken.

F-Droid en Telegram doen het al, het kost alleen wat moeite vanuit de kant van de appmakers.

[Reactie gewijzigd door Ikheetchris op 17 juli 2020 14:53]

Tk55
17 juli 2020 14:22

Goed dat een minister zo betrokken is bij het uitvoerend werk binnen de IT.

CEx
@Tk55 • 17 juli 2020 14:28

Dit is natuurlijk een publiciteitsstunt en heeft niks met betrokkenheid te maken.

Oyxl
@CEx • 17 juli 2020 14:30

Ja dit is letterlijk het lintje doorknippen van vroegah.

HMC
@Oyxl • 17 juli 2020 14:36

Of zelfs een een stagiaire, of iemand die hem door het proces leidde. Net zoals Biden zijn eigen tweets niet tikt.

bvdbos

@HMC • 17 juli 2020 15:05

Ik neem trouwens aan dat @barefoot hem hiermee geholpen heeft

barefoot
@bvdbos • 20 juli 2020 20:28

Hij was net wat te druk voor een online cursus, dus hij heeft wat hulp gehad zo links en rechts 😉

bvdbos

@HMC • 17 juli 2020 15:03

Tuurlijk iemand die hem door het proces leidde. Een minister van ICT zou dit wellicht zelf kunnen maar ik verwacht niet dat een willekeurige minister weet hoe GH werkt...

bazzi

@HMC • 17 juli 2020 15:10

stagiaire doorknippen

HMC
@bazzi • 17 juli 2020 15:19

Niet precies wat ik bedoelde.

dasiro
@Tk55 • 17 juli 2020 16:08

sarcasm overflow

je zal maar maanden gewerkt hebben aan een app met de grootste exposure ooit, om dan een of andere politieker met de kers op de taart te laten gaan lopen, omdat hij wat mediageil is en speciale aandacht wil.

Smuey
17 juli 2020 14:36

Sja. Dit is natuurlijk niet veel meer dan een publiciteitsstunt. Op zich fijn dat er zowaar wat betrokkenheid van de betreffende politicus getoond wordt, maar het voelt vooral heel erg als een 'First!'-post.

The_Woesh
@Smuey • 17 juli 2020 15:01

Het is ook een signaal die hij wilt maken. Hiermee komt hij in het nieuws en wordt nogmaals het openscource character van de app benadrukt.
Hiermee wil hij zeggen tegen het volk: kijk, dit hebben we samen met de nerds van de opensource community gebouwd. Dat zijn dezelfde nerds die altijd zaniken over privacy. Als zij het steunen, dan zit het wel goed. Allemaal downloaden die app dus!

CAPSLOCK2000

Overheid
Software development

@Smuey • 17 juli 2020 16:47

Is het ook, maar dat is nu eenmaal wat ministers doen.
Dit is niet anders dan een lintje doorknippen of een eerste steen leggen. Ze hebben de minister echt niet nodig om dat lint door te knippen voor ze het gebouw in gebruik kunnen nemen en die eerste steen is typisch niet echt de eerst steen.
Hoort er bij.

Ik zie het liever van de positieve kant. Een publiciteitsstunt doe je alleen als je denkt dat je er aandacht mee trekt. Blijkbaar is git en programmeren inmiddels normaal genoeg in onze samenleving dat er ambtenaren zijn die naar Github gaan voor een publiciteitsstunt. Dan hebben we met z'n allen toch iets goed gedaan.

provoost
@CAPSLOCK2000 • 17 juli 2020 22:27

Ik moest ook aan de lintje knippen analogie denken. Lijkt me een prima traditie. Wel even met een Ministeriële PGP sleutel code signen...

Zwarte_os
@Smuey • 17 juli 2020 14:54

Dit heeft niets met betrokkenheid te maken, alles met publiciteit.

bvdbos

17 juli 2020 15:00

Zie toch wel wat zure reacties voorbijkomen. Ik vindt het wel leuk en daarmee laat hij (danwel het ministerie) wel zien dat ze zich bewust zijn van hetgeen wij (ondermeer en over het algemeen) een belangrijk uitgangspunt vinden.

bartcramer

17 juli 2020 15:01

Is het publiciteit zoeken wat de minister hier doet? Zeker!

En toch is het wel bijzonder.

Het gegeven dat we nu een app hebben, waarvan de volledige source (incl historie) ingekeken kan worden, geeft toch wel aan dat dingen schuiven. En dat de minister geen lintje knipt, maar een commitje doet, is leuk gevonden. Het is ook een symbolische stap naar: het is betaald van ons belastinggeld, dus wij mogen ook zien wat daarmee gebeurt. Ik hoop van harte dat dat het komende decennium de standaard gaat worden.

Vexxon
17 juli 2020 15:58

Een van de eerste comment op de commit:

Normally we make a pull request, but the minister just pushed to master . Welcome to to Github anyway

Voor zover ik kan is het niet zo, maar is er nog gebruik gemaakt van één of andere SDK van Facebook o.i.d.?

[Reactie gewijzigd door Vexxon op 17 juli 2020 16:03]

Blokker_1999

Overheid
Software development

@Vexxon • 17 juli 2020 16:47

Waarom zou men daarvan gebruik maken in een app waarvan je weet dat privacy belangrijk is? Er worden geen accounts in gebruikt, iedereen moet anoniem kunnen blijven. Waarom zou je de FB SDK willen gebruiken?