lisawolderiksen

Using Git Commit Message Templates to Write Better Commit Messages

The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

lisawolderiksen

Adding co-authors to Git commits

How do you share credit for a new or altered piece of code when one person commits the change in a pair programming or mob programming session? And when you have questions about a particular change, how can you see in Git who has been working on that change, besides the committer? You add co-autors to your commits. This gist contains information on how to do that, so that the Git commit message contains a list of co-authors, and all co-autors for a commit are automatically listed in GitHubs web UI.

GitHub has some info on specifying co-authors here. This is good info, pretty straightforward. The gist of it (pun intended) is to include at least one blank line and then a line for each co-author like so Co-authored-by: name <[email protected]> at the very end of your commit message.

GitHub's recipe tells you [how to find the right e-mail address to use](https:

lisawolderiksen

#!/bin/bash

usage() {
    cat << EOF

This script detects TLS secrets which refer to certificates that don't exist (anymore).

This is the case when error "unable to fetch certificate that owns the secret" occurs in cert-manager (cainjector) logs.
The reason is that a certificate has been removed without the secret being deleted.
The solution is to clean up by deleting any secret which belonged to a certificate that no longer exists.

lisawolderiksen

Jasså, en mal for pull request-beskrivelse, sier du? Hvorfor det, da?

Jo, nå skal du høre: Når man oppretter en pull request (PR) i et repo i GitHub, er det lurt å ha en god beskrivelse. Beskrivelsen kan være til god hjelp for den som skal gjøre kodegjennomgangen og vurdere om endringen skal godkjennes eller om det trengs noen justeringer.

Hvis man setter opp en mal for pull request-beskrivelsen i repoet, får man automatisk opp et forslag til tekst i pull requesten. I malen kan man ha informasjon og påminnelser til den som oppretter pull requesten om hva slags informasjon som er lurt å ha med, og man kan også inkludere påminnelser om hva som er lurt å ha gjort før man oppretter pull requesten eller hva prosessen skal være etter at pull requesten er opprettet.

lisawolderiksen

❓ What and why?