🇺🇸 – Last update: Monday, January 12th 2026

Keywords: #Git, #commits, #GitHub, #GPG, #CLI

A bit of context

Sometimes I need to get back some commands I used in my terminal so as to work on my Git repositories of GitHub / GitLab projects. But I can have often some doubts about them, so I decided to list here some useful commands as a cheatsheet or a simple reminder to keep and share. I will try to keep it updated. There are nice resources in the bottom of this document!

Applying some common Git configurations

Use also the —global option if you want to apply this configuration everwyhere.

Showing GPG keys to get ID to use for commits

Useful to remember the ID of the GPG key to use to sign commits. More details in this other publication (in french).

Verify GPG signature of commits

Keep in mind the software forges like GitHub and GitLab provide also some verification process for commits.

Verify GPG signature of artifacts

Verify assets or release integrity (GH)

Display contributors of a commit

You can also filter to get other metadata in commits, find here for example some ideas.

Create branch from another and switch

That's not the only command of course, but I like this one.

Get rid of the last N commits

You can use of course other things instead of HEAD~N.

Reword, reorder or squash last N commits with interactive rebease

You can use of course other things instead of HEAD~N. Beware of fixup and squash, not the same uses with the commit messages.

Create a Git patch

Allows to generate a Git patch from a diff to apply or send it later.

Keeping somewhere changes temporary

Useful for drafts or temporary changes you don't want to version.

Find someone to blame (maybe you!)

The aim is to display who modified lines of files.

Clean the repository

Clean the project, get rid of files, but beware, you may loose things!

Work on a fork and submit

The workflow is simple: fork, create local develop branch with your dev stuff, make meaningful commits, then cherry-picks from this branch to a virgin one so as to submit a nice and simple pull request.

Resources

You have also some online resources like git-cheat-sheet.readthedocs.io.

But, maybe most important, you can refer also to this amazing comic of Julia Evans, available online and also buy her book. Her comic bellow is licensed under CC-BY-NC-SA 4.0.

[Code samples rendered with carbon.now.sh]

— Posted on Friday, September 27th 2024 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0. Opinions are my own. To contact me, feel free to choose the most suitable medium for you, or for example Mastodon.

🇫🇷 – mercredi 8 juin 2022

Mots clés : #Git, #commits, #GPG, #signature, #cryptographie

Au jour d'aujourd'hui il est indéniable que le code source a une valeur concrète, tant pour ce qui est de la propriété intellectuelle et du patrimoine logiciel qui en découle que pour les sommes investies pour son écriture. En 2009, un article de silicon.fr est paru et évoquait le fait que la valeur des logiciels open source est estimée à 400 milliards de dollars américains, explosant les quelques 25 milliards de dollars américains pour l'écosystème Linux !

Le fait est qu'il faut être capable de définir, et surtout certifier, qui est l'auteur des commits pour savoir à qui appartient la contribution induite. Lorsque des entreprises travaillent avec des filiales ou des prestataires, ou quand du code source est cédé à une fondation ou un organisme tiers, voire même si les projets open source sont critiques, certifier l'origine du commit est rassurant.

Certes, on pourrait se contenter de regarder l'identité de l'auteur, avec par exemple la bonne vieille commande git log, permettant de ressortir l'historique Git et d'obtenir des détails sur les derniers commits.

Sauf que le champ Author d'un commit est définit par deux éléments : les champs user.name et user.email de la configuration Git (locale ou globale). Or, ces champs peuvent être définis par n'importe qui, avec n'importe quelle valeur, sans vraiment de contrôle naïf et natif sur ça. Ils ne sont donc pas à considérer comme fiables.

On pourrait aussi regarder du côté du Developer Certificate of Origin (DCO), avec notamment l'option -s dans la commande Git de commit. Or le DCO n'est pas dédié à cette question, mais plutôt au fait que l'on confirme avoir les autorisations qui vont bien pour faire ce commit, apporter cette contribution, dans le respect des licences par exemple. C'est intéressant, mais pas adapté.

On peut par contre considérer la signature des commits via... une clé GPG (option -S).

L'idée est simple finalement : on créé une clé GPG, on la dépose dans son compte sur sa forge logicielle (GitHub ou GitLab par exemple), et on définit dans le dépôt en local la clé à utiliser (user.signingkey). Ainsi, on peut plus fortement confirmer que le commit est bien signé par une personne via sa clé GPG avec la même adresse e-mail entre celle du commit et celle de la clé. C'est d'ailleurs très pratique car via sa forge on peut facilement voir que le commit est vérifié (ellipse bleue), avec une clé GPG d'identifiant donné (rectangle vert), et d'ailleurs signé avec le DCO (rectangle rouge). Bon le hic c'est qu'il faut être capable d'avoir une autorité permettant de vérifier les clés, ou alors de placer une confiance aveugle envers la forge logicielle concernée dont peut-être les administrateurs seraient peu scrupuleux et capables d'altérer les clés publiques enregistrées. À creuser en tout cas.

Ce faisant, il est même possible de vérifier a posteriori la signature d'un commit via la commande git show [commit] —show-signature, ou plus appropriée la commande git verify-commit [commit] qui renvoie le strict nécessaire en terme d'informations.

Remarque, ce serait intéressant d'avoir des hooks vérifiant au moment du commit s'il est bien signé. Dans des projets critiques ou sensibles, on saura ainsi s'il n'y a pas un contributeur tiers qui aurait commis des commits sans autorisation. Ce n'est pas suffisant, mais ça aide.

On peut ainsi voir que pour le commit donné, il y a bien eu une signature avec une clé GPG de type EDDSA avec l'identifiant indiqué (dont on retrouve une partie à la fin), et une note indiquant que c'est bien la bonne adresse email qui est utilisée.

Bref, pensez à signer vos commits. C'est rigolo et ça fait classe.

Pour en savoir davantage, je vous conseille cet article assez simple et aussi cette page de la documentation GitHub à propos d'une nouvelle fonctionnalité chez eux : “le mode vigilant”.

— Dernière mise à jour : lundi 3 octobre 2022 Précédemment sur paper.wf —