HowDoWeDoGit¶
- /!\ On ne fait JAMAIS
git push -f
sur la branche main. /!\
Procédure canonique¶
Travailler dans une branche dont le nom suit le convention de nommage wip/XXXXX-mini-description, où XXXXX est le numéro de ticket où le développement est suivi.
git checkout -b wip/XXXXX-mini-description
Une fois les commit faits dans la branche, pousser (git push) permet d'ouvrir une Pull Request sur Gitea.
git push origin wip/XXXXX-mini-description
Il faut de manière systématique cliquer sur « ajouter le préfixe WIP », car tant que l'intégration continue via Jenkins ne s'est pas exécutée, on ne peut pas être sûr que le code est prêt à être relu.
Si la branche ne contient qu'un seul commit, on peut laisser le titre automatique. Sinon, il faut taper un titre plus descriptif que le nom de la branche mis par défaut, qui doit notamment contenir le numéro du ticket entre parenthèses (par exemple, copier coller le titre du ticket redmine).
Une fois la PR créée pour la branche, les tests seront exécutés par Jenkins et un mail vous sera envoyé en cas d'erreur.
Le ticket redmine a été automatiquement passé sur le statut « En cours », et assigné à vous.
Si les tests passent, on peut aller sur la PR et retirer le préfixe WIP. Le ticket redmine passera alors en « Solution proposée », ce qui indique qu'il est bon pour relecture.
Les commits¶
Sur la forme des messages de commit, http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
- Modulo la première ligne il y est écrit "max 50 caractères", ça peut être 80.
- Et pas de majuscule au début. À la place, toujours un préfixe, qui indique la partie du code principale que le commit modifie.
- Si un seul fichier est modifié, trouver le préfixe est très simple : il suffit de faire
git log <nom du fichier>
et de prendre le préfixe majoritairement utilisé par les commits précédents.
- Si un seul fichier est modifié, trouver le préfixe est très simple : il suffit de faire
- Inclure une référence au ticket, façon (#12345) par exemple :
doc: explain how we are supposed to commit (#12345)
- Le message du commit doit être en anglais, au présent.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. -- http://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatchesÀ noter également :
- séparer les patchs de traduction des patchs de code
- pareil, ne pas mêler des modifications de style (genre réindentation ou autre) dans un patch ajoutant une fonctionnalité/corrigeant un bug.
Pre-commit hooks¶
Afin d'imposer un style de code commun, on utilise le logiciel pre-commit.
On trouvera à la racine de chaque dépôt un fichier .pre-commit-config.yaml
, qui spécifie les vérifications à effectuer. Pour qu'elles s'exécutent automatiquement il est nécessaire de taper la commande pre-commit install
(à faire une fois sur chaque dépôt).
Conseils & astuces git¶
Note from 2024 : cette section n'a pas été mise à jour depuis 10 ans et devrait sûrement être retravaillée.
- dans
~/.gitconfig
:[color] branch = auto diff = auto interactive = auto status = auto [pull] rebase = true
- git log
- git show (avec la coloration syntaxique activée plus haut, ça permet de voir les espaces qui trainent, par exemple)
- git add -p
- travail dans une branche, git rebase main avant de merger
- git cherry-pick aussi, peut-être
- travail dans main, git rebase -i origin/main, taper les commits qu'on veut en premier
- git push origin hash:main
- ou second git rebase -i, effacer les commits en trop, noter le hash
- git push; git merge hash
- retrouver l'état d'une branche avant un rebase, un merge, un
git --amend
:git reflog
, une fois retrouvé le bon commit on y retourne de façon non destructive pargit reset <commit>
ou destructive (on perd les différences) pargit reset --hard <commit>
- revenir sur le le dernier commit pour le découper (git reset HEAD^)
- ajouter les modifications en cours au dernier commit (git commit -av --amend)
- réorganiser manuellement les n (ici 5) derniers commits (git rebase -i HEAD~~~~~, ou git rebase -i HEAD~5)
(?) http://blogs.gnome.org/bastian/2015/02/12/a-guide-to-git-in-gnome-for-the-simple-minded/
- pour obtenir 8 lignes de contexte dans les patchs, ajout à
~/.gitconfig
:[diff] context = 8
- Pour merger des fichiers .po sans se faire chier: https://gist.github.com/mezis/1605647
- Certains dépôts présentent des commits annotés (voir git-notes). Ces notes ne sont pas tirées par défaut. Pour ce faire il suffit d'ajouter la référence au remote correspondant, dans le fichier de configuration git du dépôt. Par exemple, dans l'entrée
[remote "origin"]
, y ajouter :fetch = +refs/notes/*:refs/notes/*
Porcelaine git pour notre workflow (avant gitea)¶
Note from 2024 : cette section date d'avant Gitea, mais l'utilitaire mentionné peut toujours servir à ouvrir des tickets depuis son terminal, et créer les branches automatiquement.
J'ai créé ça :
C'est sympatoche:
pip install --user git-redmine
- poser ça dans
~/.config/git/config
:[redmine] url·=·https://dev.entrouvert.org/ key·=·<apikey à récupérer sur redmine sur la page de votre utilisateur>
git redmine project set <redmine-project-slug>
: associe le dépôt git à un projetgit redmine issue new
: ouvre un $EDITOR pour décrire un nouveau ticket, obtient un numéro et crée la branchewip/XXXX-description
pour commencer à bossergit redmine issue take XXXX
: prendre un ticket existant pour bossergit redmine rebase
: fais un pull sur main puis vérifie que la branche courante rebase sur maingit redmine issue submit
: fait unrebase
comme juste avant, puis si ça passe poser les patchs dans le ticket en passant le ticket en Solution Proposée (ça demande si on veut changer le status et s'affecter le ticket)git redmine merge-and-push
: pull un main récent, vérifie qu'un rebase de la branche est possible, puis merge la branche, supprime une éventuelle branche distante si créée pour jenkins, pousse sur origin/main puis demande s'il faut supprimer la branche locale