Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue84:c_c [2014/09/19 16:28] – [2] frangi
+++ issue84:c_c [2014/09/26 19:16] (Version actuelle) – [3] auntiee
@@ Ligne 14: / Ligne 14: @@
 **
-Au début du mois, j'ai reçu le courriel d'un lecteur de Command & Conquer, me demandant d'écrire un article sur l'utilisation de Git; en particulier sur des choses comme ce qu'est un « fork » (branche), ce que veut dire « pulling » (télécharger), et ce qu'est exactement un « commit » (validation). Il a également poursuivi sur les erreurs d'« automerge » et comment les corriger.  Je ferai de mon mieux pour parler de chacun de ces points en particulier. Cependant, comme la plupart de mes expériences avec Git est faite via Github, qui offre quelques fonctionnalités supplémentaires sur son site web et qui n'est pas l'expérience « commune » de Git, il peut y avoir certains aspects de mes explications qui ne s'appliquent pas à un serveur Git personnalisé.
+Au début du mois, j'ai reçu le courriel d'un lecteur de Command & Conquer, me demandant d'écrire un article sur l'utilisation de Git ; en particulier sur des choses comme ce qu'est un « fork » (fourche), ce que veut dire « pulling » (télécharger), et ce qu'est exactement un « commit » (validation). Il a également poursuivi sur les erreurs d'« automerge » et comment les corriger. Je ferai de mon mieux pour parler de chacun de ces points en particulier. Cependant, comme la plupart de mes expériences avec Git se sont faites via Github, qui propose quelques fonctionnalités supplémentaires sur le site web et qui n'est pas l'expérience « commune » de Git, il peut y avoir certains aspects de mes explications qui ne s'appliquent pas à un serveur Git personnalisé.
 Informations générales
-Dans Git, vous pouvez créer un dépôt [repository] (qui contient généralement une branche maitre). Mais un dépôt peut contenir plusieurs branches (comme stable, testing et development). Un dépôt peut être créé par n'importe qui, et ceci se traduira par un dépôt local pour l'utilisateur qui le crée.
+Dans Git, vous pouvez créer un dépôt [repository] (qui contient généralement une branche maîtresse). Mais un dépôt peut contenir plusieurs branches (comme stable, testing et development). Le fork d'un dépôt peut être créé par n'importe qui, et ceci engendra un dépôt local pour l'utilisateur qui l'a créé.
 Une branche
-Une branche pourrait essentiellement être considérée comme une photo de votre projet à un certain moment. Certaines personnes préconisent d'attribuer une branche à tout changement, alors que certaines personnes gardent seulement une ou deux branches actives (tout en gardant la branche master de base pour toutes les futures branches). Par exemple: Si vous développez activement un navigateur Web, vous pouvez garder deux branches : stable et testing.
+Une branche pourrait essentiellement être considérée comme une photo de votre projet à un certain moment. Certaines personnes préconisent d'attribuer une branche à tout changement, alors que d'autres personnes gardent seulement une ou deux branches actives (tout en gardant la branche master comme base pour toutes les futures branches). Par exemple : si vous développez activement un navigateur Web, vous pouvez garder deux branches : stable et testing.
- • Stable contient le code source de votre dernière sortie officielle, qui est sans bug, espérons-le.
+ • Stable contient le code source de votre dernière sortie officielle, qui est, vous l'espérez, sans bug.
- • Pour continuer à avancer les développement pendant ce temps, vous pouvez créer aussi une branche appelée Testing, qui contient tout le nouveau code. Vous pouvez suivre les modifications, et obtenir la contribution de bêta-testeurs, afin de cheminer dans votre travail vers une nouvelle mise à jour stable. Une fois que vous atteignez un point dans le test qui est stable et fonctionne comme vous le souhaitez, vous allez ensuite mettre à jour ces changements dans la branche stable, et continuer à travailler sur les tests.
+ • Pour continuer à faire avancer le développement pendant ce temps, vous auriez aussi une branche appelée Testing, qui contient tout le nouveau code. Vous pouvez suivre les modifications et obtenir l'avis de bêta-testeurs, afin de progresser vers une nouvelle mise à jour stable. Une fois que vous avez atteint un stade dans les tests qui est stable et fonctionne comme vous le souhaitez, vous allez ensuite mettre ces changements dans la branche stable et continuer à travailler sur les tests.
 **
@@ Ligne 38: / Ligne 38: @@
 **
-Une fourche (Fork)
+Une fourche (fork)
-C'est quand un utilisateur voit un projet qu'il aime (ex: le projet de navigateur Web précédent), et qu'il pense: « Je pourrais faire mieux », ou « Je serais ravi d'aider à créer ceci ». Au lieu d'attribuer aux utilisateurs la possibilité de modifier le dépôt officiel et de ses branches, il serait mieux que l'utilisateur crée une fourche du projet. Vous pouvez l'imaginer comme une autoroute (le dépôt officiel), avec des sorties pour chaque utilisateur qui y contribue, conduisant à leurs copies locales. C'est utile, car ça évite de dévier l'objectif principal du projet original; si vous voulez redéfinir le but du code d'un navigateur Web pour créer une galerie d'images, vous pouvez le « forker » normalement, et faire les changements que vous souhaitez.
+C'est quand un utilisateur voit un projet qui lui plaît (ex : le projet de navigateur Web précédent), et qu'il pense : « Je pourrais faire mieux », ou « Je serais ravi d'aider à créer ceci. » Au lieu d'attribuer aux utilisateurs la possibilité de modifier le dépôt officiel et ses branches, il serait mieux que l'utilisateur crée une fourche du projet. Vous pouvez l'imaginer comme une autoroute (le dépôt officiel), avec des sorties pour chaque utilisateur qui y contribue, conduisant à leurs exemplaires locaux. C'est utile, car ça évite de dévier l'objectif principal du projet original ; si vous voulez redéfinir le but du code d'un navigateur Web pour créer une galerie d'images, vous pouvez le « forker » normalement et faire les changements que vous souhaitez.
-Certains d'entre vous peuvent se demander comment ces fourches peuvent contribuer à un projet, s'il s'agit essentiellement d'une copie. Ceci est géré par quelque chose s'appellant une fusion (expliqué ci-dessous).
+Certains d'entre vous peuvent se demander comment ces fourches peuvent contribuer à un projet, s'il s'agit essentiellement d'une copie. Ceci est géré par quelque chose qui s'appelle une fusion (expliquée ci-dessous).
-Une validation (Commit)
+Une validation (commit)
-Avant de discuter de ce qu'est la fusion, nous devons d'abord expliquer les validations. Chaque fois que vous modifiez un fichier dans votre répertoire local, vous pouvez choisir de l'enregistrer comme une validation (c'est à dire un changement), donner une brève explication, puis le renvoyer (upload) vers votre dépôt distant, de sorte que les mises à jour peuvent être  propagées à travers toutes les fourches basées sur ce référentiel, et donner les versions les plus récentes à toutes les nouvelles fourches.
+Avant de discuter de ce qu'est la fusion, nous devons d'abord expliquer les validations. Chaque fois que vous modifiez un fichier dans votre répertoire local, vous pouvez choisir de l'enregistrer comme une validation (c'est-à-dire un changement), donner une brève explication, puis le renvoyer (upload) vers votre dépôt distant, de sorte que les mises à jour peuvent être propagées à travers toutes les fourches basées sur ce référentiel, et donner les versions les plus récentes à toutes les nouvelles fourches.
 ===== 2 =====
@@ Ligne 57: / Ligne 57: @@
 Une fusion (merge)
-Une fois que vous avez validé les modifications dans votre dépôt distant, et que vous croyez que cela aiderait le projet d'origine, vous pouvez envoyer une demande de fusion pour cette validation (ou série de validations). Cela envoie alors une notification au propriétaire du dépôt d'origine, qui comprend des informations sur la propagation, affiche une comparaison de l'avant et après, et indique les conflits (si, par exemple, vous avez déjà changé légèrement une ligne de code, et que le patch ne peut donc plus la « trouver »). Dites que vous écrivez un patch pour le navigateur web qui permet aux utilisateurs de définir leurs propres CSS (feuilles de style en cascade), afin de donner un style à leur navigateur et aux pages web selon leurs propres spécifications. Pour ce faire, vous avez modifié une boucle for qui scrute tous les fichiers dans des dossiers appelés « config » et « données », pour inclure le dossier « styles ». Mais en amont (le projet initial) a changé le nom du dossier de config pour « conf ». Cela signifie que la boucle semble différente de celle attendue pour la demande de fusion, ce qui soulève un conflit avec le développement d'origine. Ils peuvent alors choisir de le résoudre, ou de l'ignorer.
+Une fois que vous avez validé les modifications dans votre dépôt distant et que vous croyez que cela aiderait le projet d'origine, vous pouvez envoyer une demande de fusion pour cette validation (ou série de validations). Cela envoie alors une notification au propriétaire du dépôt d'origine, qui comprend des informations sur la validation, affiche une comparaison de l'avant et après, et indique les conflits (si, par exemple, vous avez déjà changé légèrement une ligne de code et que le patch ne peut donc plus la « trouver »). Supposons que vous écrivez un patch pour le navigateur web qui permet aux utilisateurs de définir leurs propres CSS (feuilles de style en cascade), afin de donner un style à leur navigateur et aux pages Web selon leurs propres spécifications. Pour ce faire, vous avez modifié une boucle « for » qui scrute tous les fichiers dans des dossiers appelés « config » et « données », pour inclure le dossier « styles ». Mais le projet initial en amont a remplacé le nom du dossier config par « conf ». Cela signifie que la boucle semble différente de ce qui était attendu par la demande de fusion, ce qui crée un conflit avec le développeur d'origine. Ils peuvent alors choisir de le résoudre ou de l'ignorer.
 **
@@ Ligne 80: / Ligne 80: @@
 Résolution des conflits
-Si vous rencontrez des conflits avec les fusions (deux personnes modifient le même fichier, ou une personne l'édite et une autre le supprime), vous aurez généralement besoin de les résoudre manuellement.  Pour le faire, vous devez exécuter :
+Si vous rencontrez des conflits avec les fusions (deux personnes modifient le même fichier, ou une personne l'édite et une autre le supprime), vous aurez généralement besoin de les résoudre manuellement. Pour le faire, vous devez exécuter :
- git status
+git status
-Cela vous donnera des informations sur les fichiers en conflit, et vous donnera les instructions pour indiquer quand vous avez résolu le conflit.
+Cela vous donnera des informations sur les fichiers en conflit ainsi que des instructions pour indiquer quand vous aurez résolu le conflit.
-Examiner en détail le conflit est aussi simple que d'ouvrir le fichier après l'échec de la fusion, le fichier doit contenir un bloc qui ressemble à quelque chose comme:
+Examiner en détail le conflit est aussi simple que d'ouvrir le fichier après l'échec de la fusion, le fichier doit contenir un bloc qui ressemble à quelque chose comme :
 Le nombre de planètes est
@@ Ligne 107: / Ligne 107: @@
 **
-La série de caractères « inférieur à » et « supérieur à » marque la zone du conflit, et la ligne de caractères « égale » marque les deux modifications différentes. Branch-a réfère à dans quelle branche ce conflit se produit. Pour résoudre ce problème, il suffit de supprimer les marqueurs de conflit (inférieur à, supérieur à, et égale), et supprimer soit votre modification soit la modification de l'autre personne, ou de remplacer l'ensemble du conflit par une nouvelle édition (c'est à dire quelque chose qui contient à la fois les deux modifications). Une fois les marqueurs disparus, vous pouvez aller l'ajouter à la liste des validations, et le pousser vers le dépôt distant.
+La série de caractères « inférieur à » et « supérieur à » marque la zone du conflit et la ligne de caractères « égal » sépare les deux modifications différentes. Branch-a indique la branche dans laquelle ce conflit se produit. Pour résoudre ce problème, il suffit de supprimer les marqueurs de conflit (inférieur à, supérieur à, et égal), et de supprimer aussi soit votre modification soit la modification de l'autre personne, ou de remplacer l'ensemble du conflit par une nouvelle édition (c'est-à-dire quelque chose qui contient à la fois les deux modifications). Une fois les marqueurs disparus, vous pouvez aller l'ajouter à la liste des validations et le « pousser » vers le dépôt distant.
-Dans le cas d'un conflit causé par quelqu'un ayant supprimé un fichier, vous pouvez le résoudre par l'une des deux manières suivantes:
+Dans le cas d'un conflit causé par la suppression d'un fichier, vous pouvez le résoudre de l'une des deux manières suivantes :
- • Ajouter le fichier à nouveau, puis valider (ce qui annule essentiellement la validation où il a été supprimé).
+ • Ajouter le fichier à nouveau, puis valider (ce qui annule la validation où il a été supprimé).
  • Supprimer le fichier avec git rm, puis valider à nouveau le changement.
-Qu'est-ce qu'un téléchargement (pull)?
+Qu'est-ce qu'un téléchargement (pull) ?
-Un téléchargement est une combinaison de git-fetch et git-merge. Fetch (aller chercher) demande essentiellement les changements dans le dépôt, et télécharge les validations en local. Merge tente ensuite d'intégrer les nouvelles informations dans votre copie existante du dépôt. Au lieu d'avoir à faire ces choses une par une, Git propose à la place la commande de téléchargement pull, qui tente automatiquement de fusionner tout ce qu'elle va aller chercher.
+Un téléchargement est une combinaison de git-fetch et git-merge. Fetch (aller chercher) demande essentiellement les changements dans le dépôt et télécharge les validations en local. Merge tente ensuite d'intégrer les nouvelles informations dans votre copie existante du dépôt. Au lieu d'avoir à faire ces choses une à une, Git propose à la place la commande de téléchargement pull, qui tente automatiquement de fusionner tout ce qu'elle va aller chercher.
 **
@@ Ligne 137: / Ligne 137: @@
 Quoi, aucun code ?!
-Ce mois-ci, j'ai décidé de me concentrer sur l'explication de la terminologie et d'illustrer certains aspects de Git. Le mois prochain, je vous amènerai à travers une série d'exemples de paramétrage d'un dépôt git, de clonage, de modification des branches, de création d'une validation et de résolution d'un conflit. Pour ceux qui ne veulent pas attendre un mois, il y a des liens vers des informations dans la section de lecture ci-dessous.
+Ce mois-ci, j'ai décidé de me concentrer sur l'explication de la terminologie et d'illustrer certains aspects de Git. Le mois prochain, je vous détaillerai une série d'exemples de paramétrage d'un dépôt git, de clonage, de modification des branches, de création d'une validation et de résolution d'un conflit. Pour ceux qui ne veulent pas attendre un mois, il y a des liens vers des informations dans la section Pour aller plus loin, ci-dessous.
-Espérons que cet article a contribué à éclairer un peu la terminologie de Git. Si vous avez des questions, des commentaires, des recommandations ou suggestions, contactez moi à lswest34+fcm@gmail.com, vous êtes les bienvenus.
+Espérons que cet article a contribué à éclairer un peu la terminologie de Git. Si vous avez des questions, des commentaires, des recommandations ou suggestions, n'hésitez pas à me contacter à lswest34+fcm@gmail.com.
+Pour aller plus loin
-Further Reading
+http://git-scm.com/doc – Documentation Git.
-http://git-scm.com/doc – Documentation Git
-http://githowto.com/ - Site Web de manuels de Git
+http://githowto.com/ - Site Web de tutoriels de Git.
-https://help.github.com/ - Github offre des explications bien écrites pour les usages typiques de Git, et explique tout aussi bien les fonctionnalités propres à Github.
+https://help.github.com/ - Github offre des explications bien écrites pour les usages typiques de Git et explique tout aussi bien les fonctionnalités propres à Github.