Versiebeheersysteem Git bestaat twintig jaar

Het opensourceversiebeheersysteem Git bestaat twintig jaar. Er is ter ere van deze verjaardag een Discord-kanaal geopend waarbinnen gebruikers hun leukste verhalen over de software kunnen delen.

Git is een tool om aanpassingen in software bij te houden. De software werd op 7 april 2005 uitgebracht door Linus Torvalds, die toen ook de eerste commit deed: "Initial revision of Git, the information manager from hell", stond daarin.

De Linux-bedenker en -ontwikkelaar zocht dat jaar naar een alternatief voor de gratis BitKeeper-software die hij en zijn collega’s gebruikten om Linux verder te ontwikkelen. BitKeeper ging later door als betaalde software, omdat er een conflict over de gebruiksvoorwaarden was ontstaan.

Torvalds was op 3 april 2005 met de ontwikkeling van Git begonnen en had een eerste versie klaar op 6 april. Een dag later, op 7 april, hostte hij het versiebeheersysteem ook zelf. Na enkele iteraties waarbij onder andere de snelheid en stabiliteit van Git werden verbeterd, droeg Torvalds het project over aan ontwikkelaar Junio Hamano. Deze bevriende ontwikkelaar heeft meegewerkt aan de 1.0-versie van de software die in december 2005 werd gepubliceerd.

De naam van de software slaat volgens Torvalds op het Engelse slangwoord git. Het woord staat voor een onaangenaam persoon. Torvalds zegt dat hij de software naar zichzelf heeft vernoemd, maar ook dat git alles kan betekenen wat de gebruiker zelf wil. Enkele Git-ontwikkelaars hebben ondertussen een Discord-kanaal geopend waar verhalen met betrekking tot de software kunnen worden gedeeld.

Reacties (82)

Wraldpyk 7 april 2025 14:57

En wat een uitkomst dat git is! Ik had jaren met SVN gewerkt en dat werkte destijds prima, ik begreep dan eerst ook niet waarvoor git een voordeel in was. Maar ik zou nu echt niet meer terug willen naar svn. Niet vreemd dat ik ook al tenminste 10 jaar geen enkel bedrijf, persoon of project tegen ben gekomen die geen git gebruikt.

Ik ben benieuwd of het beter kan, maar voor nu, heel blij mee!

nzall

@Wraldpyk • 7 april 2025 15:03

Wij gebruiken intern nog altijd subversion. Dat heeft te maken met onze interne processen voor development en toolset.

Ryen @nzall • 7 april 2025 15:19

Als SVN goed werkt is er niet zoveel mis mee. Git ondersteunt inmiddels wel meer integraties met andere producten. Op een gegeven moment kan het interessant worden je interne processen aan te passen.

nzall

@Ryen • 7 april 2025 15:39

Het gaat niet zozeer over het BESTAAN van integraties met andere producten. ons probleem is eerder dat Git net iets anders werkt in verband met branchen, mergen en committen dan Subversion. Ik kan het niet helemaal herinneren, maar volgens mij was de hoofdoorzaak dat je in Eclipse met Git niet zomaar slechts een deel van je wijzigingen kunt committen, terwijl dat wel mogelijk is in Subversion.

Wij hebben namelijk in onze producten een aantal bestanden staan die wel geversioneerd zijn, maar zelden of nooit gecommit mogen worden, omdat deze bestanden te maken hebben met de locaties en/of credentials van tools die gebruikt worden tijdens tests of als onderdeel van development. Als deze bestanden worden aangepast riskeren we dat deze tests falen tijdens de nightly build of op de machines van collega's.

het probleem is dus dat deze bestanden wel lokaal aangepast zijn op onze development machines, maar deze wijzigingen mogen niet gecommit worden. En onze teamleider beweert dat het met eGit of andere Eclipse Git oplossingen enkel mogelijk is om ALLE veranderde bestanden te committen, en niet enkel die bestanden die nodig zijn om de nieuwe ontwikkelingen te doen werken.

Nu vraag je je misschien af: waarom gebruiken we Eclipse en niet IntelliJ voor Java development? Dat komt omdat IntelliJ voor andere redenen niet compatibel is met onze werkwijze. Zo is in IntelliJ de regel: 1 workspace = 1 project en maar 1 branch van dat project. Maar enerzijds hebben wij vaak meerdere projecten tegelijk openstaan in dezelfde workspace, en anderzijds hebben wij ook vaak van hetzelfde project meerdere branches openstaan in dezelfde workspace. Mijn collega's gebruiken zelfs maar 1 workspace voor alle projecten en alle versies van dit project, en ze closen gewoon die projecten die ze niet nodig hebben. In IntelliJ is dat niet mogelijk.

BRAINLESS01 @nzall • 7 april 2025 16:37

Zomaar wat ideeën:

Je haalt de bestanden met credentials uit je git repository en voegt ze toe aan .gitignore. Nadeel van deze methode is dat nieuwe ontwikkelaars dan de bestanden ergens vandaan moeten halen. Als je ooit credentials wil wijzigingen moeten alle ontwikkelaars dat handmatig doorvoeren.
Je laat de bestanden in git staan en voegt ze toe aan .gitignore. Nadeel van deze methode is dat commit niet standaard werkt voor die bestanden, want die wilde je negeren. Zover ik weet kun je ze dan alsnog handmatig toevoegen, dus dat werkt prima als je sporadisch wijzigingen door wil voeren.
Een extra bestand voor ontwikkelaar-specifieke credentials toevoegen, die voeg je dan toe aan .gitignore. Als je dan altijd de standaard credentials eerst leest kan het ontwikkelaar-specifieke bestand instelling overrulen. Zo heeft iedereen de standaard credentials, terwijl iedereen zijn eigen credentials kan gebruiken waar nodig.
Bedenk een systeem waarbij deze bestanden niet langer onderdeel zijn van je repository, maar wel vanaf iedere machine bereikbaar zijn. Dit is meteen een mooi moment om iets aan security te doen, want certificaten, credentials en andere secrets kun je zo scheiden van je repository. Als je alles in-house hebt is het probleem hierbij minder groot, maar als je bijvoorbeeld cloud diensten gebruikt voor buildservers of repositories dan is het prettig als secrets niet bij externe partijen bekend zijn.

Wij gebruiken deze methode in combinatie met Github, daar staat alle code maar de secrets houden we intern. Zo kunnen we ook eenvoudig de verschillende omgevingen configureren, dan zetten we er simpelweg een ander secrets bestand (en bijbehorende settings) neer. Bij ons staan de secrets gewoon in bestanden (encrypted, maar wel machine readable), het is dus niet enorm complex om zoiets op te zetten. Als onderdeel van de build actie worden de bestanden van het netwerk geplukt, zo heeft iedere ontwikkelaar altijd up-to-date bestanden. Voor ontwikkelaar-specifieke settings en credentials zou ik alsnog een apart bestand maken die de standaard settings overruled, dan kun je tijdens het build proces altijd de standaard bestanden overschrijven.

JustFogMaxi @nzall • 7 april 2025 15:54

Je kan ook een andere git client gebruiken. Ik zou eens poc maken en een demo geven aan je teamleider...

YopY

Software development

@nzall • 7 april 2025 17:13

volgens mij was de hoofdoorzaak dat je in Eclipse met Git niet zomaar slechts een deel van je wijzigingen kunt committen

Daarom gebruik ik bij voorkeur niet een client of IDE om met versiebeheer om te gaan. Git zelf ondersteunt het wel door middel van git add --patch.

De rest van je comment geeft aan dat je eigenlijk een security probleem hebt mbt files die je niet mag wijzigen of committten en dergelijke; daar zijn technieken voor, kijk bijvoorbeeld eens naar de 12 factor app, specifiek het stukje over config.

Hoopje @nzall • 7 april 2025 17:39

Je kan in Eclipse zeker wel een deel van je wijzigingen committen. Gewoon in de Staging View de gewijzigde bestanden die je wilt committen uitzoeken en klaar, niks magisch aan. Je teamleider heeft al heel lang niet meer met git in Eclipse gewerkt, blijkbaar.

IntelliJ is wat meer "in" tegenwoordig, maar ik vind nog steeds dat er eigenlijk niks mis is met Eclipse. Het doet wat het moet doen. Wij werken ook met Eclipse, omdat niemand zin heeft al die bedrijfs- en teaminterne plugins nog een keer voor IntelliJ te schrijven.

Nark0tiX @nzall • 8 april 2025 08:55

Wat een onzin allemaal. dit kan allemaal met git. En veel beter ook. Beperking ligt dus bij de devs niet bij git. Allemaal excuses zelf aangepraat.

ZinloosGeweldig @nzall • 8 april 2025 13:28

Met Git moet je eerst de bestanden die je wil commiten "stagen" en vervolgens de gestagede bestanden commiten. Dat hoeven niet alle gewijzigde bestanden te zijn. En eGit heeft dat gewoon geimplementeerd.
https://wiki.eclipse.org/EGit/User_Guide/#Committing

!GN!T!ON @nzall • 7 april 2025 17:36

Je kan die paar bestanden toch gewoon in je .gitignore zetten?

Lord Anubis @nzall • 8 april 2025 19:56

Ik heb een script gemaakt dat checkt of er bepaalde woorden in staan en dan een popup laat zien of het wel of niet in de .gitignore lijst moet. Dat herinnert iedereen eraan om de gevoelige data apart te zetten.

BCC @Ryen • 7 april 2025 15:34

DB Corruptie... langzaam... lastige merges...

Navi @Wraldpyk • 7 april 2025 15:08

En toch was er weinig mis met SVN, de argumenten die mensen gebruiken voor een overstap zijn vaak helemaal niet van toepassing, zaken als oh zo makkelijk voor een feature een branch maken en dan terugmergen, tja, dat kan SVN ook gewoon.

En sommige dingen vallen juist weg, zo kun je in Git een persoon geen toegang geven tot een deel van je repository, wat bij SVN wel kan.

Ook kan Git een stuk complexer zijn met het commiten, pushen, rebasen, history rewriten, geen oplopende commit-id's, etc.

Je hebt inderdaad gelijk dat Git nu wel gewoon de standaard is.

Heb jarenlang SVN gebruikt i.c.m TortoiseSVN en nu al heel wat jaren Git met SourceTree. (repo in Gitlab)

[Reactie gewijzigd door Navi op 7 april 2025 15:11]

Xander2 @Navi • 7 april 2025 16:52

Er was heel wat mis met SVN, behalve als je het misschien in je 1tje gebruikt.

Bij een team heb je al snel merge conflicts en branches zijn heel duur; doe feature branches van een groot project en je kan een uur of meer wachten.

Dat is fijn als net iemand nog wat incheckt, de server vastloopt en je met een invalide main source tree zit. Als er ook maar iets in de server niet meewerkt hebben alle devs daar meteen last van.

Daarnaast zijn PRs ideaal en kun je een deel van je project eenvoudig in een submodule onderbrengen.

SVN was een verademing tov CVS maar *Kuch* zekere cad pdm met svn onderwater geeft al binnen een jaar dezelfde problematiek.

Nog los van alle hookscripts die je aan svn toevoegde om het vriendelijk te maken. Plus met git is het doodsimpel meerdere repository urls te koppelen.

Nee, sinds git nooit meer het gevoel gehad dat ik bij een commit/push problemen kan verwachten...

Navi @Xander2 • 7 april 2025 17:53

Ik vind het hele merge conflicten argument overtrokken, in Git kom ik net zo vaak tegen dat er niet zomaar gemerged kan worden zonder eerst handmatig het conflict te resolven.

Een uur wachten heb ik echt nog nooit gehad, ook niet met bv commits van 15.000 files. Het duurt iets langer dan bij Git inderdaad bij dat soort grote zaken, maar meer dan een paar minuten heb ik niet gezien.

Xander2 @Navi • 7 april 2025 18:51

Ik vind het hele merge conflicten argument overtrokken..

Versie management draait om niets anders dan mergen van patches (incl. bijbehorende conflicten) en git heeft gegarandeerd minder handmatige conflicten omdat het file/revisie-based is itt. SVN. Daarvoor zijn pull-requests. Als je een merge conflict hebt moet je eerst je branch updaten en vervolgens de pull-request.

Teveel conflicten betekent dat features op dezelfde source+locatie worden uitgevoerd, ergo, een monolithisch probleem, ontwerpprobleem, planningsprobleem, you name it.

SVN/CVS is volledig gestoeld op een heilige main branch en centrale opslag maar maakt het vrijwel onmogelijk meerdere branches up-to-date te houden. Een SVN branch is een kopie van alle files ten tijde van creatie, geen referentie.

De manier van werken lijkt in eerste instantie misschien omslachtiger maar een commit is simpelweg geen push. Die onvermijdelijke race bij SVN/CVS tussen devs om te committen (want daar komt het uiteindelijk altijd op neer) is het alleen al waard. Wie het eerst commit en de mainbranch niet om zeep helpt kan het eerst naar huis.

[Reactie gewijzigd door Xander2 op 7 april 2025 18:53]

Navi @Xander2 • 7 april 2025 19:06

Teveel conflicten betekent dat features op dezelfde source+locatie worden uitgevoerd, ergo, een monolithisch probleem, ontwerpprobleem, planningsprobleem, you name it.

Precies wat ik bedoel, een overstap naar Git lost dat dus niet op, en dat is wel vaak het argument dat ik hoor.

Als je in dezelfde files op dezelfde regels zit te rommelen kan ook Git er niets van maken, m.a.w een conflict.

rbr320 @Navi • 7 april 2025 20:56

Git lost dat probleem wel degelijk beter op dan SVN. Laten we er gewoon eens een pen-en-papier-vergelijking op loslaten:

Met z'n tweeën op hetzelfde moment dezelfde regel op hetzelfde blaadje beschrijven gaat gewoon nooit, dat kan iedere kleuter die daar wel eens ruzie over heeft met broertje of zusje van meepraten. Bij SVN loop je zelfs risico op conflicten als je tegelijkertijd met iemand anders op dezelfde bladzijde bezig bent, ook al beschrijf je totaal andere regels. Of wordt werken op dezelfde bladzijde je gewoon niet toegestaan vanwege een lock. Bij Git krijg je tenminste nog je eigen kopie van het schriftje en zolang jij op je eigen regels blijft zal er geen conflict zijn, zelfs als je in dezelfde file werkt. Het wordt pas een probleem als de beschreven regels elkaar overlappen omdat je veel toevoegt, maar zelfs dat hoeft niet altijd een probleem te zijn.

Xander2 @Navi • 7 april 2025 19:13

Precies wat ik bedoel, een overstap naar Git lost dat dus niet op, en dat is wel vaak het argument dat ik hoor.

Als je in dezelfde files op dezelfde regels zit te rommelen kan ook Git er niets van maken, m.a.w een conflict.

Nee, maar dat is toch een kwestie van eigenwijs zijn en beroerd samenwerken/ontwerp?

Hoe wil je ooit vooruitkomen en meerdere features tegelijkertijd ontwikkelen als je met z'n allen gelijktijdig in telnet.c zit te akkeren?

mekkieboek

@Xander2 • 7 april 2025 18:26

SVN was een verademing tov CVS

En op zijn beurt was CVS weer een verademing t.o.v. RCS (en zelfs t.o.v. enkele commerciele producten).
En op zijn beurt was RCS weer een verademing t.o.v. SCCS.
Toch mooi de ontwikkeling van versiebeheertooling, voortschrijdend inzicht.

bwerg @Navi • 7 april 2025 15:31

Nou is mijn ervaring met SVN beperkt (lees: alleen gebruikt voor een projectje van anderen die toevallig nog SVN gebruikten), maar ik kwam er al snel achter dat offline in de trein aan een SVN werken heel andere koek was dan git. Bij git doe je voor het in de trein stappen een "git fetch" en je merkt verder geen verschil. Bij SVN hield mijn poging tot een productieve treinrit vrij snel op bij het eerste commando waarbij SVN lokaal niet genoeg informatie had.

Oon

@Navi • 7 april 2025 15:50

history rewriten

Tja, dan zijn we denk ik al heel snel klaar met een discussie over welke beter is, want als je de history moet rewriten heb je óf geen echte ervaring met git óf doe je iets héél erg fout

TimVdE @Oon • 7 april 2025 16:11

Dat is zo op je main branch, maar ik herschrijf mijn history meerdere keren voordat deze gemerged wordt. Het doel is om mooie, atomaire commits te krijgen. Meer zelfs, de commit history is bij ons deel van de review, en we geven geregeld comments als "Kun je dit afsplitsen in een aparte commit?" of "Kun je dat beter uitleggen in je commit message?".

Ik zou zelfs zo ver durven gaan om te zeggen dat als je _nog nooit_ history hebt herschreven, dat je veel mist in je gebruik van git.

rbr320 @TimVdE • 7 april 2025 21:17

Ik snap wat je zegt en je hebt niet per se ongelijk, maar ik ben het toch wel eens met het punt van @Oon. Dat het herschrijven van de geschiedenis kán in Git wil niet zeggen dat je het te pas en te onpas moet doen. De twee voorbeelden die je noemt zijn scenario's die je eigenlijk wilt voorkomen en dat doe je door samen met je collega's goede regels en richtlijnen op te stellen voor het gebruik van versiebeheer (of dat nu Git is of iets anders) en daar gedisciplineerd mee om te gaan. Binnen de organisatie waarin jij werkt zal er in die richtlijnen komen te staan dat je kleine commits moet maken (commit early, commit often) en uitgebreide, verklarende commit boodschappen dient te schrijven. Overigens ben ik van mening dat een commit boodschap geen proza moet worden, als het toelichting behoeft kan je dat doen in de review notities of als commentaar bij het merge request.

Tel daarbij de problemen op die je je op de hals haalt als je met de geschiedenis gaat rommelen in een gedeelde branch, wat in theorie iedere branch is die naar de centrale server is gepusht, en het wordt al vrij snel duidelijk waarom het helemaal geen goed idee is. Persoonlijk doe ik "rebase" en "commit --amend" dan ook alleen op commits die ik nog niet heb gepusht, of als ik 100% zeker weet dat ik de enige ben die met de branch werkt. Daarbuiten is het me het risico op gedoe gewoon niet waard en doe ik gewoon een lineaire commit met een correctie of een "revert" indien van toepassing.

TimVdE @rbr320 • 8 april 2025 08:21

Overigens ben ik van mening dat een commit boodschap geen proza moet worden, als het toelichting behoeft kan je dat doen in de review notities of als commentaar bij het merge request.

Daar ben ik het niet mee eens, om de simpele reden dat ik de merge request-tool (en bij uitbreiding het ticketingsysteem) als vergankelijk zie. In het verleden heb ik organisaties zien verhuizen van Github naar Gitlab of van Trac naar Jira, waarbij die hele geschiedenis verdween. Hetgene dat _wel_ is gebleven (zelfs in de move van SVN naar git)? De version control-history.

Tel daarbij de problemen op die je je op de hals haalt als je met de geschiedenis gaat rommelen in een gedeelde branch, wat in theorie iedere branch is die naar de centrale server is gepusht, en het wordt al vrij snel duidelijk waarom het helemaal geen goed idee is.

In praktijk zijn dit niet echt gedeelde branches. We reviewen elkaars code, kunnen die soms ook lokaal eens uitvoeren, maar laten het aan de originele auteur om changes te maken. Maar zelfs als het _wel_ gedeelde branches zijn (bijvoorbeeld wanneer je aan pair programming doet), lost goede communicatie dit probleem ook vrijwel geheel op. En natuurlijk `git push --force-with-lease` als extra safety.

Daarbuiten is het me het risico op gedoe gewoon niet waard en doe ik gewoon een lineaire commit met een correctie of een "revert" indien van toepassing.

En dan mis je dus volgens mij net datgene waar git voor dient: een manier om snel en eenvoudig op te zoeken waarom een bepaalde change is gebeurd. En na al jarenlang te werken met `git commit --fixup` en `git rebase -i --autosquash` om code reviews te doen en het artefact van die code reviews weg te rebasen, kan ik met de hand op het hart zeggen dat dit helemaal geen gedoe is. De enige mensen die ik ooit heb weten zeggen dat het gedoe is, zijn mensen die het nooit echt geprobeerd hebben (lang genoeg om vlot genoeg te worden met de git-commando's).

[Reactie gewijzigd door TimVdE op 8 april 2025 08:21]

jerisson @Oon • 8 april 2025 12:19

Perongeluk een file die groter is dan 100MB committen en je hebt het al vlaggen als je naar github wilt pushen. Dan moet je beginnen met rewriten als je nog ooit iets naar github wilt pushen.

Oon

@jerisson • 8 april 2025 12:56

Ben benieuwd wat voor bestanden van 100MB jij hebt die je niet in je .gitignore gooit. Bij mij zijn de enige grote bestanden build artifacts want ik houd netjes zoals het hoort alle dependencies en binaries buiten git

jerisson @Oon • 8 april 2025 13:31

Git is uiteraard voor meer bedoeld dan enkel voor source-code. Bij ons wordt het ook veel gebruikt voor lesmateriaal, inclusief powerpoint presentaties, afbeeldingen of videos (hetgeen alle binary bestanden zijn). Afbeeldingen en videos zijn overigens ook niet vreemd bij projecten die media vereisen, denk aan games bijvoorbeeld. Door de indeling die veel game-engines gebruiken ga je de media echt niet elders opslaan.

Het probleem treedt bijvoorbeeld op als je enkele videos of zelfs gewoon afbeeldingen aan een ppt toevoegt. Vanaf dat moment dien je de ppt eigenlijk toe te voegen aan Git LFS. Als je echter niet in de gaten hebt dat je filesize tot over 100MB toegenomen is, heb je prijs.

rbr320 @jerisson • 8 april 2025 15:42

Vanaf dat moment dien je de ppt eigenlijk toe te voegen aan Git LFS.

Ik gebruik Git LFS voor al alle binaire bestanden in een repository, ongeacht hun grootte. Ik raad je dus aan om PPT en andere binaire bestandstypen al meteen aan LFS toe te voegen.

ZinloosGeweldig @jerisson • 8 april 2025 13:33

Als je een bestand met broncode van 100MB hebt lijkt het me sowieso tijd om te beginnen met rewriten. Ongeacht of je iets naar github wil pushen of niet.

jerisson @ZinloosGeweldig • 8 april 2025 13:38

Git is in het beginsel een versiecontrolesysteem en geen codebeheersysteem. De toepassingen zijn breder dan enkel sourcecode, al is dat wel hetgene waar het het meeste voor gebruikt wordt.

ZinloosGeweldig @jerisson • 8 april 2025 14:02

De officiele website van git heet toch echt git-scm.com waar SCM staat voor Source Control Management.

SCM systemen zijn natuurlijk in principe (vrijwel) altijd version control systemen. Maar git is toch echt ontwikkeld met het doel: broncode beheren.

jerisson @ZinloosGeweldig • 8 april 2025 15:52

I stand corrected.

Blijft natuurlijk wel een feit dat bron-code tegenwoordig meer is dan enkel tekstfiles met instructies. Ook de data wordt vaak toegevoegd omdat een andere aanpak niet praktisch is. Denk bijvoorbeeld aan het schrijven van een document o.b.v. LaTeX: je schrijft code (LaTeX), maar verwijst naar allerlei mediabestanden (veelal afbeeldingen). De resulterende pdf is opzichzelf staand (itt een executable of Python-script) en wordt daarom ook vaak mee gecommit.

Bij een Unity gebaseerde game is het in mijn ervaring bijna onmogelijk om de assets (modellen, textures, scenes) niet mee in de repo te plaatsen, tenzij je net een hoop issues wilt met ontbrekende/defecte referenties. Afhankelijk van de gekozen formaten en editor kan het zijn dat een scéne in een enkele file gedefinieerd is (bvb scene gedesigned in Blender, geexporteerd als Collada/DAE).

Wat ik wil zeggen is: zodra je met media begint te werken in je projecten loop je al heel snel het risico om die limiet te bereiken. De limiet is overigens geen van Git zelf, maar van Github. Github voorziet wel een Large File Storage, die mits installatie van een uitbreiding, samenwerkt met git (git LFS). Maar je moet manueel een file aan lfs toevoegen. Vergeet je dit, dan ben je alsnog aan het herschrijven.

aldieaccounts @Navi • 8 april 2025 11:48

Er was heel wat mis met SVN. Het was zo traag als stroop en een SVN checkout (met dus alleen de laatste revisie van je software en niet de hele history) was bij onze codebase 1.5x *groter* dan de git equivalent met ~8 jaar history.

Doordat veel dingen heen en weer naar de server moeten werd eea nog trager.

Ik heb jarenlang gewerkt met SVN als een centraal repo(ook omdat onze geautomatiseerde builds daar op gemaakt warenb e.d.) , en dan git-svn als 'svn'-client. Dat was al immens veel prettiger in gebruik omdat je bijna alles lokaal kan doen.

En ja, git is wat complexer, maar ook *veel* flexibeler.

Goderic @Wraldpyk • 7 april 2025 20:24

Het kan zeker beter, Git heeft een nogal inconsistente UI en is soms gewoon ingewikkelder dan het zou kunnen. Andere dingen zijn gewoon halfbakken geïmplementeerd en niemand die aan git werkt heeft zin om het te verbeteren (submodules).

Jujutsu vind ik een zeer interessante ontwikkeling en het is compatibel met git!

Wraldpyk @Goderic • 7 april 2025 21:21

Je bedoeld de CLI als inconsistente UI?

Goderic @Wraldpyk • 7 april 2025 23:10

Ja, om maar enkele voorbeelden te geven:

Een branch verwijder je met git branch -d. Een file verwijder je met git rm, een stash met git stash drop.

En dan heb je de soep aan benamingen die de index/staging area/cache (ben ik misschien nog een synoniem vergeten?) is. Je hebt git add dat hetzelfde is als git stage, maar git diff --staged is dan weer hetzelfde als git diff --cached.

Remote branches moet je soms als remote/branch meegegeven en soms met een spatie er tussen.

De vele betekenissen van checkout hebben ze proberen op te lossen door de switch/restore opties toe te voegen, maar checkout bestaat nog dus het kan nog verwarrender over komen.

--ours en --theirs zijn omgewisseld als je rebased t.o.v merged

paltenburg @Goderic • 8 april 2025 10:46

Git heeft een UI?

Goderic @paltenburg • 8 april 2025 10:57

Ja, UI staat voor user interface, hoe je met het programma interageert. In het geval van git is dat het git commando.

paltenburg @Goderic • 8 april 2025 11:14

Ahja

(En: Eindelijk iemand die 'interactie' goed vervormd! Volgens mij ben je echt de eerste nadat ik 15, misschien 20, jaar geleden heb geleerd dat het "interageert" is en niet "interacteert". Ik heb het al die jaren iedereen fout zien/horen doen tot het punt dat ik me afvroeg waarom die kennis eigenlijk in mijn hoofd zit...

)

ZinloosGeweldig @paltenburg • 8 april 2025 13:35

Volgens mij ben je echt de eerste nadat ik 15, misschien 20, jaar geleden heb geleerd dat het "interageert" is en niet "interacteert".

Maar dit klopt niet. In elk geval: Dat interageert correct is klopt inderdaad. Dat interacteert dat niet is klopt niet. Beiden zijn correct.

Tenzij je anti-anglicisme bent maar dan moet je ook eigenlijk wisselwerking zeggen en niet interactie

[Reactie gewijzigd door ZinloosGeweldig op 8 april 2025 13:37]

HansvDr @Wraldpyk • 7 april 2025 15:05

Ik heb zoveel .net projecten in TFS staan dat ik dat nog gewoon gebruik.

darkfader @Wraldpyk • 7 april 2025 15:09

Omzetten van svn naar git (met behoud van historie) was wel een leuke (zelf toegekende) opdracht. Volgens mij ook nog een keer Team Foundation Version Control gebruikt ooit in het verleden ergens.
We gebruiken hier zelf al Gitlab een lange tijd en dat bevalt best goed.

DigitalExorcist @Wraldpyk • 7 april 2025 20:35

Versiebeheer? Gewoon Sharepoint toch.

Martinspire 7 april 2025 22:40

Op zich een prima tool om code te beheren. Alleen vind ik hem voor puur documentenbeheer nog steeds niet geweldig. Helaas is daar Sharepoint nog steeds de marktleider volgens mij (of anderzijds teams wat eigenlijk niet meer dan een schil is over sharepoint heen), maar ik vind ook die niet echt gebruiksvriendelijk. Met Git heb je vooral voor de leek dat het te complex wordt om allerlei problemen op te lossen. Die wil gewoon een bestand opslaan welke dan meteen wordt bijgewerkt en een kopietje wordt opgeslagen voor de huidige versie zodat je ook nog terug kunt. Als je dan dingen moet uitleggen van branches, merge conflicts e.d. dan wordt dat al vrij snel te complex. Zeker als het bestanden betreft die niet echt makkelijk te vergelijken zijn in de diverse git tools voor conflicten. Ik vind Git nog steeds zo'n web 1.0 oplossing die eigenlijk al wel vervangen had mogen worden, maar er is niemand die de stap durft te nemen want het is inmiddels al zo ingebakken en alle sysadmins zijn er helemaal wild van, maar die hebben weer geen weet van hoe de leek met dit soort systemen om wil gaan.

Ook voor Git zijn er niet heel veel goede GUI clients meer over. Het is allemaal de betaalmuur op gegaan en daarbij zijn ze zichzelf allemaal de markt uit aan het prijzen. 30 euro per maand voor een git tooltje, daar zijn er maar weinig van die dat ervoor over hebben en voor de makers is het nou ook weer niet zo'n heftige tool om te moeten onderhouden of ontwikkelen. Maar goed, dat merk ik ook met email clients en calendar apps. Ofwel het is kneiter duur, ofwel het is allemaal nog steeds gepruts.

Bezulba @Martinspire • 8 april 2025 08:24

Wij zijn ook aan het kijken of Git een mogelijkheid is voor ons, maar zoals jij zegt, voor een leek is het echt heel erg obscuur. Het probleem, naar mijn idee, is dat je niet gewoon klein kan beginnen. Dus niet gewoon een nieuwe versie van een bestand "uploaden" en dat is dan de nieuwste versie etc, maar je moet gelijk aan de slag met branches en merging en commits en weet ik veel wat allemaal. En dat allemaal in commandline onzin. Daar was ik 30 jaar geleden al klaar mee, dat hoef ik niet terug.

Een beetje hetzelfde als Docker. Dat is in essentie geweldig. Alles in 1 container, platform onafhankelijk en dus prachtig om mee te testen. Maar zelfs met de GUI moet ik commandline dingen doen om uberhaupt een docker file te mounten en aan de gang te slingeren. Het voelt heel erg alsof de ontwikkelaars het wel tof vinden dat het zo complex mogelijk is want dan is het alleen voor de echte IT'ers of iets in die richting.

MsG @Bezulba • 9 april 2025 10:18

Er zijn legio Gui tools voor git beheer, en in een beetje ide zit dat er ook wel in. Gebruik soms zelf de GitHub Desktop tool ernaast, die vond ik wel overzichtelijk.

Martinspire @Bezulba • 8 april 2025 09:47

Mja en vergeet ook niet de cursussen die ze dan kunnen aansmeren...

reinouts @Martinspire • 9 april 2025 12:07

GitKraken Pro kost €4 per maand voor de eerste seat en is het geld meer dan waard.

Martinspire @reinouts • 9 april 2025 12:25

Normaal is het 8 euro en dan kom je toch al snel op 96 per jaar. En zelfs zonder die prijs is het met 48 ook nog wel prijzig imo. Per jaar dan. Voor een tooltje waar maar weinig ontwikkeling in zit (tenzij je hun eigen platform gaat gebruiken, maar daar zie ik als iemand die vast zit aan wat zijn opdrachtgever doet, weinig brood in).

reinouts @Martinspire • 9 april 2025 13:34

Ik weet niet wat je bedoelt met 'hun eigen platform' maar er komen vrij regelmatig nieuwe releases van GitKraken uit. En zelfs als dat niet zo was, vind ik het z'n geld meer dan waard.

GrandDynamo 7 april 2025 15:01

Git is een geweldig versiebeheer systeem. Wij zijn er recentelijk naar gemigreerd en het werkt veel fijner dan het oude versiebeheer systeem! Bedankt Linus voor deze tool en de maintainers voor het onderhouden er van.

[Reactie gewijzigd door GrandDynamo op 7 april 2025 15:02]

david-v

@GrandDynamo • 7 april 2025 15:09

Ik heb met veel soorten versiebeheer tools gewerkt, waarvan de meest waardeloze was: de bestanden staan op het netwerk, daar kan je ze aanpassen (ofwel geen versiebeheer)

. Maar een in-house versiebeheer zelf ontwikkelen? dat heb ik niet eerder meegemaakt. Was dat een bewuste keuze? en waarom hebben jullie daar voor gekozen? Beheerden jullie de versiebeheer code ook in de in-house versie beheer? de vraag is puur uit interesse, geen kritiek of iets anders, ben gewoon geïnteresseerd

Ryen @david-v • 7 april 2025 15:17

Waar lees jij dat @GrandDynamo zelf een zelf-ontwikkelde versiebeheeroplossing gebruikte? Hij zegt alleen dat ze recentelijk gemigreerd zijn van een andere (oude) oplossing.

Maar verder: Ik heb zelf wel eens een versiebeheeroplossing gebouwd, maar dat was wel in 1988

GrandDynamo @Ryen • 7 april 2025 15:34

Wij gebruikten idd een zelf ontwikkelde versiebeheer systeem. Ik had dat na een edit weggelaten, excuus!

GrandDynamo @david-v • 7 april 2025 15:39

Wij hadden idd een eigen versiebeheer ontwikkeld en in onderhoud. Git bestond nog niet toen deze codebase geschreven werd

zo lang geleden alweer! Verdere details weet ik helaas niet : )

moonlander 7 april 2025 18:31

Git moet alleen nog een AI functie krijgen voor het genereren van een goede commit message. Want dat vind ik toch vaak het minste. Op moment van committen vaak geen zin om een fatsoenlijk bericht te typen, en later spijt dat je niet een fatsoenlijke commit -m hebt geschreven.

JW te R @moonlander • 7 april 2025 19:28

Dan moet je eens naar Git clients kijken.
Gitkraken kan dat sinds kort.

Martinspire @JW te R • 7 april 2025 22:34

Ik vind het niet erg om voor tooltjes te betalen, maar gitkraken vind ik wel erg duur. Dan houd ik nog liever even vast aan Fork.dev

JW te R @Martinspire • 8 april 2025 08:52

Tsja. Het is verreweg de beste Git cliënt die ik tot nu toe gezien heb.

BL3ND3D

@moonlander • 7 april 2025 22:20

Dit kan je overigens zelf vrij 'makkelijk' implementeren met een LLM command line tool als https://github.com/simonw/llm. En dan een alias maken die informatie over je changes (git diff bijvoorbeeld) in een LLM stopt. Met het 'template' systeem kan je systeem instructies voorprogrammeren die er dan een mooie commit message van maakt. Nadeel is wel dat je dan een paar seconden moet wachten eer het verwerkt is. Als alternatief zou je met een tool als
https://facebook.github.io/watchman/ dit riedeltje op de achtergrond kunnen uitvoeren wanneer er een bestand in je git-tracked folder verandert. Dan hoef je ten tijde van het committen niet te wachten.

Malarky @moonlander • 8 april 2025 09:20

Windsurf kan dat en met de meest gangbare AI agents naar keuze.

moonlander @Malarky • 8 april 2025 09:40

Ah thanks, ik gebruikte Codium altijd al, is nu Windsurf geworden zie ik. En ik zie inderdaad de optie om een commit message te genereren.

Anonymoussaurus 7 april 2025 14:57

Die Discord-invite klopt niet, dat hoort het volgende te zijn: https://discord.com/invite/UcjvsNQR.

On-topic: git is echt fantastisch. Versioning is erg handig, daarnaast het hele automatiseren van A tot Z is ook erg fijn, ook voor auto-deployments.

[Reactie gewijzigd door Anonymoussaurus op 7 april 2025 14:58]

jb044 7 april 2025 14:59

Briljante tool! Zit echt heel goed in elkaar.

AW_Bos

7 april 2025 15:12

Git werkt gewoon fantastisch. Voorheen gebruikte ik SVN, en moest ik niks van git weten vanwege de 'complexiteit'. Maar complexiteit heeft natuurlijk een reden, en omdat het makkelijk te gebruiken is in een workflow ben ik enkele jaren geleden ook hier naar overgestapt. Mijn eigen CMS en wat andere projecten heb ik in Github (openbaar) of in een eigen gehoste Gitea (eigen source) staan. Gezien ik laatste tijd op meerdere plaatsen zit, werkt het ideaal met een pull.

Cambionn

7 april 2025 15:30

Erg blij met git. Zelfs nu ik niet meer zelf develop gebruik ik het nog regelmatig voor dingen waar wel versiebeheer op moet. Documentatie die in markdown staat bijv. Heerlijke tool, maar wel via de terminal. GUI's is altijd gedoe, zeker als mensen niet allemaal dezelfde GUI gebruiken. Maarja, dat kun je git niet echt aanrekenen. Net zoals je het git niet kan aanrekenen dat sommige mensen nog steeds niet snappen dat git en GitHub niet hetzelfde is.

SPee 7 april 2025 15:37

Twintig jaar geleden?!

Wow, naar mijn idee is het echt pas een jaar of tien dat dit in gebruik is. Ik begon het toen te gebruiken ipv SVN. En naar mijn idee was het nog vrij jong, hooguit een paar jaar.

bendeleider 7 april 2025 15:49

Zo'n 10 jaar geleden ook git gaan gebruiken. Daarvoor gewerkt met CVS. Als je daarmee een branch wou maken, kon je gerust een kop koffie gaan halen.

Garyu @bendeleider • 7 april 2025 16:05

Wij werken (deels) nog steeds met CVS. Het kan echt. Het merendeel is echter al jaren geleden naar SVN en later naar GIT overgestapt. Maar CVS is nog altijd niet dood in bepaalde omgevingen kost de overstap meer dan er maar gewoon bij te blijven.

SPee @Garyu • 7 april 2025 21:54

Wow. Andere organisaties hebben ondertussen hun applicaties al meerdere keren herschreven.

Op dit item kan niet meer gereageerd worden.

Versiebeheersysteem Git bestaat twintig jaar

Lees meer

Reacties (82)

Sorteer op:

Weergave: