-
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..
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.).
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.
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 :
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 :
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 :
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.