-
1. Démarrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 Démon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 Sélection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 Réécrire l’historique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 Déboguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systèmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables d’environnement
- 10.9 Résumé
-
A1. Annexe A: Git dans d’autres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture d’instantané basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise à jour de projets
- A3.6 Inspection et comparaison
- A3.7 Débogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 Systèmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
5.3 Git distribué - Maintenance d’un projet
Maintenance d’un projet
En plus de savoir comment contribuer efficacement à un projet, vous aurez probablement besoin de savoir comment en maintenir un.
Cela peut consister à accepter et appliquer les patchs générés via format-patch
et envoyés par courriel, ou à intégrer des modifications dans des branches distantes de dépôts distants.
Que vous mainteniez le dépôt de référence ou que vous souhaitiez aider en vérifiant et approuvant les patchs, vous devez savoir comment accepter les contributions d’une manière limpide pour vos contributeurs et soutenable à long terme pour vous.
Travail dans des branches thématiques
Quand vous vous apprêtez à intégrer des contributions, une bonne idée consiste à les essayer d’abord dans une branche thématique, une branche temporaire spécifiquement créée pour essayer cette nouveauté.
De cette manière, il est plus facile de rectifier un patch à part et de le laisser s’il ne fonctionne pas jusqu’à ce que vous disposiez de temps pour y travailler.
Si vous créez une simple branche nommée d’après le thème de la modification que vous allez essayer, telle que ruby_client
ou quelque chose d’aussi descriptif, vous pouvez vous en souvenir simplement plus tard.
Le mainteneur du projet Git a l’habitude d’utiliser des espaces de nommage pour ses branches, tels que sc/ruby_client
, où sc
représente les initiales de la personne qui a fourni le travail.
Comme vous devez vous en souvenir, on crée une branche à partir de master
de la manière suivante :
$ git branch sc/ruby_client master
Ou bien, si vous voulez aussi basculer immédiatement dessus, vous pouvez utiliser l’option checkout -b
:
$ git checkout -b sc/ruby_client master
Vous voilà maintenant prêt à ajouter les modifications sur cette branche thématique et à déterminer si c’est prêt à être fusionné dans les branches au long cours.
Application des patchs à partir de courriel
Si vous recevez un patch par courriel et que vous devez l’intégrer dans votre projet, vous devez l’appliquer dans une branche thématique pour l’évaluer.
Il existe deux moyens d’appliquer un patch reçu par courriel : git apply
et git am
.
Application d’un patch avec apply
Si vous avez reçu le patch de quelqu’un qui l’a généré avec la commande git diff
ou diff
Unix, vous pouvez l’appliquer avec la commande git apply
.
Si le patch a été sauvé comme fichier /tmp/patch-ruby-client.patch
, vous pouvez l’appliquer comme ceci :
$ git apply /tmp/patch-ruby-client.patch
Les fichiers dans votre copie de travail sont modifiés.
C’est quasiment identique à la commande patch -p1
qui applique directement les patchs mais en plus paranoïaque et moins tolérant sur les concordances approximatives.
Les ajouts, effacements et renommages de fichiers sont aussi gérés s’ils sont décrits dans le format git diff
, ce que patch
ne supporte pas.
Enfin, git apply
fonctionne en mode « applique tout ou refuse tout » dans lequel toutes les modifications proposées sont appliquées si elles le peuvent, sinon rien n’est modifié, là où patch
peut n’appliquer que partiellement les patchs, laissant le répertoire de travail dans un état intermédiaire.
git apply
est par-dessus tout plus paranoïaque que patch
.
Il ne créera pas une validation à votre place : après l’avoir lancé, vous devrez indexer et valider les modifications manuellement.
Vous pouvez aussi utiliser git apply
pour voir si un patch s’applique proprement avant de réellement l’appliquer — vous pouvez lancer git apply --check
avec le patch :
$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
S’il n’y pas de message, le patch devrait s’appliquer proprement. Cette commande se termine avec un statut non-nul si la vérification échoue et vous pouvez donc l’utiliser dans des scripts.
Application d’un patch avec am
Si le contributeur est un utilisateur de Git qui a été assez gentil d’utiliser la commande format-patch
pour générer ses patchs, votre travail sera facilité car le patch contient alors déjà l’information d’auteur et le message de validation.
Si possible, encouragez vos contributeurs à utiliser format-patch
au lieu de patch
pour générer les patchs qu’ils vous adressent.
Vous ne devriez avoir à n’utiliser git apply
que pour les vrais patchs.
Pour appliquer un patch généré par format-patch
, vous utilisez git am
.
Techniquement, git am
s’attend à lire un fichier au format mbox, qui est un format texte simple permettant de stocker un ou plusieurs courriels dans un unique fichier texte.
Il ressemble à ceci :
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] add limit to log function
Limit log functionality to the first 20
C’est le début de ce que la commande format-patch
affiche, comme vous avez vu dans la section précédente.
C’est aussi un format courriel mbox parfaitement valide.
Si quelqu’un vous a envoyé par courriel un patch correctement formaté en utilisant git send-mail
et que vous le téléchargez en format mbox, vous pouvez pointer git am
sur ce fichier mbox et il commencera à appliquer tous les patchs contenus.
Si vous utilisez un client courriel qui sait sauver plusieurs messages au format mbox, vous pouvez sauver la totalité de la série de patchs dans un fichier et utiliser git am
pour les appliquer tous en une fois.
Néanmoins, si quelqu’un a déposé un fichier de patch généré via format-patch
sur un système de suivi de faits techniques ou quelque chose de similaire, vous pouvez toujours sauvegarder le fichier localement et le passer à git am
pour l’appliquer :
$ git am 0001-limit-log-function.patch
Application : add limit to log function
Vous remarquez qu’il s’est appliqué proprement et a créé une nouvelle validation pour vous.
L’information d’auteur est extraite des en-têtes From
et Date
tandis que le message de validation est repris du champ Subject
et du corps (avant le patch) du message.
Par exemple, si le patch est appliqué depuis le fichier mbox ci-dessus, la validation générée ressemblerait à ceci :
$ git log --pretty=fuller -1 commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 Author: Jessica Smith <jessica@example.com> AuthorDate: Sun Apr 6 10:17:23 2008 -0700 Commit: Scott Chacon <schacon@gmail.com> CommitDate: Thu Apr 9 09:19:06 2009 -0700 add limit to log function Limit log functionality to the first 20
L’information Commit
indique la personne qui a appliqué le patch et la date d’application.
L’information Author
indique la personne qui a créé le patch et la date de création.
Il reste la possibilité que le patch ne s’applique pas proprement.
Peut-être votre branche principale a-t’elle déjà trop divergé de la branche sur laquelle le patch a été construit, ou peut-être que le patch dépend d’un autre patch qui n’a pas encore été appliqué.
Dans ce cas, le processus de git am
échouera et vous demandera ce que vous souhaitez faire :
$ git am 0001-seeing-if-this-helps-the-gem.patch
Application : seeing if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Le patch a échoué à 0001.
Lorsque vous aurez résolu ce problème, lancez "git am --continue".
Si vous préférez sauter ce patch, lancez "git am --skip" à la place.
Pour restaurer la branche d'origine et stopper le patchage, lancez
"git am --abort".
Cette commande introduit des marqueurs de conflit dans tous les fichiers qui ont généré un problème, de la même manière qu’un conflit de fusion ou de rebasage.
Vous pouvez résoudre les problèmes de manière identique — éditez le fichier pour résoudre les conflits, indexez le nouveau fichier, puis lancez git am --resolved
ou git am --continue
pour continuer avec le patch suivant :
$ (correction du fichier)
$ git add ticgit.gemspec
$ git am --continue
Applying: seeing if this helps the gem
Si vous souhaitez que Git essaie de résoudre les conflits avec plus d’intelligence, vous pouvez passer l’option -3
qui demande à Git de tenter une fusion à trois sources.
Cette option n’est pas active par défaut parce qu’elle ne fonctionne pas si le commit sur lequel le patch indique être basé n’existe pas dans votre dépôt.
Si par contre, le patch est basé sur un commit public, l’option -3
est généralement beaucoup plus fine pour appliquer des patchs conflictuels :
$ git am -3 0001-seeing-if-this-helps-the-gem.patch
Applying: seeing if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Dans ce cas, je cherchais à appliquer un patch qui avait déjà été intégré.
Sans l’option -3
, cela aurait ressemblé à un conflit.
Si vous appliquez des patchs à partir d’un fichier mbox, vous pouvez aussi lancer la commande am
en mode interactif qui s’arrête à chaque patch trouvé et vous demande si vous souhaitez l’appliquer :
$ git am -3 -i mbox
Commit Body is:
--------------------------
seeing if this helps the gem
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
C’est agréable si vous avez un certain nombre de patchs sauvegardés parce que vous pouvez voir les patchs pour vous rafraîchir la mémoire et ne pas les appliquer s’ils ont déjà été intégrés.
Quand tous les patchs pour votre sujet ont été appliqués et validés dans votre branche, vous pouvez choisir si et comment vous souhaitez les intégrer dans une branche au long cours.
Vérification des branches distantes
Si votre contribution a été fournie par un utilisateur de Git qui a mis en place son propre dépôt public sur lequel il a poussé ses modifications et vous a envoyé l’URL du dépôt et le nom de la branche distante, vous pouvez les ajouter en tant que dépôt distant et réaliser les fusions localement.
Par exemple, si Jessica vous envoie un courriel indiquant qu’elle a une nouvelle fonctionnalité géniale dans la branche ruby-client
de son dépôt, vous pouvez la tester en ajoutant le dépôt distant et en tirant la branche localement :
$ git remote add jessica git://github.com/jessica/monproject.git
$ git fetch jessica
$ git checkout -b rubyclient jessica/ruby-client
Si elle vous envoie un autre mail indiquant une autre branche contenant une autre fonctionnalité géniale, vous pouvez la récupérer et la tester simplement à partir de votre référence distante.
C’est d’autant plus utile si vous travaillez en continu avec une personne. Si quelqu’un n’a qu’un seul patch à contribuer de temps en temps, l’accepter via courriel peut s’avérer moins consommateur en temps de préparation du serveur public, d’ajout et retrait de branches distantes juste pour tirer quelques patchs. Vous ne souhaiteriez sûrement pas devoir gérer des centaines de dépôts distants pour intégrer à chaque fois un ou deux patchs. Néanmoins, des scripts et des services hébergés peuvent rendre cette tâche moins ardue. Cela dépend largement de votre manière de développer et de celle de vos contributeurs.
Cette approche a aussi l’avantage de vous fournir l’historique des validations.
Même si vous pouvez rencontrer des problèmes de fusion légitimes, vous avez l’information dans votre historique de la base ayant servi pour les modifications contribuées.
La fusion à trois sources est choisie par défaut plutôt que d’avoir à spécifier l’option -3
en espérant que le patch a été généré à partir d’un instantané public auquel vous auriez accès.
Si vous ne travaillez pas en continu avec une personne mais souhaitez tout de même tirer les modifications de cette manière, vous pouvez fournir l’URL du dépôt distant à la commande git pull
.
Cela permet de réaliser un tirage unique sans sauver l’URL comme référence distante :
$ git pull https://github.com/pourunefois/projet
From https://github.com/onetimeguy/project
* branch HEAD -> FETCH_HEAD
Merge made by recursive.
Déterminer les modifications introduites
Vous avez maintenant une branche thématique qui contient les contributions. À partir de là, vous pouvez déterminer ce que vous souhaitez en faire. Cette section revisite quelques commandes qui vont vous permettre de faire une revue de ce que vous allez exactement introduire si vous fusionnez dans la branche principale.
Faire une revue de tous les commits dans cette branche s’avère souvent d’une grande aide.
Vous pouvez exclure les commits de la branche master
en ajoutant l’option --not
devant le nom de la branche.
C’est équivalent au format master..contrib
utilisé plus haut.
Par exemple, si votre contributeur vous envoie deux patchs et que vous créez une branche appelée contrib
et y appliquez ces patchs, vous pouvez lancer ceci :
$ git log contrib --not master
commit 5b6235bd297351589efc4d73316f0a68d484f118
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Oct 24 09:53:59 2008 -0700
seeing if this helps the gem
commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <schacon@gmail.com>
Date: Mon Oct 22 19:38:36 2008 -0700
updated the gemspec to hopefully work better
Pour visualiser les modifications que chaque commit introduit, souvenez-vous que vous pouvez passer l’option -p
à git log
et elle ajoutera le diff introduit à chaque commit.
Pour visualiser un diff complet de ce qui arriverait si vous fusionniez cette branche thématique avec une autre branche, vous pouvez utiliser un truc bizarre pour obtenir les résultats corrects. Vous pourriez penser à lancer ceci :
$ git diff master
Cette commande affiche un diff mais elle peut être trompeuse.
Si votre branche master
a avancé depuis que vous avez créé la branche thématique, vous obtiendrez des résultats apparemment étranges.
Cela arrive parce que Git compare directement l’instantané de la dernière validation sur la branche thématique et celui de la dernière validation sur la branche master
.
Par exemple, si vous avez ajouté une ligne dans un fichier sur la branche master
, une comparaison directe donnera l’impression que la branche thématique va retirer cette ligne.
Si master
est un ancêtre directe de la branche thématique, ce n’est pas un problème.
Si les deux historiques ont divergé, le diff donnera l’impression que vous ajoutez toutes les nouveautés de la branche thématique et retirez tout ce qui a été fait depuis dans la branche master
.
Ce que vous souhaitez voir en fait, ce sont les modifications ajoutées sur la branche thématique — le travail que vous introduirez si vous fusionnez cette branche dans master
.
Vous obtenez ce résultat en demandant à Git de comparer le dernier instantané de la branche thématique avec son ancêtre commun à la branche master
le plus récent.
Techniquement, c’est réalisable en déterminant exactement l’ancêtre commun et en lançant la commande diff
dessus :
$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db
ou de manière plus concise :
$ git diff $(git merge-base contrib master)
Néanmoins, comme ce n’est pas très commode, Git fournit un raccourci pour réaliser la même chose : la syntaxe à trois points.
Dans le contexte de la commande diff
, vous pouvez placer trois points après une autre branche pour réaliser un diff
entre le dernier instantané de la branche sur laquelle vous vous trouvez et son ancêtre commun avec une autre branche :
$ git diff master...contrib
Cette commande ne vous montre que les modifications que votre branche thématique a introduites depuis son ancêtre commun avec master. C’est une syntaxe très simple à retenir.
Intégration des contributions
Lorsque tout le travail de votre branche thématique est prêt à être intégré dans la branche principale, il reste à savoir comment le faire. De plus, il faut connaître le mode de gestion que vous souhaitez pour votre projet. Vous avez de nombreux choix et je vais en traiter quelques-uns.
Modes de fusion
Un mode simple fusionne votre travail dans la branche master
.
Dans ce scénario, vous avez une branche master
qui contient le code stable.
Quand vous avez des modifications prêtes dans une branche thématique, vous la fusionnez dans votre branche master
puis effacez la branche thématique, et ainsi de suite.
Si vous avez un dépôt contenant deux branches nommées ruby_client
et php_client
qui ressemble à Historique avec quelques branches thématiques. et que vous fusionnez ruby_client
en premier, suivi de php_client
, alors votre historique ressemblera à la fin à Après fusion des branches thématiques..
![Historique avec quelques branches thématiques.](png/merging-workflows-1.png)
![Après fusion des branches thématiques.](png/merging-workflows-2.png)
C’est probablement le mode le plus simple mais cela peut s’avérer problématique si vous avez à gérer des dépôts ou des projets plus gros pour lesquels vous devez être circonspect sur ce que vous acceptez.
Si vous avez plus de développeurs ou un projet plus important, vous souhaiterez probablement utiliser un cycle de fusion à deux étapes.
Dans ce scénario, vous avez deux branches au long cours, master
et develop
, dans lequel vous déterminez que master
est mis à jour seulement lors d’une version vraiment stable et tout le nouveau code est intégré dans la branche develop
.
Vous poussez régulièrement ces deux branches sur le dépôt public.
Chaque fois que vous avez une nouvelle branche thématique à fusionner (Avant la fusion d’une branche thématique.), vous la fusionnez dans develop
(Après la fusion d’une branche thématique.).
Puis, lorsque vous étiquetez une version majeure, vous mettez master
à niveau avec l’état stable de develop
en avance rapide (Après une publication d’une branche thématique.).
![Avant la fusion d’une branche thématique.](png/merging-workflows-3.png)
![Après la fusion d’une branche thématique.](png/merging-workflows-4.png)
![Après une publication d’une branche thématique.](png/merging-workflows-5.png)
Ainsi, lorsque l’on clone le dépôt de votre projet, on peut soit extraire la branche master
pour construire la dernière version stable et mettre à jour facilement ou on peut extraire la branche develop
qui représente le nec plus ultra du développement.
Vous pouvez aussi continuer ce concept avec une branche d’intégration où tout le travail est fusionné.
Alors, quand la base de code sur cette branche est stable et que les tests passent, vous la fusionnez dans la branche develop
.
Quand cela s’est avéré stable pendant un certain temps, vous mettez à jour la branche master
en avance rapide.
Gestions avec nombreuses fusions
Le projet Git dispose de quatre branches au long cours : master
, next
, pu
(proposed updates : propositions) pour les nouveaux travaux et maint
pour les backports de maintenance.
Quand une nouvelle contribution est proposée, elle est collectée dans des branches thématiques dans le dépôt du mainteneur d’une manière similaire à ce que j’ai décrit (Série complexe de branches thématiques contribuées en parallèle.).
À ce point, les fonctionnalités sont évaluées pour déterminer si elles sont stables et prêtes à être consommées ou si elles nécessitent un peaufinage.
Si elles sont stables, elles sont fusionnées dans next
et cette branche est poussée sur le serveur public pour que tout le monde puisse essayer les fonctionnalités intégrées ensemble.
![Série complexe de branches thématiques contribuées en parallèle.](png/large-merges-1.png)
Si les fonctionnalités nécessitent encore du travail, elles sont fusionnées plutôt dans pu
.
Quand elles sont considérées comme totalement stables, elles sont re-fusionnées dans master
et sont alors reconstruites à partir des fonctionnalités qui résidaient dans next
mais n’ont pu intégrer master
.
Cela signifie que master
évolue quasiment toujours en mode avance rapide, tandis que next
est rebasé assez souvent et pu
est rebasé encore plus souvent :
![Fusion des branches thématiques dans les branches à long terme.](png/large-merges-2.png)
Quand une branche thématique a finalement été fusionnée dans master
, elle est effacée du dépôt.
Le projet Git a aussi une branche maint
qui est créée à partir de la dernière version pour fournir des patchs correctifs en cas de besoin de version de maintenance.
Ainsi, quand vous clonez le dépôt de Git, vous avez quatre branches disponibles pour évaluer le projet à différentes étapes de développement, selon le niveau de développement que vous souhaitez utiliser ou pour lequel vous souhaitez contribuer.
Le mainteneur a une gestion structurée qui lui permet d’évaluer et sélectionner les nouvelles contributions.
Gestion par rebasage et sélection de commit
D’autres mainteneurs préfèrent rebaser ou sélectionner les contributions sur le sommet de la branche master
, plutôt que les fusionner, de manière à conserver un historique à peu près linéaire.
Lorsque plusieurs modifications sont présentes dans une branche thématique et que vous souhaitez les intégrer, vous vous placez sur cette branche et vous lancez la commande rebase
pour reconstruire les modifications à partir du sommet courant de la branche master
(ou develop
, ou autre).
Si cela fonctionne correctement, vous pouvez faire une avance rapide sur votre branche master
et vous obtenez finalement un historique de projet linéaire.
L’autre moyen de déplacer des modifications introduites dans une branche vers une autre consiste à les sélectionner ou les picorer (cherry-pick
).
Un picorage dans Git ressemble à un rebasage appliqué à un commit unique.
Cela consiste à prendre le patch qui a été introduit lors d’une validation et à essayer de l’appliquer sur la branche sur laquelle on se trouve.
C’est très utile si on a un certain nombre de commits sur une branche thématique et que l’on veut n’en intégrer qu’un seul, ou si on n’a qu’un commit sur une branche thématique et qu’on préfère le sélectionner plutôt que de lancer rebase
.
Par exemple, supposons que vous ayez un projet ressemblant à ceci :
![Historique d’exemple avant une sélection.](png/rebasing-1.png)
Si vous souhaitez tirer le commit e43a6
dans votre branche master
, vous pouvez lancer :
$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
3 files changed, 17 insertions(+), 3 deletions(-)
La même modification que celle introduite en e43a6
est tirée mais vous obtenez une nouvelle valeur de SHA-1 car les dates d’application sont différentes.
À présent, votre historique ressemble à ceci :
![Historique après sélection d’un _commit_ dans une branche thématique.](png/rebasing-2.png)
Maintenant, vous pouvez effacer votre branche thématique et abandonner les commits que vous n’avez pas tirés dans master
.
Rerere
Si vous fusionnez et rebasez beaucoup ou si vous maintenez une branche au long cours, la fonctionnalité appelée « rerere » peut s’avérer utile.
Rerere signifie « ré utiliser les ré solutions en re gistrées » (“ reuse recorded resolution ”) ‑ c’est un moyen de raccourcir les résolutions manuelles de conflit. Quand rerere est actif, Git va conserver un jeu de couples d’images pré et post fusion des fichiers ayant présenté des conflits, puis s’il s’aperçoit qu’un conflit ressemble à une de ces résolutions, il va utiliser la même stratégie sans rien vous demander.
Cette fonctionnalité se traite en deux phases : une étape de configuration et une commande.
L’étape de configuration est rerere.enabled
qui active la fonction et qu’il est facile de placer en config globale :
$ git config --global rerere.enabled true
Ensuite, quand vous fusionnez en résolvant des conflits, la résolution sera enregistrée dans le cache pour un usage futur.
Si besoin, vous pouvez interagir avec le cache rerere au moyen de la commande git rerere
.
Quand elle est invoquée telle quelle, Git vérifie sa base de données de résolutions et essaie de trouver une correspondance avec les conflits en cours et les résout (bien que ce soit automatique si rerere.enabled
est à true
).
Il existe aussi des sous-commandes permettant de voir ce qui sera enregistré, d’effacer du cache une résolution spécifique ou d’effacer entièrement le cache.
rerere est traité plus en détail dans Rerere.
Étiquetage de vos publications
Quand vous décidez de créer une publication de votre projet, vous souhaiterez probablement étiqueter le projet pour pouvoir recréer cette version dans le futur. Vous pouvez créer une nouvelle étiquette (tag) telle que décrite dans Les bases de Git. Si vous décidez de signer l’étiquette en tant que mainteneur, la commande ressemblera à ceci :
$ git tag -s v1.5 -m 'mon etiquette v1.5 signée'
Une phrase secrète est nécessaire pour déverrouiller la clef secrète de
l'utilisateur : "Scott Chacon <schacon@gmail.com>"
clé DSA de 1024 bits, identifiant F721C45A, créée le 2009-02-09
Si vous signez vos étiquettes, vous rencontrerez le problème de la distribution de votre clé publique PGP permettant de vérifier la signature.
Le mainteneur du projet Git a résolu le problème en incluant la clé publique comme blob dans le dépôt et en ajoutant une étiquette qui pointe directement sur ce contenu.
Pour faire de même, vous déterminez la clé de votre trousseau que vous voulez publier en lançant gpg --list-keys
:
$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid Scott Chacon <schacon@gmail.com>
sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09]
Ensuite, vous pouvez importer la clé directement dans la base de données Git en l’exportant de votre trousseau et en la redirigeant dans git hash-object
qui écrit un nouveau blob avec son contenu dans Git et vous donne en sortie le SHA-1 du blob :
$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92
À présent, vous avez le contenu de votre clé dans Git et vous pouvez créer une étiquette qui pointe directement dessus en spécifiant la valeur SHA-1 que la commande hash-object
vous a fournie :
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
Si vous lancez git push --tags
, l’étiquette maintainer-pgp-pub
sera partagée publiquement.
Un tiers pourra vérifier une étiquette après import direct de votre clé publique PGP, en extrayant le blob de la base de donnée et en l’important dans GPG :
$ git show maintainer-pgp-pub | gpg --import
Il pourra alors utiliser cette clé pour vérifier vos étiquettes signées.
Si de plus, vous incluez des instructions d’utilisation pour la vérification de signature dans le message d’étiquetage, l’utilisateur aura accès à ces informations en lançant la commande git show <étiquette>
.
Génération d’un nom de révision
Comme Git ne fournit pas par nature de nombres croissants tels que « r123 » à chaque validation, la commande git describe
permet de générer un nom humainement lisible pour chaque commit.
Git concatène le nom de l’étiquette la plus proche, le nombre de validations depuis cette étiquette et un code SHA-1 partiel du commit que l’on cherche à définir :
$ git describe master
v1.6.2-rc1-20-g8c5b85c
De cette manière, vous pouvez exporter un instantané ou le construire et le nommer de manière intelligible.
En fait, si Git est construit à partir du source cloné depuis le dépôt Git, git --version
vous donne exactement cette valeur.
Si vous demandez la description d’un instantané qui a été étiqueté, le nom de l’étiquette est retourné.
La commande git describe
repose sur les étiquettes annotées (étiquettes créées avec les options -a
ou -s
).
Les étiquettes de publication doivent donc être créées de cette manière si vous souhaitez utiliser git describe
pour garantir que les commits seront décrits correctement.
Vous pouvez aussi utiliser ces noms comme cible lors d’une extraction ou d’une commande show
, bien qu’ils reposent sur le SHA-1 abrégé et pourraient ne pas rester valides indéfiniment.
Par exemple, le noyau Linux a sauté dernièrement de 8 à 10 caractères pour assurer l’unicité des objets SHA-1 et les anciens noms git describe
sont par conséquent devenus invalides.
Préparation d’une publication
Maintenant, vous voulez publier une version.
Une des étapes consiste à créer une archive du dernier instantané de votre code pour les malheureux qui n’utilisent pas Git.
La commande dédiée à cette action est git archive
:
$ git archive master --prefix='projet/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz
Lorsqu’on ouvre l’archive, on obtient le dernier instantané du projet sous un répertoire projet
.
On peut aussi créer une archive au format zip de manière similaire en passant l’option --format=zip
à la commande git archive
:
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
Voilà deux belles archives tar.gz et zip de votre projet prêtes à être téléchargées sur un site web ou envoyées par courriel.
Shortlog
Il est temps d’envoyer une annonce à la liste de diffusion des nouveautés de votre projet.
Une manière simple d’obtenir rapidement une sorte de liste des modifications depuis votre dernière version ou courriel est d’utiliser la commande git shortlog
.
Elle résume toutes les validations dans l’intervalle que vous lui spécifiez.
Par exemple, ce qui suit vous donne un résumé de toutes les validations depuis votre dernière version si celle-ci se nomme v1.0.1 :
$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (8):
Add support for annotated tags to Grit::Tag
Add packed-refs annotated tag support.
Add Grit::Commit#to_patch
Update version and History.txt
Remove stray `puts`
Make ls_tree ignore nils
Tom Preston-Werner (4):
fix dates in history
dynamic version method
Version bump to 1.0.2
Regenerated gemspec for version 1.0.2
Vous obtenez ainsi un résumé clair de toutes les validations depuis v1.0.1, regroupées par auteur, prêt à être envoyé sur la liste de diffusion.