Remplacement de Mac par macOS lorsqu'il s'agit du système d'exploitation.

comme progit/progit2#1161 et progit/progit2#1231

Author: aollier

book/01-introduction/sections/about-version-control.asc

@@ -23,7 +23,6 @@ Pour traiter ce problème, les programmeurs ont développé il y a longtemps des
 image::images/local.png[Diagramme de gestion de version locale]
 
 Un des systèmes les plus populaires était RCS, qui est encore distribué avec de nombreux systèmes d'exploitation aujourd'hui.
-Même le système d'exploitation populaire Mac OS X inclut le programme `rcs` lorsqu'on installe les outils de développement logiciel.
 Cet outil fonctionne en conservant des ensembles de patchs (c'est-à-dire la différence entre les fichiers) d'une version à l'autre dans un format spécial sur disque ; il peut alors restituer l'état de n'importe quel fichier à n'importe quel instant en ajoutant toutes les différences.
 
 === Les systèmes de gestion de version centralisés

book/01-introduction/sections/command-line.asc

@@ -7,5 +7,5 @@ Tout d'abord, la ligne de commande est la seule interface qui permet de lancer *
 Si vous savez comment utiliser la version en ligne de commande, vous serez à même de comprendre comment fonctionne la version graphique, tandis que l'inverse n'est pas nécessairement vrai.
 De plus, le choix d'un outil graphique est sujet à des goûts personnels, mais _tous_ les utilisateurs auront les commandes en lignes installées et utilisables.
 
-Nous considérons que vous savez ouvrir un Terminal sous Mac ou une invite de commandes ou PowerShell sous Windows.
+Nous considérons que vous savez ouvrir un Terminal sous macOS ou une invite de commandes ou PowerShell sous Windows.
 Si ce n'est pas le cas, il va falloir tout d'abord vous renseigner sur ces applications pour pouvoir comprendre la suite des exemples et descriptions du livre.

book/01-introduction/sections/first-time-setup.asc

@@ -50,7 +50,7 @@ $ git config --global core.editor emacs
 
 [WARNING]
 ====
-Vim et Emacs sont des éditeurs de texte populaires chez les développeurs sur les systèmes à base Unix tels que Linux et Mac.
+Vim et Emacs sont des éditeurs de texte populaires chez les développeurs sur les systèmes à base Unix tels que Linux et macOS.
 Si vous n'êtes habitué à aucun de ces deux éditeurs ou utilisez un système Windows, il se peut que vous deviez chercher les instructions pour renseigner votre éditeur favori.
 Si vous ne renseignez pas un éditeur et ne connaissez pas Vim ou Emacs, vous risquez fort d'avoir des surprises lorsqu'ils démarreront.
 ====

book/04-git-server/sections/generating-ssh-key.asc

@@ -19,7 +19,7 @@ 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`.
 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/Mac et MSysGit pour Windows :
+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 :
 
 [source,console]
 ----

book/04-git-server/sections/git-on-a-server.asc

@@ -5,7 +5,7 @@ Nous allons à présent traiter de la configuration d'un service Git gérant ces
 
 [NOTE]
 ====
-Les commandes et étapes décrites ci-après s'appliquent à des installations simplifiées sur un serveur à base de Linux, bien qu'il soit aussi possible de faire fonctionner ces services sur des serveurs Mac ou Windows.
+Les commandes et étapes décrites ci-après s'appliquent à des installations simplifiées sur un serveur à base de Linux, bien qu'il soit aussi possible de faire fonctionner ces services sur des serveurs macOS ou Windows.
 La mise en place effective d'un serveur en production au sein d'une infrastructure englobera vraisemblablement des différences dans les mesures de sécurité et les outils système, mais ceci devrait permettre de se faire une idée générale des besoins.
 ====
 

book/08-customizing-git/sections/attributes.asc

@@ -17,7 +17,7 @@ Nous détaillerons comment indiquer à Git l'un et l'autre.
 ==== Identification des fichiers binaires
 
 Certains fichiers ressemblent à des fichiers texte mais doivent en tout état de cause être traités comme des fichiers binaires.
-Par exemple, les projets Xcode sous Mac contiennent un fichier finissant en `.pbxproj`, qui est en fait un jeu de données JSON (format de données en texte JavaScript) enregistré par l'application EDI pour y sauver les réglages entre autres de compilation.
+Par exemple, les projets Xcode sous macOS contiennent un fichier finissant en `.pbxproj`, qui est en fait un jeu de données JSON (format de données en texte JavaScript) enregistré par l'application EDI pour y sauver les réglages entre autres de compilation.
 Bien que ce soit techniquement un fichier texte en ASCII, il n'y a aucun intérêt à le gérer comme tel parce que c'est en fait une mini base de données.
 Il est impossible de fusionner les contenus si deux utilisateurs le modifient et les calculs de différence par défaut sont inutiles.
 Ce fichier n'est destiné qu'à être manipulé par un programme.

book/08-customizing-git/sections/config.asc

@@ -144,7 +144,7 @@ $ git tag -s <nom-étiquette>
 Comme décrit dans <<ch02-git-basics#s_ignoring>>, vous pouvez ajouter des patrons dans le fichier `.gitignore` de votre projet pour indiquer à Git de ne pas considérer certains fichiers comme non suivis ou pour éviter de les indexer lorsque vous lancez `git add` sur eux.
 
 Mais vous pouvez souhaiter dans quelques cas ignorer certains fichiers dans tous vos dépôts.
-Si votre ordinateur utilise Mac OS X, vous connaissez certainement les fichiers `.DS_Store`.
+Si votre ordinateur utilise macOS, vous connaissez certainement les fichiers `.DS_Store`.
 Si votre éditeur préféré est Emacs ou Vim, vous connaissez sûrement aussi les fichiers qui se terminent par `~` ou `.swp`.
 
 Cette option vous permet d'écrire un fichier `.gitignore` global.
@@ -244,12 +244,12 @@ Vous pouvez aussi sélectionner un outil graphique pour la fusion et la résolut
 Je démontrerai le paramétrage avec Perforce Merge Tool (P4Merge) pour visualiser vos différences et résoudre vos fusions parce que c'est un outil graphique agréable et gratuit.
 
 Si vous voulez l'essayer, P4Merge fonctionne sur tous les principaux systèmes d'exploitation.
-Dans cet exemple, je vais utiliser la forme des chemins usitée sur Mac et Linux.
+Dans cet exemple, je vais utiliser la forme des chemins usitée sur macOS et Linux.
 Pour Windows, vous devrez changer `/usr/local/bin` en un chemin d'exécution d'un programme de votre environnement.
 
 Pour commencer, téléchargez P4Merge depuis http://www.perforce.com/downloads/Perforce/[].
 Ensuite, il faudra mettre en place un script d'enrobage pour lancer les commandes.
-Je vais utiliser le chemin Mac pour l'exécutable ; dans d'autres systèmes, il résidera où votre binaire `p4merge` a été installé.
+Je vais utiliser le chemin macOS pour l'exécutable ; dans d'autres systèmes, il résidera où votre binaire `p4merge` a été installé.
 Créez un script enveloppe nommé `extMerge` qui appelle votre binaire avec tous les arguments fournis :
 
 [source,console]
@@ -389,7 +389,7 @@ Git dispose de quelques options de configuration pour traiter ces problèmes.
 
 (((crlf)))(((fins de ligne)))
 Si vous programmez vous-même sous Windows ou si vous utilisez un autre système d'exploitation mais devez travailler avec des personnes travaillant sous Windows, vous rencontrerez à un moment ou à un autre des problèmes de caractères de fin de ligne.
-Ceci est dû au fait que Windows utilise pour marquer les fins de ligne dans ses fichiers un caractère « retour chariot » (_carriage return_, CR) suivi d'un caractère « saut de ligne » (_line feed_, LF), tandis que Mac et Linux utilisent seulement le caractère « saut de ligne ».
+Ceci est dû au fait que Windows utilise pour marquer les fins de ligne dans ses fichiers un caractère « retour chariot » (_carriage return_, CR) suivi d'un caractère « saut de ligne » (_line feed_, LF), tandis que macOS et Linux utilisent seulement le caractère « saut de ligne ».
 C'est un cas subtil mais incroyablement ennuyeux de problème généré par la collaboration inter plate-forme.
 
 Git peut gérer ce cas en convertissant automatiquement les fins de ligne CRLF en LF lorsque vous validez, et inversement lorsqu'il extrait des fichiers sur votre système.
@@ -402,7 +402,7 @@ Git convertira les fins de ligne de LF en CRLF lorsque vous extrairez votre code
 $ git config --global core.autocrlf true
 ----
 
-Si vous utilisez un système Linux ou Mac qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers.
+Si vous utilisez un système Linux ou macOS qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers.
 Cependant, si un fichier contenant des CRLF est accidentellement introduit en gestion de versions, vous souhaitez que Git le corrige.
 Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais pas dans l'autre sens en fixant `core.autocrlf` à `input` :
 
@@ -411,7 +411,7 @@ Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais p
 $ git config --global core.autocrlf input
 ----
 
-Ce réglage devrait donner des fins de ligne en CRLF lors d'extraction sous Windows mais en LF sous Mac et Linux et dans le dépôt.
+Ce réglage devrait donner des fins de ligne en CRLF lors d'extraction sous Windows mais en LF sous macOS et Linux et dans le dépôt.
 
 Si vous êtes un programmeur Windows gérant un projet spécifique à Windows, vous pouvez désactiver cette fonctionnalité et forcer l'enregistrement des « retour chariot » dans le dépôt en réglant la valeur du paramètre à `false` :
 

book/A-git-in-other-environments/sections/guis.asc

@@ -67,15 +67,15 @@ Ensuite, vous pouvez simplement indexer ou désindexer certaines modifications,
 `gitk` et `git-gui` sont des exemples d'outils orientés tâche.
 Chacun est taillé pour un objectif spécifique (visualiser l'historique et créer des _commits_, respectivement) en omettant certaines fonctionnalités non-nécessaires à cette tâche.
 
-=== GitHub pour Mac et Windows
+=== GitHub pour macOS et Windows
 
-(((GitHub, pour Mac)))(((GitHub, pour Windows)))
-GitHub a créé deux clients Git orientés flux de travail : un pour Windows et un pour Mac.
+(((GitHub, pour macOS)))(((GitHub, pour Windows)))
+GitHub a créé deux clients Git orientés flux de travail : un pour Windows et un pour macOS.
 Ces clients sont un bon exemple d'outils orientés flux de travail — plutôt que d'exposer _toutes_ les fonctionnalités de Git, ils se focalisent sur un sous-ensemble sélectionné de fonctions couramment utilisées qui s'accordent.
 Ils ressemblent à ceci :
 
-.GitHub pour Mac.
-image::images/github_mac.png[GitHub pour Mac.]
+.GitHub pour macOS.
+image::images/github_mac.png[GitHub pour macOS.]
 
 .GitHub pour Windows.
 image::images/github_win.png[GitHub pour Windows.]
@@ -85,7 +85,7 @@ Nous n'allons pas explorer en profondeur ces outils (ils ont leur propre documen
 
 * Sur la gauche, il y a la liste des dépôts que le client suit ; vous pouvez ajouter un dépôt (soit en le clonant, soit en l'attachant localement) en cliquant sur l’icône « + » en haut de la zone.
 * Au centre, il y a la zone d'entrée de _commit_ qui vous permet d'entrer un message de validation et de sélectionner les fichiers qui devraient être inclus.
-  Sous Windows, l'historique de validation est affiché directement en dessous ; sous Mac, c'est un onglet séparé.
+  Sous Windows, l'historique de validation est affiché directement en dessous ; sous macOS, c'est un onglet séparé.
 * À droite, il y a une vue de diff qui montre ce qui a changé dans votre répertoire de travail ou les modifications qui ont été incluses dans le _commit_ sélectionné.
 * La dernière chose à noter est le bouton « Sync » en haut à droite qui est le moyen principal d'interagir via le réseau.
 
@@ -97,7 +97,7 @@ Bien qu'ils soient pensés pour mettre en lumière le service et la méthode de
 
 ==== Installation
 
-GitHub pour Windows peut être téléchargé depuis https://windows.github.com[] et GitHub pour Mac depuis https://mac.github.com[].
+GitHub pour Windows peut être téléchargé depuis https://windows.github.com[] et GitHub pour macOS depuis https://mac.github.com[].
 Quand les applications sont lancées pour la première fois, elles vous guident à travers le paramétrage initial de Git, tel que la configuration de votre nom et de votre adresse de courriel, et toutes deux définissent un paramétrage par défaut sans danger concernant différentes options de configuration telles que les caches d'identification et le comportement pour les fins de ligne.
 
 Les deux applications sont « permanentes » — les mises à jour sont téléchargées et appliquées en tâche de fond pendant que l'application est ouverte.
@@ -115,10 +115,10 @@ La manière de travailler avec cet outil est quelques fois appelée le « _GitH
 Nous traitons ceci plus en détail dans <<ch06-github#s_github_flow>>, mais l'esprit général est que a) vous validerez vos modifications dans une branche et b) vous synchroniserez avec un dépôt distant assez régulièrement.
 
 La gestion de branche est un des domaines pour lesquels les deux outils divergent.
-Sous Mac, il y a un bouton en haut de la fenêtre pour créer de nouvelles branches :
+Sous macOS, il y a un bouton en haut de la fenêtre pour créer de nouvelles branches :
 
-.Le bouton « _Create Branch_ » sous Mac.
-image::images/branch_widget_mac.png[Le bouton « _Create Branch_ » sous Mac.]
+.Le bouton « _Create Branch_ » sous macOS.
+image::images/branch_widget_mac.png[Le bouton « _Create Branch_ » sous macOS.]
 
 Sous Windows, cela se fait en tapant le nom de la branche dans la zone de saisie de bascule de branche :