Je herkent het vast wel: Je zit diep in de code: Nieuwe features aan het schrijven, aan het refactoren, tests aan het debuggen en voordat je het doorhebt, heb je al 10 files aangeraakt! Dan nu voor de laatste stap een korte maar duidelijke git commit message schrijven.
...
Maat, geen idee wat ik daar neer ga zetten. En voordat ik het weet zien mijn commit history er zo uit.
En nog meer geweldige comics via xkcd.
Dit overkomt mij vaker dan ik zou willen toegeven: niet informatief zijn in een git commit message. Het liefst zou ik natuurlijk gewoon mijn hele codebase en de git diff in een LLM gooien en het op die manier automatiseren. Helaas zijn daar wat bezwaren tegen. Ten eerste brengt een codebase delen met een cloud LLM veiligheidsrisico’s met zich mee. Jij weet net zo goed als ik dat klanten meestal niet staan te springen om nieuwe AI-modellen te trainen met hun eigen code. Ten tweede komen de tokens niet gratis uit de (digitale) lucht vallen en als laatste blijkt dat ons groeiende watertekort niet opgelost wordt met AI-datacenters.
Zijn deze bezwaren enigszins herkenbaar? Boy, oh boy. Heb ik dan misschien een leuke oplossing voor jou!!1!1!
De afgelopen tijd heb ik gesleuteld aan een oplossing die lokaal een LLM draait om mijn git commit messages creatief, consistent en informatief te houden.
Ten eerste heb je een laptop nodig die tijdelijk wat RAM over heeft om een model in te laden, check? Dan hebben we iets nodig dat de LLM lokaal kan draaien. Ik kwam uit op Ollama vanwege diens gebruiksvriendelijkheid. Ollama is een open-source framework dat zogenaamde modelfiles kan inladen (vergelijkbaar met docker images) die een LLM bevatten, waarna je met deze tool verschillende modellen kan runnen en beheren. Er zijn ook andere tools die je in staat stellen om lokaal een LLM te draaien, maar die tools worden minder ondersteund door andere applicaties zoals IntelliJ en VSCode. Als laatste hebben we dan een model nodig dat lokaal kan draaien, vaak is de hoeveelheid RAM de bottleneck voor het model dat je uiteindelijk kiest¹. Ik heb gekozen voor gemma4:e2b, een model dat gemaakt is door Google DeepMind en naar verluidt optimized is voor mobile devices. De grootte van het model is 7.2GB, dat betekent dat je minimaal 7.2GB aan RAM kwijt zolang je het model wil gebruiken. Je kan ervoor kiezen om het model te downloaden via de command-line (ollama pull gemma4:e2b), of direct via de Ollama UI.
Goede vraag! Eerst maar eens even kijken of het model mijn vragen kan beantwoorden.
Lekker modelletje downloaden, duurt ff.
¹ Kijk ook vooral even rond in de Ollama model library. Je vindt hier allemaal modellen voor allerlei doeleinden die je kan proberen en testen.
Normaal is mijn commit message wel wat kleiner hoor.
Het model werkt, maar hoe gaan we ervoor zorgen dat er integratie is met de IDE? In mijn setup gebruik ik deze AI commit plugin, maar er zijn meerdere plugins die een integratie met Ollama ondersteunen.
Stel de plugin in.
Dan komt nu het leukste onderdeel: een prompt schrijven die jouw persoonlijkheid reflecteert en nog enigszins nuttig is. Er zijn een aantal standaard prompts, maar ik heb ervoor gekozen om mijn eigen te schrijven:
Write a short git commit message consisting of a single line with a maximum of 150 characters. Format the message in the following way by replacing the variable with the following instructions:
- $MESSAGE: the git commit message in {language}
- $TYPE: fix, test, implementation, update, revert, useless
- $EMOJI: Any emoji that you think fits the change and the mental state of the developer, this one always needs to be added. Examples are: 🐝🫡🚂🚨🙈⏪🌞🐕🥶🍝🥘🧿👆🥰🤩😶🌫️🤐🦀🦑🐿️💦
Message should be one line with maximum 150 characters and formatted like this:
"($TYPE): $MESSAGE $EMOJI$EMOJI"
Use the diff: {diff}
Of, als je wat plezier wil toevoegen in je commit history:
Write a short git commit message consisting of a single line with a maximum of 150 characters. Summarize the changes that were made using star wars character Yoda’s way of speaking, which is to change the sentence structure the object to the front and the verb to the end. It also means to add thoughtful 'hmms' wherever you find appropriate. Write the prompt in the language {language}.
Strictly adhere to the style of the following examples:
👽Yoda👽 says: Updated the test, I did hmm.
👽Yoda👽 says: Hmmm to comply to security practices it has been refactored.
👽Yoda👽 says: To include the new utility functio hmm updated the Utils.kt file.
👽Yoda👽 says: Hmmm to fix everything that was broken, updated the data model to comply.
ALWAYS start the message with 👽Yoda👽 says:
ALWAYS include a hmmm in the output message
Use the diff: {diff}
Kies hier je eigen prompt.
Nu dit is ingesteld, maak een change en ga naar je commitscherm.
TADA!
Nog een beetje sleutelen… is vereist.
Selecteer de changes waarvoor je een commit message wil schrijven en klik op generate AI commit message. Afhankelijk van de hoeveelheid changes verschijnt er binnen korte tijd een commit message op het scherm.
Zeker!
Omgevingsvariabelen geven je de mogelijkheid om wat dingen in te stellen. De belangrijkste die ik heb gebruikt zijn OLLAMA_CONTEXT_LENGTH en OLLAMA_KEEP_ALIVE. De eerste (context length) beperkt hoeveel tokens er gebruikt worden voor het genereren van een antwoord. Dit staat op mijn systeem op 32k en dat zorgt ervoor dat de context die naar je lokale model wordt gestuurd, niet te groot wordt. Een lagere context length betekent in principe een snellere reactie van het model. Daarentegen kan een te lage context length ervoor zorgen dat de LLM niet alle benodigde changes heeft die belangrijk zijn om je commit message te formuleren. De tweede (keep alive) is hoe lang een model in memory blijft nadat het is ingeladen. Dit is redelijk snel, op mijn systeem rond de 10/15 seconden, toch kan je de keep alive hoog houden om deze opstarttijd te vermijden bij elke generatie. Maar als je de RAM nodig hebt om bijvoorbeeld je project te compileren of meer dan twee chrome tabs open te hebben, dan kan je ervoor kiezen om het model sneller uit de memory te halen. Commit je maar 1x per uur? dan zou ik de keep alive kort houden (standaard is 5 minuten). Dat betekent dat een model na 5 minuten automatisch uit je geheugen wordt gehaald. Maar commit je veel in een korte tijdspanne, gevolgd door bijvoorbeeld testen, dan kan je ervoor kiezen om deze keep alive te verhogen. Mijn model blijft 30 minuten in memory, dat werkt prima voor mijn use case. Je kan er ook voor kiezen om een waarde zoals -1 mee te geven zodat het model altijd in-memory blijft.
De environment variables zien er zo uit.
Het was heel leuk om hier meer van te leren. Ik hoop dat je met deze uitleg wat geleerd hebt over hoe je automatisch je git commit messages kan schrijven vanuit IntelliJ. Je kan het redelijk snel opzetten en daarnaast is er nog genoeg ruimte om eraan te sleutelen om het model helemaal naar jouw hand te zetten. Bekijk vooral de documentatie op de website zelf of zoek naar een model dat nog beter bij jouw doeleinden past.
Dat gezegd hebbende: Ik merk wel dat het in deze space soms lastig is om een duidelijk antwoord te krijgen vanuit de docs. Zo is er op de website van Ollama veel te vinden, maar bijvoorbeeld niet alle omgevingsvariabelen die gebruikt kunnen worden. Die kan je dan alleen weer vinden als je ‘ollama serve –help’ in je terminal gebruikt.
Het model reageert wat traag, soms meer dan 5 minuten. Dit is misschien nog te verhelpen door aan de parameters te sleutelen of de reasoning uit te zetten. Iets wat ik in een volgende blog zal bespreken. Een ander pluspuntje, doordat ik zoveel heb nagedacht over consistentie en duidelijkheid in mijn commit messages ben ik zelf consistenter geworden in het schrijven van deze messages. Als een AI commit message te lang op zich laat wachten, dan schrijf ik het bericht vaak zelf in dezelfde stijl. Misschien zijn we toch niet zo makkelijk te vervangen door AI. 😉