From e35913982cb17d0adb2142ee32688b3fa7f645d9 Mon Sep 17 00:00:00 2001 From: Jean-Christophe Helary Date: Sun, 20 Mar 2022 18:38:58 +0900 Subject: [PATCH 01/13] =?UTF-8?q?au=20=E2=86=92=20dans?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit la sortie PDF est "Comme présenté au Les bases de Git" et pas "Comme présenté au chapitre Les bases de Git". Il est préférable d'avoir "dans" ici dans ce contexte. --- book/10-git-internals/sections/refs.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index ad391b0..87ef56c 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -131,7 +131,7 @@ Il contient un étiqueteur, une date, un message et un pointeur. La principale différence est que l'étiquette pointe en général vers un _commit_ plutôt qu'un arbre. C'est comme une référence à une branche, mais elle ne bouge jamais : elle pointe toujours vers le même _commit_, lui donnant un nom plus sympathique. -Comme présenté au <>, il existe deux types d'étiquettes : annotée et légère. +Comme présenté dans <>, il existe deux types d'étiquettes : annotée et légère. Vous pouvez créer une étiquette légère comme ceci : [source,console] From d995b7d22ae3f571bb8f2b0b4557c43997431e03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9l=C3=A8ne=20Jonin?= Date: Thu, 29 Sep 2022 16:37:49 +0200 Subject: [PATCH 02/13] Fix formatting (extra space) --- book/02-git-basics/sections/recording-changes.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 5576aea..162ac5f 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -426,7 +426,7 @@ Cette action lance votre éditeur choisi. [NOTE] ==== - Ceci est paramétré par la variable d'environnement `EDITOR` de votre shell — habituellement vim ou Emacs, mais vous pouvez le paramétrer spécifiquement pour Git en utilisant la commande `git config --global core.editor` comme nous l'avons vu au <>).(((éditeur, changer par défaut)))(((commandes git, config))) +Ceci est paramétré par la variable d'environnement `EDITOR` de votre shell — habituellement vim ou Emacs, mais vous pouvez le paramétrer spécifiquement pour Git en utilisant la commande `git config --global core.editor` comme nous l'avons vu au <>).(((éditeur, changer par défaut)))(((commandes git, config))) ==== L'éditeur affiche le texte suivant (par exemple, ici Vim) : From 891bfe5e170adfd2e156844debb88145906c2a84 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A9l=C3=A8ne=20Jonin?= Date: Tue, 4 Oct 2022 15:45:53 +0200 Subject: [PATCH 03/13] Fix branch names * Synchronize branch names with names in figures * Harmonize names along pages --- .../sections/basic-branching-and-merging.asc | 28 ++++++++-------- .../sections/branch-management.asc | 12 +++---- book/03-git-branching/sections/nutshell.asc | 4 +-- book/03-git-branching/sections/rebasing.asc | 32 +++++++++---------- 4 files changed, 38 insertions(+), 38 deletions(-) diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 0c88a1c..189881f 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -76,15 +76,15 @@ C'est un point important à garder en mémoire : quand vous changez de branche, Il ajoute, retire et modifie automatiquement les fichiers de manière à s'assurer que votre copie de travail soit identique à ce qu'elle était lors de votre dernier _commit_ sur cette branche. Vous avez ensuite un correctif à faire. -Pour ce faire, créons une branche `correctif` sur laquelle travailler jusqu'à résolution du problème : +Pour ce faire, créons une branche `hotfix` sur laquelle travailler jusqu'à résolution du problème : [source,console] ---- -$ git checkout -b correctif -Switched to a new branch 'correctif' +$ git checkout -b hotfix +Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m "correction de l'adresse email incorrecte" -[correctif 1fb7853] "correction de l'adresse email incorrecte" +[hotfix 1fb7853] "correction de l'adresse email incorrecte" 1 file changed, 2 insertions(+) ---- @@ -97,7 +97,7 @@ Vous réalisez ceci au moyen de la commande `git merge` : [source,console] ---- $ git checkout master -$ git merge correctif +$ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ @@ -110,17 +110,17 @@ Autrement dit, lorsque l'on cherche à fusionner un _commit_ qui peut être atte Votre modification est maintenant dans l'instantané (_snapshot_) du _commit_ pointé par la branche `master` et vous pouvez déployer votre correctif. -.Avancement du pointeur de `master` sur `correctif` -image::images/basic-branching-5.png[Avancement du pointeur de `master` sur `correctif`] +.Avancement du pointeur de `master` sur `hotfix` +image::images/basic-branching-5.png[Avancement du pointeur de `master` sur `hotfix`] Après le déploiement de votre correctif super-important, vous voilà prêt à retourner travailler sur le sujet qui vous occupait avant l'interruption. -Cependant, vous allez avant cela effacer la branche `correctif` dont vous n'avez plus besoin puisque la branche `master` pointe au même endroit. +Cependant, vous allez avant cela effacer la branche `hotfix` dont vous n'avez plus besoin puisque la branche `master` pointe au même endroit. Vous pouvez l'effacer avec l'option `-d` de la commande `git branch` : [source,console] ---- -$ git branch -d correctif -Deleted branch correctif (3a0874c). +$ git branch -d hotfix +Deleted branch hotfix (3a0874c). ---- Maintenant, vous pouvez retourner travailler sur la branche qui contient vos travaux en cours pour le problème #53 : @@ -139,7 +139,7 @@ $ git commit -a -m 'Nouveau pied de page terminé [issue 53]' .Le travail continue sur `iss53` image::images/basic-branching-6.png[Le travail continue sur `iss53`] -Il est utile de noter que le travail réalisé dans la branche `correctif` n'est pas contenu dans les fichiers de la branche `iss53`. +Il est utile de noter que le travail réalisé dans la branche `hotfix` n'est pas contenu dans les fichiers de la branche `iss53`. Si vous avez besoin de les y rapatrier, vous pouvez fusionner la branche `master` dans la branche `iss53` en lançant la commande `git merge master`, ou vous pouvez retarder l'intégration de ces modifications jusqu'à ce que vous décidiez plus tard de rapatrier la branche `iss53` dans `master`. @@ -147,7 +147,7 @@ Si vous avez besoin de les y rapatrier, vous pouvez fusionner la branche `master ==== Fusions (_Merges_) Supposons que vous ayez décidé que le travail sur le problème #53 était terminé et prêt à être fusionné dans la branche `master`. -Pour ce faire, vous allez fusionner votre branche `iss53` de la même manière que vous l'avez fait plus tôt pour la branche `correctif`. +Pour ce faire, vous allez fusionner votre branche `iss53` de la même manière que vous l'avez fait plus tôt pour la branche `hotfix`. Tout ce que vous avez à faire est d'extraire la branche dans laquelle vous souhaitez fusionner et lancer la commande `git merge`: [source,console] @@ -160,7 +160,7 @@ README | 1 + 1 file changed, 1 insertion(+) ---- -Le comportement semble légèrement différent de celui observé pour la fusion précédente de la branche `correctif`. +Le comportement semble légèrement différent de celui observé pour la fusion précédente de la branche `hotfix`. Dans ce cas, à un certain moment, l'historique de développement a divergé. Comme le _commit_ sur la branche sur laquelle vous vous trouvez n'est plus un ancêtre direct de la branche que vous cherchez à fusionner, Git doit effectuer quelques actions. Dans ce cas, Git réalise une simple fusion à trois sources (_three-way merge_), en utilisant les deux instantanés pointés par les sommets des branches ainsi que leur plus proche ancêtre commun. @@ -188,7 +188,7 @@ $ git branch -d iss53 (((fusionner, conflits))) Quelques fois, le processus ci-dessus ne se déroule pas aussi bien. Si vous avez modifié différemment la même partie du même fichier dans les deux branches que vous souhaitez fusionner, Git ne sera pas capable de réaliser proprement la fusion. -Si votre résolution du problème #53 a modifié la même section de fichier que le `correctif`, vous obtiendrez un conflit qui ressemblera à ceci : +Si votre résolution du problème #53 a modifié la même section de fichier que le `hotfix`, vous obtiendrez un conflit qui ressemblera à ceci : [source,console] diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index ac9c329..5f0748f 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -12,7 +12,7 @@ Si vous la lancez sans argument, vous obtenez la liste des branches courantes : $ git branch iss53 * master - test + testing ---- Notez le caractère `*` qui préfixe la branche `master` : il indique la branche courante (c'est-à-dire la branche sur laquelle le pointeur `HEAD` se situe). @@ -24,7 +24,7 @@ Pour visualiser la liste des derniers _commits_ sur chaque branche, vous pouvez $ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' - test 782fd34 add scott to the author list in the readmes + testing 782fd34 add scott to the author list in the readmes ---- `--merged` et `--no-merged` sont des options très utiles qui permettent de filtrer les branches de cette liste selon que vous les avez ou ne les avez pas encore fusionnées avec la branche courante. @@ -45,7 +45,7 @@ Pour visualiser les branches qui contiennent des travaux qui n'ont pas encore é [source,console] ---- $ git branch --no-merged - test + testing ---- Ceci affiche votre autre branche. @@ -53,9 +53,9 @@ Comme elle contient des modifications qui n'ont pas encore été intégrées, es [source,console] ---- -$ git branch -d test -error: The branch 'test' is not fully merged. -If you are sure you want to delete it, run 'git branch -D test'. +$ git branch -d testing +error: The branch 'testing' is not fully merged. +If you are sure you want to delete it, run 'git branch -D testing'. ---- Si vous souhaitez réellement supprimer cette branche et perdre ainsi le travail réalisé, vous pouvez tout de même forcer la suppression avec l'option `-D`, comme l'indique le message. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 05b4bd2..f5a5a13 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -117,7 +117,7 @@ $ git commit -a -m 'made a change' .La branche HEAD avance à chaque _commit_ image::images/advance-testing.png[La branche HEAD avance à chaque _commit_] -C'est intéressant parce qu'à présent, votre branche `test` a avancé tandis que la branche `master` pointe toujours sur le _commit_ sur lequel vous étiez lorsque vous avez lancé la commande `git checkout` pour changer de branche. +C'est intéressant parce qu'à présent, votre branche `testing` a avancé tandis que la branche `master` pointe toujours sur le _commit_ sur lequel vous étiez lorsque vous avez lancé la commande `git checkout` pour changer de branche. Retournons sur la branche `master` : [source,console] @@ -143,7 +143,7 @@ image::images/checkout-master.png[HEAD est déplacé lors d'un _checkout_] Cette commande a réalisé deux actions. Elle a remis le pointeur `HEAD` sur la branche `master` et elle a replacé les fichiers de votre répertoire de travail dans l'état du _snapshot_ pointé par `master`. Cela signifie aussi que les modifications que vous réalisez à partir de ce point divergeront de l'ancienne version du projet. -Cette commande annule les modifications réalisées dans la branche `test` pour vous permettre de repartir dans une autre direction. +Cette commande annule les modifications réalisées dans la branche `testing` pour vous permettre de repartir dans une autre direction. [NOTE] .Changer de branche modifie les fichiers dans votre répertoire de travail diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 5e606cf..95b6828 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -26,7 +26,7 @@ Dans cet exemple, vous lanceriez les commandes suivantes : [source,console] ---- -$ git checkout experience +$ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command @@ -63,9 +63,9 @@ Rebaser rejoue les modifications d'une ligne de _commits_ sur une autre dans l'o Vous pouvez aussi faire rejouer votre rebasage sur autre chose qu'une branche. Prenez un historique tel que <> par exemple. -Vous avez créé une branche thématique (`serveur`) pour ajouter des fonctionnalités côté serveur à votre projet et avez réalisé un _commit_. +Vous avez créé une branche thématique (`server`) pour ajouter des fonctionnalités côté serveur à votre projet et avez réalisé un _commit_. Ensuite, vous avez créé une branche pour ajouter des modifications côté client (`client`) et avez validé plusieurs fois. -Finalement, vous avez rebasculé sur la branche `serveur` et avez réalisé quelques _commits_ supplémentaires. +Finalement, vous avez rebasculé sur la branche `server` et avez réalisé quelques _commits_ supplémentaires. [[rbdiag_e]] @@ -77,10 +77,10 @@ Vous pouvez récupérer les modifications du côté client qui ne sont pas sur l [source,console] ---- -$ git rebase --onto master serveur client +$ git rebase --onto master server client ---- -Cela signifie en substance "Extraire la branche client, déterminer les patchs depuis l'ancêtre commun des branches `client` et `serveur` puis les rejouer sur `master` ". +Cela signifie en substance "Extraire la branche client, déterminer les patchs depuis l'ancêtre commun des branches `client` et `server` puis les rejouer sur `master` ". C'est assez complexe, mais le résultat est assez impressionnant. .Rebaser deux branches thématiques l'une sur l'autre @@ -98,34 +98,34 @@ $ git merge client .Avance rapide sur votre branche `master` pour inclure les modifications de la branche client image::images/interesting-rebase-3.png[Avance rapide sur votre branche `master` pour inclure les modifications de la branche client] -Supposons que vous décidiez de tirer (_pull_) votre branche `serveur` aussi. -Vous pouvez rebaser la branche `serveur` sur la branche `master` sans avoir à l'extraire avant en utilisant `git rebase [branchedebase] [branchethematique]` — qui extrait la branche thématique (dans notre cas, `serveur`) pour vous et la rejoue sur la branche de base (`master`) : +Supposons que vous décidiez de tirer (_pull_) votre branche `server` aussi. +Vous pouvez rebaser la branche `server` sur la branche `master` sans avoir à l'extraire avant en utilisant `git rebase [branchedebase] [branchethematique]` — qui extrait la branche thématique (dans notre cas, `server`) pour vous et la rejoue sur la branche de base (`master`) : [source,console] ---- -$ git rebase master serveur +$ git rebase master server ---- -Cette commande rejoue les modifications de `serveur` sur le sommet de la branche `master`, comme indiqué dans <>. +Cette commande rejoue les modifications de `server` sur le sommet de la branche `master`, comme indiqué dans <>. [[rbdiag_h]] -.Rebasage de la branche serveur sur le sommet de la branche `master` -image::images/interesting-rebase-4.png[Rebasage de la branche serveur sur le sommet de la branche `master`] +.Rebasage de la branche server sur le sommet de la branche `master` +image::images/interesting-rebase-4.png[Rebasage de la branche server sur le sommet de la branche `master`] Vous pouvez ensuite faire une avance rapide sur la branche de base (`master`) : [source,console] ---- $ git checkout master -$ git merge serveur +$ git merge server ---- -Vous pouvez effacer les branches `client` et `serveur` une fois que tout le travail est intégré et que vous n'en avez plus besoin, éliminant tout l'historique de ce processus, comme visible sur <> : +Vous pouvez effacer les branches `client` et `server` une fois que tout le travail est intégré et que vous n'en avez plus besoin, éliminant tout l'historique de ce processus, comme visible sur <> : [source,console] ---- $ git branch -d client -$ git branch -d serveur +$ git branch -d server ---- [[rbdiag_i]] @@ -190,12 +190,12 @@ Ceci est appelé un "identifiant de patch" (_patch-id_). Si vous tirez des travaux qui ont été réécrits et les rebasez au-dessus des nouveaux _commits_ de votre collègue, Git peut souvent déterminer ceux qui sont uniquement les vôtres et les réappliquer au sommet de votre nouvelle branche. -Par exemple, dans le scénario précédent, si au lieu de fusionner quand nous étions à l'étape <> nous exécutons la commande `git rebase equipe1/master`, Git va : +Par exemple, dans le scénario précédent, si au lieu de fusionner quand nous étions à l'étape <> nous exécutons la commande `git rebase teamone/master`, Git va : * Déterminer quels travaux sont uniques à notre branche (C2, C3, C4, C6, C7) * Déterminer ceux qui ne sont pas des _commits_ de fusion (C2, C3, C4) * Déterminer ceux qui n'ont pas été réécrits dans la branche de destination (uniquement C2 et C3 puisque C4 est le même _patch_ que C4') -* Appliquer ces _commits_ au sommet de `equipe1/master` +* Appliquer ces _commits_ au sommet de `teamone/master` Ainsi, au lieu du résultat que nous avons observé au chapitre <>, nous aurions pu finir avec quelque chose qui ressemblerait davantage à <>. From 287dba42562fb9bda61a1d875434b3bcd9e026a6 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Fri, 25 Nov 2022 14:07:00 +0100 Subject: [PATCH 04/13] fix grammar mistake --- book/01-introduction/sections/first-time-setup.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 115278e..2519209 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -88,7 +88,7 @@ Sous Windows par exemple, l'opération de Git pourrait être terminée prématur Par défaut Git crée une branche nommée _master_ quand vous créez un nouveau repository avec `git init`. Depuis Git version 2.28, vous pouvez définir un nom différent pour la branche initiale. -Pour définir _main_ comme nom de branche par défaut, utiliser la commande : +Pour définir _main_ comme nom de branche par défaut, utilisez la commande : [source,console] ---- From 0fbd6c83fc1d862cc9b885e85bfe190a234830a8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= Date: Sat, 16 Sep 2023 13:58:37 +0200 Subject: [PATCH 05/13] rmove duplicated pr github action --- .github/workflows/pr-build.yml | 24 ------------------------ 1 file changed, 24 deletions(-) delete mode 100644 .github/workflows/pr-build.yml diff --git a/.github/workflows/pr-build.yml b/.github/workflows/pr-build.yml deleted file mode 100644 index 20bbc0d..0000000 --- a/.github/workflows/pr-build.yml +++ /dev/null @@ -1,24 +0,0 @@ -name: Pull Request Build - -on: - pull_request: - branches: [ main, master ] - -jobs: - build: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v2 - - - name: Download bootstrap file - run: wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh - - name: Run bootstrap - run: sh bootstrap.sh - - name: Set up Ruby - uses: ruby/setup-ruby@v1 - with: - ruby-version: 2.7 - bundler-cache: true # runs 'bundle install' and caches installed gems automatically - - - name: Build book - run: bundle exec rake book:build_action From 5e68be60bea67f6d12d76b765ce131c5982550e3 Mon Sep 17 00:00:00 2001 From: Adrien Ollier Date: Fri, 15 Sep 2023 21:31:27 +0200 Subject: [PATCH 06/13] Bazaar est mort --- .../sections/client-bzr.asc | 134 ---------------- .../sections/import-bzr.asc | 145 ------------------ ch09-git-and-other-systems.asc | 4 - 3 files changed, 283 deletions(-) delete mode 100644 book/09-git-and-other-scms/sections/client-bzr.asc delete mode 100644 book/09-git-and-other-scms/sections/import-bzr.asc diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc deleted file mode 100644 index 4f6d10f..0000000 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ /dev/null @@ -1,134 +0,0 @@ -==== Git et Bazaar - -Parmi tous les systèmes de contrôle de version distribués, un des plus connus est https://bazaar.canonical.com/[Bazaar]. -Bazaar est libre et open source, et fait partie du https://www.gnu.org/[Projet GNU]. -Il a un comportement très différent de Git. -Parfois, pour faire la même chose que Git, il vous faudra utiliser un mot-clé différent, et quelques mots-clés communs n'ont pas la même signification. -En particulier, la gestion des branches est très différente et peut être déroutante, surtout pour quelqu'un qui viendrait du monde de Git. -Toutefois, il est possible de travailler sur un dépôt Bazaar depuis un dépôt Git. - -Il y a plein de projets qui permettent d'utiliser Git comme client d'un dépôt Bazaar. -Ici nous utiliserons le projet de Felipe Contreras que vous pouvez trouver à l'adresse https://github.com/felipec/git-remote-bzr. -Pour l'installer, il suffit de télécharger le fichier `git-remote-bzr` dans un dossier de votre `$PATH` et de le rendre exécutable : -[source,console] ----- -$ wget https://raw.github.com/felipec/git-remote-bzr/master/git-remote-bzr -O ~/bin/git-remote-bzr -$ chmod +x ~/bin/git-remote-bzr ----- - -Vous devez aussi avoir Bazaar installé. -C'est tout ! - - -===== Créer un dépôt Git depuis un dépôt Bazaar - -C'est simple à utiliser. -Il suffit de cloner un dépôt Bazaar en préfixant son nom par `bzr::`. -Puisque Git et Bazaar font des copies complètes sur votre machine, il est possible de lier un clone Git à votre clone Bazaar local, mais ce n'est pas recommandé. -Il est beaucoup plus facile de lier votre clone Git directement au même endroit que l'est votre clone Bazaar ‒ le dépôt central. - -Supposons que vous travailliez avec un dépôt distant qui se trouve à l'adresse `bzr+ssh://developpeur@monserveurbazaar:monprojet`. -Alors vous devez le cloner de la manière suivante : -[source,console] ----- -$ git clone bzr::bzr+ssh://developpeur@monserveurbazaar:monprojet monProjet-Git -$ cd monProjet-Git ----- - -A ce stade, votre dépôt Git est créé mais il n'est pas compacté pour un usage optimal de l'espace disque. -C'est pourquoi vous devriez aussi nettoyer et compacter votre dépôt Git, surtout si c'est un gros dépôt : -[source,console] ----- -$ git gc --aggressive ----- - - -===== Les branches Bazaar - -Bazaar ne vous permet de cloner que des branches, mais un dépôt peut contenir plusieurs branches, et `git-remote-bzr` peut cloner les deux. -Par exemple, pour cloner une branche : -[source,console] ----- -$ git clone bzr::bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk ----- - -Et pour cloner le dépôt entier : -[source,console] ----- -$ git clone bzr::bzr:/bzr.savannah.gnu.org/emacs emacs ----- - -La seconde commande clone toutes les branches contenues dans le dépôt emacs ; néanmoins il est possible de spécifier quelques branches : -[source,console] ----- -$ git config remote-bzr.branches 'trunk, xwindow' ----- - -Certains dépôts ne permettent pas de lister leurs branches, auquel cas vous devez les préciser manuellement, et même si vous pourriez spécifier la configuration dans la commande de clonage, vous pourriez trouver ceci plus facile : -[source,console] ----- -$ git init emacs -$ git remote add origin bzr::bzr://bzr.savannah.gnu.org/emacs -$ git config remote-bzr.branches 'trunk, xwindow' -$ git fetch ----- - - -===== Ignorer ce qui est ignoré avec .bzrignore - -Puisque vous travaillez sur un projet géré sous Bazaar, vous ne devriez pas créer de fichier `.gitignore` car vous pourriez le mettre accidentellement en gestion de version et les autres personnes travaillant sous Bazaar en seraient dérangées. -La solution est de créer le fichier `.git/info/exclude`, soit en tant que lien symbolique, soit en tant que véritable fichier. -Nous allons voir plus loin comment trancher cette question. - -Bazaar utilise le même modèle que Git pour ignorer les fichiers, mais possède en plus deux particularités qui n'ont pas d'équivalent dans Git. -La description complète se trouve dans http://doc.bazaar.canonical.com/bzr.2.7/en/user-reference/ignore-help.html[la documentation]. -Les deux particularités sont : - -1. le "!!" en début de chaîne de caractères qui prévaut sur le "!" en début de chaîne, ce qui permet d'ignorer des fichiers qui auraient été inclus avec "!" -2. les chaînes de caractères commençant par "RE:". -Ce qui suit "RE:" est une http://doc.bazaar.canonical.com/bzr.2.7/en/user-reference/patterns-help.html[expression rationnelle]. -Git ne permet pas d'utiliser des expressions rationnelles, seulement les globs shell. - -Par conséquent, il y a deux situations différentes à envisager : - -1. Si le fichier `.bzrignore` ne contient aucun de ces deux préfixes particuliers, alors vous pouvez simplement faire un lien symbolique vers celui-ci dans le dépôt. -2. Sinon, vous devez créer le fichier `.git/info/exclude` et l'adapter pour ignorer exactement les mêmes fichiers que dans `.bzrignore`. - -Quel que soit le cas de figure, vous devrez rester vigilant aux modifications du fichier `.bzrignore` pour faire en sorte que le fichier `.git/info/exclude` reflète toujours `.bzrignore`. -En effet, si le fichier `.bzrignore` venait à changer et comporter une ou plusieurs lignes commençant par "!!" ou "RE:", Git ne pouvant interpréter ces lignes, il vous faudra adapter le fichier `.git/info/exclude` pour ignorer les mêmes fichiers que ceux ignorés avec `.bzrignore`. -De surcroît, si le fichier `.git/info/exclude` était un lien symbolique vers `.bzrignore`, il vous faudra alors d'abord détruire le lien symbolique, copier le fichier `.bzrignore` dans `.git/info/exclude` puis adapter ce dernier. -Attention toutefois à son élaboration car avec Git il est impossible de ré-inclure un fichier dont l'un des dossiers parent a été exclu. - - -===== Récupérer les changements du dépôt distant - -Pour récupérer les changements du dépôt distant, vous tirez les modifications comme d'habitude, en utilisant les commandes Git. -En supposant que vos modifications sont sur la branche `master`, vous fusionnez ou rebasez votre travail sur la branche `origin/master` : -[source,console] ----- -$ git pull --rebase origin ----- - - -===== Pousser votre travail sur le dépôt distant - -Comme Bazaar a lui aussi le concept de _commits_ de fusion, il n'y aura aucun problème si vous poussez un _commit_ de fusion. -Donc vous créez vos branches et travaillez dessus, vous testez et validez votre travail par l'intermédiaire de _commits_ comme d'habitude, puis vous fusionnez vos modifications dans `master` et vous poussez votre travail sur le dépôt Bazaar : -[source,console] ----- -$ git push origin master ----- - -===== Mise en garde - -Le cadriciel de l'assistant de dépôt distant de Git a des limitations qui s'imposent. -En particulier, les commandes suivantes ne fonctionnent pas : - -* git push origin :branche-à-effacer (Bazaar n'accepte pas de supprimer une branche de cette façon) -* git push origin ancien:nouveau (il poussera 'ancien') -* git push --dry-run origin branch (il poussera) - -===== Résumé - -Comme les modèles de Git et de Bazaar sont similaires, il n'y a pas beaucoup de difficulté à travailler à la frontière. -Tant que vous faites attention aux limitations, et tant que vous êtes conscient que le dépôt distant n'est pas nativement Git, tout ira bien. diff --git a/book/09-git-and-other-scms/sections/import-bzr.asc b/book/09-git-and-other-scms/sections/import-bzr.asc deleted file mode 100644 index 8bb40aa..0000000 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ /dev/null @@ -1,145 +0,0 @@ -==== Bazaar -(((Bazaar)))(((Importation, depuis Bazaar))) - -Bazaar est un système de contrôle de version distribué tout comme Git, en conséquence de quoi il est assez facile de convertir un dépôt Bazaar en un dépôt Git. -Pour cela, vous aurez besoin d'importer le plugin `bzr-fastimport`. - - -===== Obtenir le plugin bzr-fastimport - -La procédure d'installation du plugin `bzr-fastimport` est différente sur les systèmes type UNIX et sur Windows. -Dans le premier cas, le plus simple est d'installer le paquet `bzr-fastimport` avec toutes les dépendances requises. - -Par exemple, sur Debian et dérivés, vous feriez comme cela : -[source,console] ----- -$ sudo apt-get install bzr-fastimport ----- - -Avec RHEL, vous feriez ainsi : -[source,console] ----- -$ sudo yum install bzr-fastimport ----- - -Avec Fedora, depuis la sortie de la version 22, le nouveau gestionnaire de paquets est dnf : -[source,console] ----- -$ sudo dnf install bzr-fastimport ----- - -Si le paquet n'est pas disponible, vous pouvez l'installer en tant que plugin : -[source,console] ----- -$ mkdir --parents ~/.bazaar/plugins/ # crée les dossiers nécessaires aux plugins -$ cd ~/.bazaar/plugins/ -$ bzr branch lp:bzr-fastimport fastimport # importe le plugin bzr-fastimport -$ cd fastimport -$ sudo python setup.py install --record=files.txt # installe le plugin ----- - -Pour que ce plugin fonctionne, vous aurez aussi besoin du module Python `fastimport`. -Vous pouvez vérifier s'il est présent ou non et l'installer avec les commandes suivantes : -[source,console] ----- -$ python -c "import fastimport" -Traceback (most recent call last): - File "" , line 1, in -ImportError: No module named fastimport -$ pip install fastimport ----- - -S'il n'est pas disponible, vous pouvez le télécharger à l'adresse https://pypi.python.org/pypi/fastimport/. - -Dans le second cas (sous Windows), `bzr-fastimport` est automatiquement installé avec la version _standalone_ et l'installation par défaut (laisser toutes les cases à cocher cochées). -Alors, vous n'avez rien à faire. - -À ce stade, la façon d'importer un dépôt Bazaar diffère selon que vous n'avez qu'une seule branche ou que vous travaillez avec un dépôt qui a plusieurs branches. - - -===== Projet avec une seule branche - -Maintenant positionnez-vous dans le dossier qui contient votre dépôt Bazaar et initialisez le dépôt Git : -[source,console] ----- -$ cd /chemin/vers/le/depot/bzr -$ git init ----- - -Vous pouvez exporter simplement votre dépôt Bazaar et le convertir en un dépôt Git avec la commande suivante : -[source,console] ----- -$ bzr fast-export --plain . | git fast-import ----- - -Selon la taille du projet, votre dépôt Git est constitué dans un délai allant de quelques secondes à plusieurs minutes. - -===== Cas d'un projet avec une branche principale et une branche de travail - -Vous pouvez aussi importer un dépôt Bazaar qui contient plusieurs branches. -Supposons que vous avez deux branches : l'une représente la branche principale (monProjet.trunk), l'autre est la branche de travail (monProjet.travail). -[source,console] ----- -$ ls -monProjet.trunk monProjet.travail ----- - -Créez le dépôt Git et placez-vous-y : -[source,console] ----- -$ git init depot-git -$ cd depot-git ----- - -Tirez la branche principale dans le dépôt git : -[source,console] ----- -$ bzr fast-export --marks=../marks.bzr --plain ../monProjet.trunk | \ -git fast-import --export-marks=../marks.git ----- - -Tirez la branche de travail dans le dépôt git : -[source,console] ----- -$ bzr fast-export --marks=../marks.bzr --plain --git-branch=travail ../monProjet.travail | \ -git fast-import --import-marks=../marks.git --export-marks=../marks.git ----- - -Maintenant, `git branch` vous montre la branche `master` tout comme la branche `travail`. -Vérifiez les logs pour vous assurer qu'ils sont complets et supprimez les fichiers `marks.bzr` et `marks.git`. - -===== Synchroniser l'index - -Quel que soit le nombre de branches que vous aviez et la méthode d'importation, votre index n'est pas synchronisé avec HEAD, et avec l'import de plusieurs branches, votre répertoire de travail n'est pas synchronisé non plus. -Cette situation se résout simplement avec la commande suivante : -[source,console] ----- -$ git reset --hard HEAD ----- - -===== Ignorer les fichiers qui étaient ignorés avec .bzrignore - -Occupons-nous maintenant des fichiers à ignorer. -Il faut tout d'abord renommer le fichier `.bzrignore` en `.gitignore`. -Si le fichier `.bzrignore` contient une ou des lignes commençant par "!!" ou "RE:", il vous faudra en plus le modifier et peut-être créer de multiples fichiers `.gitignore` afin d'ignorer exactement les mêmes fichiers que le permettait `.bzrignore`. - -Finalement, vous devrez créer un _commit_ qui contient cette modification pour la migration : -[source,console] ----- -$ git mv .bzrignore .gitignore -$ # modifier le fichier .gitignore au besoin -$ git commit -m 'Migration de Bazaar vers Git' ----- - -===== Envoyer votre dépôt git sur le serveur - -Nous y sommes enfin ! -Vous pouvez maintenant pousser votre dépôt sur son nouveau serveur d'hébergement : -[source,console] ----- -$ git remote add origin git@mon-serveur-git:mon-depot-git.git -$ git push origin --all -$ git push origin --tags ----- - -La migration de Bazaar vers Git est maintenant terminée, vous pouvez travailler sur votre dépôt git. diff --git a/ch09-git-and-other-systems.asc b/ch09-git-and-other-systems.asc index 232ca9a..48f963f 100644 --- a/ch09-git-and-other-systems.asc +++ b/ch09-git-and-other-systems.asc @@ -20,8 +20,6 @@ include::book/09-git-and-other-scms/sections/client-svn.asc[] include::book/09-git-and-other-scms/sections/client-hg.asc[] -include::book/09-git-and-other-scms/sections/client-bzr.asc[] - include::book/09-git-and-other-scms/sections/client-p4.asc[] [[s_migrating]] @@ -36,8 +34,6 @@ include::book/09-git-and-other-scms/sections/import-svn.asc[] include::book/09-git-and-other-scms/sections/import-hg.asc[] -include::book/09-git-and-other-scms/sections/import-bzr.asc[] - include::book/09-git-and-other-scms/sections/import-p4.asc[] include::book/09-git-and-other-scms/sections/import-custom.asc[] From 8fc6cadc6d194d1a9b574fb209167d6879ca57c9 Mon Sep 17 00:00:00 2001 From: Adrien Ollier Date: Sat, 16 Sep 2023 19:30:47 +0200 Subject: [PATCH 07/13] =?UTF-8?q?Ne=20plus=20mentionner=20Bazaar=20suite?= =?UTF-8?q?=20=C3=A0=20#157?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/about-version-control.asc | 2 +- book/01-introduction/sections/what-is-git.asc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index d441a7c..28adaf3 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -50,7 +50,7 @@ Les systèmes de gestion de version locaux souffrent du même problème — dès (((gestion de version, distribuée))) C'est à ce moment que les systèmes de gestion de version distribués entrent en jeu (DVCS en anglais pour _Distributed Version Control Systems_). -Dans un DVCS (tel que Git, Mercurial, Bazaar ou Darcs), les clients n'extraient plus seulement la dernière version d'un fichier, mais ils dupliquent complètement le dépôt. +Dans un DVCS (tel que Git, Mercurial ou Darcs), les clients n'extraient plus seulement la dernière version d'un fichier, mais ils dupliquent complètement le dépôt. Ainsi, si le serveur disparaît et si les systèmes collaboraient via ce serveur, n'importe quel dépôt d'un des clients peut être copié sur le serveur pour le restaurer. Chaque extraction devient une sauvegarde complète de toutes les données. diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 48f4d13..3013625 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -9,7 +9,7 @@ Git enregistre et gère l'information très différemment des autres systèmes, La différence majeure entre Git et les autres VCS (Subversion et autres) réside dans la manière dont Git considère les données. Au niveau conceptuel, la plupart des autres systèmes gèrent l'information comme une liste de modifications de fichiers. -Ces systèmes (CVS, Subversion, Perforce, Bazaar et autres) considèrent l'information qu'ils gèrent comme une liste de fichiers et les modifications effectuées sur chaque fichier dans le temps. +Ces systèmes (CVS, Subversion, Perforce et autres) considèrent l'information qu'ils gèrent comme une liste de fichiers et les modifications effectuées sur chaque fichier dans le temps. .D'autres systèmes sauvent l'information comme des modifications sur des fichiers. image::images/deltas.png[D'autres systèmes sauvent l'information comme des modifications sur des fichiers.] From 004adb31bbe1a1aaaf5e84c7a75a4423b0aea48c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Isma=C3=ABl=20Maurice?= <55036198+tisma95@users.noreply.github.com> Date: Tue, 14 Nov 2023 07:28:03 +0100 Subject: [PATCH 08/13] Update gitlab.asc --- book/04-git-server/sections/gitlab.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index cd307f1..71768f8 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -122,7 +122,7 @@ Les utilisateurs qui n'ont pas la permission de pousser sur un dépôt peuvent e Ce modèle permet au propriétaire de garder le contrôle total sur ce qui entre dans le dépôt et quand, tout en autorisant les contributions des utilisateurs non fiables. Les requêtes de fusion (_merge requests_) et les problèmes (_issues_) sont les principaux moyens pour mener des discussions au long cours dans GitLab. -Chaque requête de fusion permet une discussion ligne par ligne sur les modifications proposées (qui permettent un sorte de revue de code légère), ainsi qu'un fil de discussion général. +Chaque requête de fusion permet une discussion ligne par ligne sur les modifications proposées (qui permettent une sorte de revue de code légère), ainsi qu'un fil de discussion général. Requêtes de fusion et problèmes peuvent être assignés à des utilisateurs ou assemblés en jalons (_milestones_). Cette section se concentre principalement sur les parties de GitLab dédiées à Git, mais c'est un système assez mature qui fournit beaucoup d'autres fonctions qui peuvent aider votre équipe à coopérer. From 1a5548b7cf264a83e8fa3b81136f44b2475c45b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antonin=20D=C3=A9cimo?= Date: Wed, 29 Nov 2023 12:54:16 +0100 Subject: [PATCH 09/13] Fix link syntax --- book/05-distributed-git/sections/contributing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 80c4a65..7a6b6e7 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -804,7 +804,7 @@ Result: OK [TIP] ==== -Pour plus d'aide sur comment configurer votre système et votre courriel, plus de trucs et astuces, et un bac à sable pour faire ses essais d'envoi de rustines par courriel, rendez-vous sur [git-send-email.io](https://git-send-email.io/). +Pour plus d'aide sur comment configurer votre système et votre courriel, plus de trucs et astuces, et un bac à sable pour faire ses essais d'envoi de rustines par courriel, rendez-vous sur https://git-send-email.io/[git-send-email.io]. ==== ==== Résumé From 8d8248d4a9cbaf56f6830ea00c561ba08e8e5aea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Isma=C3=ABl=20Maurice?= <55036198+tisma95@users.noreply.github.com> Date: Tue, 12 Dec 2023 15:12:18 +0100 Subject: [PATCH 10/13] Fix Update rewriting-history.asc --- book/07-git-tools/sections/rewriting-history.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index ca30be7..e70ce1a 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -45,7 +45,7 @@ Ne modifiez pas votre dernière validation si vous l'avez déjà publiée ! Quand vous corrigez un commit, vous avez la possibilité de modifier à la fois le contenu du commit et le message de validation. Si vous modifiez le contenu du commit de manière substantielle, vous devriez presque certainement modifier de même le message de validation pour refléter le contenu corrigé. -D'un autre côté, si vos corrections sont triviales (corriger un faute de frappe ou ajouter un fichier oublié) de telle sorte que le message de validation précédent est toujours correct, vous pouvez simplement faire la modification, l'indexer, et éviter complètement la session d'édition inutile avec : +D'un autre côté, si vos corrections sont triviales (corriger une faute de frappe ou ajouter un fichier oublié) de telle sorte que le message de validation précédent est toujours correct, vous pouvez simplement faire la modification, l'indexer, et éviter complètement la session d'édition inutile avec : [source,console] ---- From 753848b16cc30dbf8c6674dd9f24b16b74bb6f02 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Isma=C3=ABl=20Maurice?= <55036198+tisma95@users.noreply.github.com> Date: Wed, 27 Dec 2023 08:41:01 +0100 Subject: [PATCH 11/13] Update submodules.asc --- book/07-git-tools/sections/submodules.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index d622f11..9e18d67 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -439,7 +439,7 @@ Cela forcera Git à lancer `git submodule update` juste après le tirage, de ma De plus, si vous voulez que Git tire toujours avec `--recurse-submodules`, vous pouvez régler l'option de configuration `submodule.recurse` à true (cela marche pour `git pull` depuis Git 2.15). Cette option forcera Git à utiliser le drapeau `--recurse-submodules` pour toutes les commandes qui le supportent (à part `clone`). -Il y a une situation spéciale qui peut arriver lors du tirage depuis le super-projet ; le dépôt amont peut avoir modifié l'URL du sous-module dans le fichier `.gitmodules` dans un des commits qui vous tirez. +Il y a une situation spéciale qui peut arriver lors du tirage depuis le super-projet ; le dépôt amont peut avoir modifié l'URL du sous-module dans le fichier `.gitmodules` dans un des commits que vous tirez. Cela peut arriver si le projet du sous-module change de plate-forme d'hébergement. Dans ce dernier cas, il est possible pour `git pull --recurse-submodules`, or `git submodule update`, d'échouer si le super-projet fait référence à un commit d'un sous-module qui n'est pas trouvé dans le serveur distant du sous-module configuré localement dans votre dépôt. Pour corriger cette situation, la commande `git submodule sync` est nécessaire : From 9b7e6a281819ea847b3093c4983fb524ecde5382 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20DURANDY?= Date: Fri, 28 Mar 2025 19:26:58 +0100 Subject: [PATCH 12/13] Fix typing error --- C-git-commands.asc | 2 +- book/01-introduction/sections/first-time-setup.asc | 2 +- book/02-git-basics/sections/aliases.asc | 2 +- book/02-git-basics/sections/getting-a-repository.asc | 2 +- book/02-git-basics/sections/recording-changes.asc | 4 ++-- book/02-git-basics/sections/tagging.asc | 8 ++++---- book/03-git-branching/sections/branch-management.asc | 2 +- book/03-git-branching/sections/rebasing.asc | 4 ++-- book/03-git-branching/sections/remote-branches.asc | 4 ++-- book/04-git-server/sections/generating-ssh-key.asc | 2 +- book/04-git-server/sections/git-daemon.asc | 2 +- book/05-distributed-git/sections/contributing.asc | 10 +++++----- book/06-github/sections/5-scripting.asc | 2 +- book/07-git-tools/sections/credentials.asc | 2 +- book/07-git-tools/sections/debugging.asc | 2 +- book/07-git-tools/sections/rerere.asc | 4 ++-- book/07-git-tools/sections/revision-selection.asc | 6 +++--- book/07-git-tools/sections/signing.asc | 2 +- book/07-git-tools/sections/stashing-cleaning.asc | 2 +- book/07-git-tools/sections/submodules.asc | 4 ++-- book/08-customizing-git/sections/config.asc | 4 ++-- book/10-git-internals/sections/environment.asc | 10 +++++----- book/10-git-internals/sections/objects.asc | 4 ++-- book/10-git-internals/sections/packfiles.asc | 6 +++--- book/10-git-internals/sections/transfer-protocols.asc | 4 ++-- book/A-git-in-other-environments/sections/guis.asc | 4 ++-- .../sections/jetbrainsides.asc | 4 ++-- book/B-embedding-git/sections/jgit.asc | 2 +- book/B-embedding-git/sections/libgit2.asc | 6 +++--- 29 files changed, 56 insertions(+), 56 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index 0f6d45f..7da59eb 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -48,7 +48,7 @@ En plus des instructions de configuration dans < .Liste exhaustive de commandes de configuration de `core.editor` [cols="1,2",options="header"] |============================== -|Editeur | Commande de configuration +|Éditeur | Commande de configuration |Atom |`git config --global core.editor "atom --wait"` |BBEdit (Mac, with command line tools) |`git config --global core.editor "bbedit -w"` |Emacs |`git config --global core.editor emacs` diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 2519209..6c09ef5 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -10,7 +10,7 @@ Ces variables peuvent être stockées dans trois endroits différents : 1. `[chemin]/etc/gitconfig` : Contient les valeurs pour tous les utilisateurs et tous les dépôts du système. Si vous passez l'option `--system` à `git config`, il lit et écrit ce fichier spécifiquement. - Parce que c'est un fichier de configuration au niveau système, vous aurez besoin de privilèges admnistrateur ou super-utilisateur pour le modifier. + Parce que c'est un fichier de configuration au niveau système, vous aurez besoin de privilèges administrateur ou super-utilisateur pour le modifier. 2. Fichier `~/.gitconfig` : Spécifique à votre utilisateur. Vous pouvez forcer Git à lire et écrire ce fichier en passant l'option `--global` et cela affecte _tous_ les dépôts avec lesquels vous travaillez sur ce système. 3. Fichier `config` dans le répertoire Git (c'est-à-dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours. diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 55608fa..89cfdfb 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -3,7 +3,7 @@ (((alias))) Avant de clore ce chapitre sur les bases de Git, il reste une astuce qui peut rendre votre apprentissage de Git plus simple, facile ou familier : les alias. -Nous n'y ferons pas référence ni ne les considèrerons utilisés dans la suite du livre, mais c'est un moyen de facilité qui mérite d'être connu. +Nous n'y ferons pas référence ni ne les considérerons utilisés dans la suite du livre, mais c'est un moyen de facilité qui mérite d'être connu. Git ne complète pas votre commande si vous ne la tapez que partiellement. Si vous ne voulez pas avoir à taper l'intégralité du texte de chaque commande, vous pouvez facilement définir un alias pour chaque commande en utilisant `git config`.(((commandes git, config))) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index b50a39f..ce27c8e 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -3,7 +3,7 @@ Vous pouvez principalement démarrer un dépôt Git de deux manières. -1. Vous pouvez prendre un répertoire existant et le transformer en dépot Git. +1. Vous pouvez prendre un répertoire existant et le transformer en dépôt Git. 2. Vous pouvez _cloner_ un dépôt Git existant sur un autre serveur. Dans les deux cas, vous vous retrouvez avec un dépôt Git sur votre machine locale, prêt pour y travailler. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 162ac5f..1ebe96a 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -5,7 +5,7 @@ Vous devez faire quelques modifications et valider des instantanés de ces modif Souvenez-vous que chaque fichier de votre copie de travail peut avoir deux états : sous suivi de version ou non suivi. Les fichiers suivis sont les fichiers qui appartenaient déjà au dernier instantané ; ils peuvent être inchangés, modifiés ou indexés. -En résumé, les fichiers suivis sont ceux que Git connait. +En résumé, les fichiers suivis sont ceux que Git connaît. Tous les autres fichiers sont non suivis — tout fichier de votre copie de travail qui n'appartenait pas à votre dernier instantané et n'a pas été indexé. Quand vous clonez un dépôt pour la première fois, tous les fichiers seront sous suivi de version et inchangés car Git vient tout juste de les extraire et vous ne les avez pas encore édités. @@ -219,7 +219,7 @@ Renseigner un fichier `.gitignore` avant de commencer à travailler est généra Les règles de construction des patrons à placer dans le fichier `.gitignore` sont les suivantes : * les lignes vides ou commençant par `#` sont ignorées ; -* les patrons standards de fichiers sont utilisables et seront appliqués recursivement dans tout l'arbre de travail ; +* les patrons standards de fichiers sont utilisables et seront appliqués récursivement dans tout l'arbre de travail ; * si le patron commence par une barre oblique (`/), le patron n'est pas récursif ; * si le patron se termine par une barre oblique (`/`), il indique un répertoire ; * un patron commençant par un point d'exclamation (`!`) indique des fichiers à inclure malgré les autres règles. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 3e69bdc..cff8618 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -140,11 +140,11 @@ $ git log --pretty=oneline a6b4c97498bd301d84096da251c98a07c7723e65 Début de l'écriture support 0d52aaab4479697da7686c15f77a3d64d9165190 Un truc de plus 6d52a271eda8725415634dd79daabbc4d9b6008e Fusion branche 'experimental' -0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc ajout d'une fonction de validatn -4682c3261057305bdd616e23b64b0857d832627b ajout fichier afaire -166ae0c4d3f420721acbb115cc33848dfcc2121a début de l'ecriture support +0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc ajout d'une fonction de validation +4682c3261057305bdd616e23b64b0857d832627b ajout fichier a_faire +166ae0c4d3f420721acbb115cc33848dfcc2121a début de l'écriture support 9fceb02d0ae598e95dc970b74767f19372d61af8 mise à jour rakefile -964f16d36dfccde844893cac5b347e7b3d44abbc validation afaire +964f16d36dfccde844893cac5b347e7b3d44abbc validation a_faire 8a5cbc430f1a9c3d00faaeffd07798508422908a mise à jour lisezmoi ---- diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index 5f0748f..c72dde5 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -2,7 +2,7 @@ === Gestion des branches (((branches, gestion))) -Maintenant que vous avez créé, fusionné et supprimé des branches, regardons de plus près les outils de gestion des branches qui s'avèreront utiles lors d'une utilisation intensive des branches. +Maintenant que vous avez créé, fusionné et supprimé des branches, regardons de plus près les outils de gestion des branches qui se révéleront utiles lors d'une utilisation intensive des branches. La commande `git branch` permet en fait bien plus que la simple création et suppression de branches.(((commandes git, branche))) Si vous la lancez sans argument, vous obtenez la liste des branches courantes : diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 95b6828..6f76425 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -15,8 +15,8 @@ image::images/basic-rebase-1.png[Historique divergeant simple] Comme nous l'avons déjà expliqué, le moyen le plus simple pour intégrer ces branches est la fusion via la commande `merge`. Cette commande réalise une _fusion à trois branches_ entre les deux derniers instantanés (_snapshots_) de chaque branche (C3 et C4) et l'ancêtre commun le plus récent (C2), créant un nouvel instantané (et un _commit_). -.Fusion pour intégrer des travaux aux historiques divergeants -image::images/basic-rebase-2.png[Fusion pour intégrer des travaux aux historiques divergeants] +.Fusion pour intégrer des travaux aux historiques divergeant +image::images/basic-rebase-2.png[Fusion pour intégrer des travaux aux historiques divergeant] Cependant, il existe un autre moyen : vous pouvez prendre le _patch_ de la modification introduite en `C4` et le réappliquer sur `C3`. Dans Git, cette action est appelée "rebaser" (_rebasing_). diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index fae26a0..7023cc0 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -148,13 +148,13 @@ Branch correctionserveur set up to track remote branch correctionserveur from or Switched to a new branch 'correctionserveur' ---- -En fait, c'est tellement habituel qu'il y a même un raccourci de ce racccouci. +En fait, c'est tellement habituel qu'il y a même un raccourci de ce raccourci. Si le nom de branche que vous essayez d'extraire (a) n'existe pas et (b) correspond à un seul nom sur un seul distant, Git va créer une branche de suivi pour vous : [source,console] ---- $ git checkout correctionserveur -Branch serverfix set up to track remote branch correctionserveur from origin. +Branch correctionserveur set up to track remote branch correctionserveur from origin. Switched to a new branch 'correctionserveur' ---- Pour créer une branche locale avec un nom différent de celui de la branche distante, vous pouvez simplement utiliser la première version avec un nom différent de branche locale : diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index c8200f5..560bda1 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -17,7 +17,7 @@ authorized_keys2 id_dsa known_hosts config id_dsa.pub ---- -Recherchez une paire de fichiers appelés _quelquechose_ et _quelquechose_`.pub` où le _quelquechose_ en question est généralement `id_dsa` ou `id_rsa`. +Recherchez une paire de fichiers appelés _quelque_chose_ et _quelque_chose_`.pub` où le _quelque_chose_ en question est généralement `id_dsa` ou `id_rsa`. Le fichier en `.pub` est la clé publique tandis que l'autre est la clé privée. Si vous ne voyez pas ces fichiers (ou n'avez même pas de répertoire `.ssh`), vous pouvez les créer en lançant un programme appelé `ssh-keygen` fourni par le paquet SSH sur les systèmes Linux/macOS et MSysGit pour Windows : diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 3546ef2..e3301fa 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -21,7 +21,7 @@ Si vous utilisez un pare-feu, il sera nécessaire de rediriger le port 9418 sur Transformer ce processus en _daemon_ peut s'effectuer de différentes manières qui dépendent du système d'exploitation sur lequel il est lancé. -Puisque `systemd` est le système d'init le plus habitituel sur les distributions Linux modernes, vous pouvez l'utiliser pour cela. +Puisque `systemd` est le système d'init le plus habituel sur les distributions Linux modernes, vous pouvez l'utiliser pour cela. Placez simplement un fichier `/etc/systemd/system/git-daemon.service` avec le contenu suivant : [source,console] diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 7a6b6e7..67f7a84 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -128,8 +128,8 @@ Clonage dans 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb -$ git commit -am 'Eliminer une valeur par défaut invalide' -[master 738ee87] Eliminer une valeur par défaut invalide +$ git commit -am 'Éliminer une valeur par défaut invalide' +[master 738ee87] Éliminer une valeur par défaut invalide 1 files changed, 1 insertions(+), 1 deletions(-) ----- @@ -261,7 +261,7 @@ commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith Date: Fri May 29 16:01:27 2009 -0700 - Eliminer une valeur par defaut invalide + Éliminer une valeur par défaut invalide ----- @@ -485,8 +485,8 @@ Elle valide donc encore et pousse ses changements sur le serveur : [source,console] ----- -$ git commit -am 'details regles' -[fonctionA ed774b3] details regles +$ git commit -am 'details règles' +[fonctionA ed774b3] details règles 1 files changed, 1 insertions(+), 1 deletions(-) $ git push ... diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 4689628..c1a3071 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -107,7 +107,7 @@ image::images/scripting-04-webhook-debug.png[Webhook debug] L'autre fonctionnalité intéressante est que vous pouvez redéclencher la livraison de n'importe quel message pour tester votre service. -Pour plus d'information sur l'écriture de crochets web et tous les différents types d'événement que vous pouvez écouter, rendez-vous à la documentation du Developpeur GitHub à l'adresse https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks[]. +Pour plus d'information sur l'écriture de crochets web et tous les différents types d'événement que vous pouvez écouter, rendez-vous à la documentation du Développeur GitHub à l'adresse https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks[]. ==== L'interface de programmation (_API_) GitHub diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index f92bef0..d89b18b 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -54,7 +54,7 @@ Voici à quoi ressemblerait un `.gitconfig` si vous utilisiez un fichier d'ident ==== Sous le capot Comment tout ceci fonctionne-t-il ? -La commande d'origine de Git pour le système d'assistants d'indentification est `git credential`, qui accepte une commande comme argument, puis d'autres informations via stdin. +La commande d'origine de Git pour le système d'assistants d'identification est `git credential`, qui accepte une commande comme argument, puis d'autres informations via stdin. Un exemple peut aider à mieux comprendre cela. Supposons qu'un assistant d'identification a été configuré et que l'assistant a stocké les identifiants pour `mygithost`. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 23cd50e..b273002 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -92,7 +92,7 @@ Bisecting: 6 revisions left to test after this Git trouve qu'il y a environ 12 _commits_ entre celui que vous avez marqué comme le dernier bon connu (v1.0) et la version courante qui n'est pas bonne, et il a récupéré le _commit_ du milieu à votre place. À ce moment, vous pouvez dérouler vos tests pour voir si le bogue existait dans ce _commit_. Si c'est le cas, il a été introduit quelque part avant ce _commit_ médian, sinon, il l'a été évidemment après. -Il apparait que le bogue ne se reproduit pas ici, vous le dites à Git en tapant `git bisect good` et continuez votre périple : +Il apparaît que le bogue ne se reproduit pas ici, vous le dites à Git en tapant `git bisect good` et continuez votre périple : [source,console] ---- diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 72db1b7..c4deada 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -1,10 +1,10 @@ [[s_sect_rerere]] === Rerere -La fonctionalité `git rerere` est une fonction un peu cachée. +La fonctionnalité `git rerere` est une fonction un peu cachée. Le nom vient de l'anglais _reuse recorded resolution_ (« _ré_ utiliser les _ré_ solutions en _re_ gistrées ») et comme son nom l'indique, cela permet de demander à Git de se souvenir comment vous avez résolu un conflit sur une section de diff de manière que la prochaine fois qu'il rencontre le même conflit, il le résolve automatiquement pour vous. -Il existe pas mal de scénarios pour lesquels cette fonctionalité peut se montrer efficace. +Il existe pas mal de scénarios pour lesquels cette fonctionnalité peut se montrer efficace. Un exemple mentionné dans la documentation cite le cas d'une branche au long cours qui finira par fusionner proprement mais ne souhaite pas montrer des fusions intermédiaires. Avec `rerere` activé, vous pouvez fusionner de temps en temps, résoudre les conflits, puis sauvegarder la fusion. Si vous faites ceci en continu, alors la dernière fusion devrait être assez facile parce que `rerere` peut quasiment tout faire automatiquement pour vous. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 1580449..554530b 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -49,7 +49,7 @@ $ git show 1c002dd4b536e7479f $ git show 1c002d ---- -Git peut déterminer une référence SHA-1 tout à la fois la plus courte possible et non ambigüe. +Git peut déterminer une référence SHA-1 tout à la fois la plus courte possible et non ambiguë. Ajoutez l'option `--abbrev-commit` à la commande `git log` et le résultat affiché utilisera des valeurs plus courtes mais uniques ; par défaut Git retiendra 7 caractères et augmentera au besoin : [source,console] @@ -83,7 +83,7 @@ Voici un exemple pour vous donner une idée de ce qui pourrait provoquer une col Si tous les 6,5 milliards d'humains sur Terre programmaient et que chaque seconde, chacun produisait du code équivalent à l'historique entier du noyau Linux (6,5 millions d'objets Git) et le poussait sur un énorme dépôt Git, cela prendrait 2 ans pour que ce dépôt contienne assez d'objets pour avoir une probabilité de 50 % qu'une seule collision SHA-1 existe. Ainsi, une collision organique de SHA-1 est moins probable que tous les membres de votre équipe de programmeurs soient attaqués et tués par des loups dans des incidents sans relation la même nuit. -Si vous y dédiiez plusieurs milliers de dollars de puissance de calcul, il searit possible de synthétiser deux fichiers avec la même empreinte, comme prouvé par https://shattered.io/[] en février 2017. +Si vous y dédiiez plusieurs milliers de dollars de puissance de calcul, il serait possible de synthétiser deux fichiers avec la même empreinte, comme prouvé par https://shattered.io/[] en février 2017. Git évolue vers l'utilisation de SHA256 comme algorithme par défaut d'empreinte, qui est beaucoup plus résilient aux attaques par collision, et a déjà du code en place pour amenuiser cette attaque (bien qu'il ne puisse pas totalement éliminer cette faiblesse) ==== @@ -366,7 +366,7 @@ $ git log refA refB ^refC $ git log refA refB --not refC ---- -Ceci vous fournit un système de requêtage des révisions très puissant, pour vous aider à saisir ce qui se trouve sur vos branches. +Ceci vous fournit un système de requête des révisions très puissant, pour vous aider à saisir ce qui se trouve sur vos branches. [[s_triple_dot]] ===== Triple point diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index ddade6c..fdd76cf 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -150,7 +150,7 @@ En complément, vous pouvez configurer `git log` pour vérifier toutes les signa $ git log --pretty="format:%h %G? %aN %s" 5c3386c G Scott Chacon commit signé -ca82a6d N Scott Chacon changed the verison number +ca82a6d N Scott Chacon changed the version number 085bb3b N Scott Chacon removed unnecessary test code a11bef0 N Scott Chacon first commit ---- diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 5a255ca..4b763b8 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -11,7 +11,7 @@ Remiser prend l'état en cours de votre répertoire de travail, c'est-à-dire le .Migrer vers `git stash push` ==== Courant fin octobre 2017, il y a eu de longues discussions sur la liste de diffusion Git, pour rendre obsolète la commande `git stash save` au profit de l'alternative existante `git stash push`. -La raison principale en est que `git stash push` introduit une option pour remiser des _specificateurs de chemin_ sélectionnés, ce que `git stash save` ne sait pas faire. +La raison principale en est que `git stash push` introduit une option pour remiser des _spécificateurs de chemin_ sélectionnés, ce que `git stash save` ne sait pas faire. `git stash save` ne va disparaître immédiatement, donc ne vous inquiétez pas. Néanmoins il serait préférable de commencer à migrer vers l'alternative `push` pour bénéficier des nouvelles fonctionnalités. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 9e18d67..1656293 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -434,7 +434,7 @@ nothing to commit, working tree clean Notez que pour rester en sécurité, vous devriez lancer `git submodule update` avec le drapeau `--init` au cas où les commits de ProjetPrincipal que vous venez de tirer ont ajouté des nouveaux sous-modules, et le drapeau `--recursive` si certains sous-module ont des sous-modules imbriqués. -Si vous souhaitez automatiser ce processsus, vous pouvez ajouter le drapeau `--recurse-submodules` à la commande `git pull` (depuis Git 2.14). +Si vous souhaitez automatiser ce processus, vous pouvez ajouter le drapeau `--recurse-submodules` à la commande `git pull` (depuis Git 2.14). Cela forcera Git à lancer `git submodule update` juste après le tirage, de manière à mettre à jour les sous-modules dans l'état correct. De plus, si vous voulez que Git tire toujours avec `--recurse-submodules`, vous pouvez régler l'option de configuration `submodule.recurse` à true (cela marche pour `git pull` depuis Git 2.15). Cette option forcera Git à utiliser le drapeau `--recurse-submodules` pour toutes les commandes qui le supportent (à part `clone`). @@ -969,7 +969,7 @@ Cela peut être vraiment déroutant, donc c'est toujours une bonne idée de touj Pour les versions anciennes de Git qui n'ont pas de drapeau `--recurse-submodules`, après l'extraction, vous pouvez utiliser `git submodule update --init --recursive` pour placer les sous-modules dans le bon état. Par chance, vous pouvez indiquer à Git (>=2.14) de toujours utiliser le drapeau `--recurse-submodules` en paramétrant l'option de configuration `submodule.recurse` : `git config submodule.recurse true`. -Comme noté ci-dessus, cela forcera auss Git à parcourir récursivement les sous-modules pour toute commande qui accepte l'option `--recurse-submodules` (excepté `git clone`). +Comme noté ci-dessus, cela forcera aussi Git à parcourir récursivement les sous-modules pour toute commande qui accepte l'option `--recurse-submodules` (excepté `git clone`). ===== Basculer d'un sous-répertoire à un sous-module diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index a9cbcd7..5ae5b55 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -172,7 +172,7 @@ Si vous avez fait une faute de frappe en tapant une commande Git, il vous affich [source,console] ---- $ git chekcout master -git : 'chekcout' n'est pas une commande git. Voir 'git --help'. +git : 'checkout' n'est pas une commande git. Voir 'git --help'. Vouliez-vous dire cela ? checkout @@ -184,7 +184,7 @@ Si vous positionnez le paramètre `help.autocorrect` à 1, Git va réellement la [source,console] ---- $ git chekcout master -ATTENTION : vous avez invoqué une commande Git nommée 'chekcout' qui n'existe pas. +ATTENTION : vous avez invoqué une commande Git nommée 'checkout' qui n'existe pas. Continuons en supposant que vous avez voulu dire 'checkout' dans 0.1 secondes automatiquement... ---- diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 94f771f..17d34b8 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -36,7 +36,7 @@ Git utilise plusieurs variables d'environnement pour déterminer comment interag S'il n'est pas spécifié, Git remonte l'arbre des répertoires jusqu'à ce qu'il arrive à `~` ou bien `/`, en cherchant un répertoire `.git` à chaque étape. *`GIT_CEILING_DIRECTORIES`* contrôle le comportement de Git pendant la recherche d'un répertoire `.git`. -Si vous êtes sur des répertoires qui se chargent lentement (par exemple sur une bande magnétique ou à travers une connexion réseau lente), vous pouvez souhaiter que Git s'arrête plus tôt qu'il ne le ferait habituellemnt, surtout si Git est appelé à la construction de votre appel shell (_prompt_). +Si vous êtes sur des répertoires qui se chargent lentement (par exemple sur une bande magnétique ou à travers une connexion réseau lente), vous pouvez souhaiter que Git s'arrête plus tôt qu'il ne le ferait habituellement, surtout si Git est appelé à la construction de votre appel shell (_prompt_). *`GIT_WORK_TREE`* est l'emplacement de la racine du répertoire de travail pour un dépôt non nu. Si cette variable n'est pas spécifiée, c'est le répertoire parent de `$GIT_DIR` qui est utilisé. @@ -45,7 +45,7 @@ Si cette variable n'est pas spécifiée, c'est le répertoire parent de `$GIT_DI *`GIT_OBJECT_DIRECTORY`* peut être utilisé pour spécifier l'emplacement du répertoire qui se trouve habituellement à `.git/objects`. -*`GIT_ALTERNATE_OBJECT_DIRECTORIES`* est une liste séparée par des « : » (formattée comme ceci : `/rep/un:/rep/deux:…`) qui dit à Git où trouver les objets s'ils ne sont pas dans `GIT_OBJECT_DIRECTORY`. +*`GIT_ALTERNATE_OBJECT_DIRECTORIES`* est une liste séparée par des « : » (formatée comme ceci : `/rep/un:/rep/deux:…`) qui dit à Git où trouver les objets s'ils ne sont pas dans `GIT_OBJECT_DIRECTORY`. S'il vous arrive d'avoir beaucoup de projets avec des gros fichiers ayant exactement le même contenu, cette variable peut vous éviter d'en garder trop de copies. @@ -71,7 +71,7 @@ La création finale d'un objet Git _commit_ est habituellement faite par `git-co *`GIT_AUTHOR_EMAIL`* est l'adresse de courriel pour le champ « Auteur ». -*`GIT_AUTHOR_DATE`* est l'horodatage utilisé pourle champ « Auteur ». +*`GIT_AUTHOR_DATE`* est l'horodatage utilisé pour le champ « Auteur ». *`GIT_COMMITTER_NAME`* définit le nom humain pour le champ « Validateur » (_commiter_). @@ -107,7 +107,7 @@ Les seules valeurs valides sont `-u` ou `--unified=`, qui contrôlent le n Si elle est définie, Git invoquera ce programme quand `git diff` sera invoquée. *`GIT_DIFF_PATH_COUNTER`* et *`GIT_DIFF_PATH_TOTAL`* sont utiles à l'intérieur du programme spécifié par `GIT_EXTERNAL_DIFF` ou `diff.external`. -Le premier represente le fichier de la série dont on est en train de visualiser les différences (en commençant par 1), et le dernier est le nombre total de fichiers dans le lot. +Le premier représente le fichier de la série dont on est en train de visualiser les différences (en commençant par 1), et le dernier est le nombre total de fichiers dans le lot. *`GIT_MERGE_VERBOSITY`* contrôle la sortie pour la stratégie de fusion récursive. Les valeurs admises sont les suivantes : @@ -175,7 +175,7 @@ $ GIT_TRACE_PACKET=true git ls-remote origin ---- *`GIT_TRACE_PERFORMANCE`* contrôle la journalisation d'information de performance. -La sortie montre combien de temps prend chaque invocation particulère de Git. +La sortie montre combien de temps prend chaque invocation particulière de Git. [source,console] ---- diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index 867543f..738646d 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -260,9 +260,9 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d [NOTE] ==== -Vous obtiendrez une valeur de hashage différente à cause d'un moment de création et d'une information d'auteur différents. +Vous obtiendrez une valeur de hash différente à cause d'un moment de création et d'une information d'auteur différents. De plus, bien qu'en principe tout objet commit peut être reproduit précisément en lui fournissant la même donnée, les détails historiques de la construction de ce livre signifient que les empreintes de commit affichées peuvent ne pas correspondre aux commits donnés. -Remplacez les valeurs de hashage de _commit_ et d'étiquette par vos propres valeurs de somme de contrôle dans la suite de ce chapitre. +Remplacez les valeurs de hash de _commit_ et d'étiquette par vos propres valeurs de somme de contrôle dans la suite de ce chapitre. ==== Vous pouvez voir votre nouvel objet _commit_ avec `git cat-file` : diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 3e005e3..a9abf67 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -164,6 +164,6 @@ La troisième colonne de l'affichage est la taille de l'objet dans le fichier co Ce qui est aussi intéressant est que la seconde version du fichier est celle qui est enregistrée telle quelle, tandis que la version originale est enregistrée sous forme d'un delta. La raison en est que vous aurez sans doute besoin d'accéder rapidement aux versions les plus récentes du fichier. -Une chose intéressante à propos de ceci est que l'on peut recompacter à tout moment. -Git recompacte votre base de donnée occasionnellement, en essayant d'économiser de la place. -Vous pouvez aussi recompacter à la main, en exécutant la commande `git gc` vous-même. +Une chose intéressante à propos de ceci est que l'on peut recompresser à tout moment. +Git recompresse votre base de donnée occasionnellement, en essayant d'économiser de la place. +Vous pouvez aussi recompresser à la main, en exécutant la commande `git gc` vous-même. diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index 0cc0eb0..b04c9ee 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -157,7 +157,7 @@ Chaque ligne commence avec une valeur hexadécimale sur 4 caractères, spécifia La première ligne, ici, commence avec `00a5`, soit 165 en hexadécimal, ce qui signifie qu'il y a 165 octets restants sur cette ligne. La ligne d'après est `0000`, signifiant que le serveur a fini de lister ses références. -Maintenant qu'il connait l'état du serveur, votre exécutable `send-pack` détermine quels _commits_ il a de plus que le serveur. +Maintenant qu'il connaît l'état du serveur, votre exécutable `send-pack` détermine quels _commits_ il a de plus que le serveur. L'exécutable `send-pack` envoie alors à l'exécutable `receive-pack` les informations concernant chaque référence que cette commande `push` va mettre à jour. Par exemple, si vous mettez à jour la branche `master` et ajoutez la branche `experiment`, la réponse de `send-pack` ressemblera à quelque chose comme : @@ -288,7 +288,7 @@ La réponse à cette requête indique le succès ou l'échec, et contient le fic ==== Résumé sur les protocoles Cette section contient un survol basique des protocoles de transfert. -Les protocoles contiennent de nombreuses autres fonctionalités, +Les protocoles contiennent de nombreuses autres fonctionnalités, comme les compétences `multi_ack` ou `side-band`, mais leur étude est hors du sujet de ce livre. Nous avons essayé de vous donner une idée générale des échanges entre client et serveur. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 88f8820..39309a0 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -31,8 +31,8 @@ Gitk accepte de nombreuses options de ligne de commande, dont la plupart sont pa L'une des plus intéressantes est probablement d'ajouter l'option `--all` qui indique à gitk de montrer tous les _commits_ joignables depuis _n'importe quelle_ référence, et pas seulement HEAD. L'interface de Gitk ressemble à ceci : -.Le visualisateur d'historique `gitk`. -image::images/gitk.png[Le visualisateur d'historique `gitk`.] +.Le visualiseur d'historique `gitk`. +image::images/gitk.png[Le visualiseur d'historique `gitk`.] Dans la partie supérieure, une zone ressemble à la sortie de `git log --graph`. Chaque point représente un _commit_, les lignes représentent les liens de parenté et les références apparaissent dans des rectangles colorés. diff --git a/book/A-git-in-other-environments/sections/jetbrainsides.asc b/book/A-git-in-other-environments/sections/jetbrainsides.asc index a10df30..1da85f7 100644 --- a/book/A-git-in-other-environments/sections/jetbrainsides.asc +++ b/book/A-git-in-other-environments/sections/jetbrainsides.asc @@ -1,10 +1,10 @@ === Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine -Les EDI (environnements de développement intégrés) de JetBrains (tels que IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine, et autres) sont livrés avec un greffont d'integration Git. +Les EDI (environnements de développement intégrés) de JetBrains (tels que IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine, et autres) sont livrés avec un greffon d'integration Git. Celui-ci fournit une vue dédiée dans l'EDI pour travailler avec Git et les requêtes de tirage GitHub. .Cadre de gestion de version dans les EDI JetBrains image::images/jb.png[Cadre de gestion de version dans les EDI JetBrains] -L'intrégration repose sur le client git en ligne de commande et nécessite qu'un client soit installé. +L’intégration repose sur le client git en ligne de commande et nécessite qu'un client soit installé. La documentation officielle se trouve sur https://www.jetbrains.com/help/idea/using-git-integration.html[]. diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index efebce8..15a8a2f 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -2,7 +2,7 @@ (((jgit)))(((java))) Si vous voulez utiliser Git depuis un programme Java, il existe une bibliothèque complète appelée JGit. -JGit est une réalisation relativement complète de Git écrite nativement en Java etelle est largement utilisée dans la communauté Java. +JGit est une réalisation relativement complète de Git écrite nativement en Java et elle est largement utilisée dans la communauté Java. Le projet JGit est développé sous l'égide d'Eclipse et son site se trouve sur https://www.eclipse.org/jgit[]. ==== Mise en place diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index ed70566..2b85f6e 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -14,12 +14,12 @@ En voici un tour rapide : git_repository *repo; int error = git_repository_open(&repo, "/path/to/repository"); -// Dereferencer HEAD vers un commit +// Déréférencer HEAD vers un commit git_object *head_commit; error = git_revparse_single(&head_commit, repo, "HEAD^{commit}"); git_commit *commit = (git_commit*)head_commit; -// afficher quelques proprietes du commit +// afficher quelques propriétés du commit printf("%s", git_commit_message(commit)); const git_signature *author = git_commit_author(commit); printf("%s <%s>\n", author->name, author->email); @@ -228,7 +228,7 @@ Notre programme d'exemple : [source,python] ---- pygit2.Repository("/chemin/du/depot") # ouvre le depot - .head # recupere la branche en cours + .head # récupère la branche en cours .peel(pygit2.Commit) # descend au commit .message # lit le message ---- From fc2449d72b7ba8cbf0a79e5df400559a17a3fd96 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= Date: Wed, 30 Apr 2025 18:22:06 +0200 Subject: [PATCH 13/13] fix non-existing URLs in dulwich and libgit2 sections --- book/B-embedding-git/sections/dulwich.asc | 6 +++--- book/B-embedding-git/sections/libgit2.asc | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/book/B-embedding-git/sections/dulwich.asc b/book/B-embedding-git/sections/dulwich.asc index 13ec6c9..9daf6e0 100644 --- a/book/B-embedding-git/sections/dulwich.asc +++ b/book/B-embedding-git/sections/dulwich.asc @@ -2,7 +2,7 @@ (((Dulwich)))(((Python))) Il existe aussi une implantation Git en Python pur - Dulwich. -Le projet est hébergé sous https://www.dulwich.io/[]. +Le projet est hébergé sous https://github.com/jelmer/dulwich[]. Il vise à fournir une interface vers les dépôts Git (locaux et distant) qui n'appelle pas git directement mais n'utilise purement que Python. Il dispose d'extensions C optionnelles cependant, qui améliorent significativement les performances. @@ -40,5 +40,5 @@ porcelain.log('.', max_entries=1) ==== Autres informations - * La documentation officielle de l'API est disponible sur https://www.dulwich.io/docs/api/ - * Le tutoriel officiel https://www.dulwich.io/docs/tutorial[] contient de nombreux exemples de tâches spécifiques réalisées avec Dulwich. + * La documentation officielle de l'API est disponible sur \https://www.dulwich.io/docs/api/[] + * Le tutoriel officiel \https://www.dulwich.io/docs/tutorial[] contient de nombreux exemples de tâches spécifiques réalisées avec Dulwich. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 2b85f6e..f03618c 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -3,7 +3,7 @@ (((libgit2)))((("C"))) Une autre option à votre disposition consiste à utiliser Libgit2. Libgit2 est une mise en œuvre de Git sans dépendance externe, qui se focalise sur une interface de programmation agréable à utiliser depuis d'autres programmes. -Vous pouvez la trouver sur https://libgit2.github.com[]. +Vous pouvez la trouver sur https://libgit2.org[]. Voyons d'abord à quoi ressemble l'API C. En voici un tour rapide : @@ -237,5 +237,5 @@ pygit2.Repository("/chemin/du/depot") # ouvre le depot ==== Pour aller plus loin Bien sûr, un traitement complet des capacités de Libgit2 est hors du cadre de ce livre. -Si vous souhaitez plus d'information sur Libgit2 elle-même, la documentation de programmation se trouve sur https://libgit2.github.com/libgit2[] et un ensemble de guides sur https://libgit2.github.com/docs[]. +Si vous souhaitez plus d'information sur Libgit2 elle-même, la documentation de programmation se trouve sur https://libgit2.org/docs/reference/main/[] et un ensemble de guides sur https://libgit2.org/docs/[]. Pour les autres liaisons, cherchez dans le README et dans les tests ; il y a souvent des petits didacticiels et des pointeurs sur d'autres documents.