Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
===== 1 =====
**
Earlier this month, I received an email from a reader of Command & Conquer, asking me to write an article on using Git – specifically things such as what a fork is, what pulling is, and what exactly a commit is. He also followed it up asking about automerge errors and how to fix them. I will do my best to cover each of these points in particular. However, as most of my experiences with Git are via Github, which offers some extra functionality on their website that isn't the “vanilla” Git experience, there may be some aspects of my explanations that do not apply to a custom git server.

General Information

In Git, you can create a repository (which typically contains a master branch). However, a repository can contain multiple branches – such as stable, testing, and development. A repository can be forked by anyone, and that will result in a local repository for the user who forked it.

A Branch

A branch could essentially be considered a snapshot of your project at a certain point. Some people advocate assigning every change to a branch, while some people keep only one or two active branches (while keeping the master branch as a basis for any future branches). Via example: If you are actively developing a web browser, you could keep two branches – stable and testing.
• Stable contains the source code for your last official release – which is hopefully bug-free.
• In order to keep development moving along, you would also have a branch called Testing, which contains all the bleeding edge code. You can track your changes, and get input from beta testers, in order to work your way towards a new update to stable. Once you reach a point in testing that's stable and running as you'd like it, you would then update those changes to stable, and keep working on testing.
**

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 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 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, vous l'espérez, sans bug.
 • 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.

**
A Fork

Is when a user sees a project they like (i.e. the web browser project from my last example), and think to themselves “I could do this better”, or “I'd love to help create this”. Instead of assigning users the ability to edit the official repository and its branches, the user would instead create a fork of the project. You can imagine it as a highway (the official repository), with turn-offs for every user who is contributing to it, which leads to their local copies. This is useful, as it prevents the main goal of the original project from shifting – if you want to re-purpose the code for a web browser to create an image gallery, you can fork it as normal, and make any changes you'd like.

Some of you may be wondering how these forks can help contribute anything to a project, if it's essentially a copy. This is handled by something called a merge (explained below).

A Commit

Before we discuss what a merge is, we should first explain commits. Whenever you change a file in your local repository, you can choose to save it as a commit (i.e. a change), give it a brief explanation, and then push (upload) it back to your remote repository, so that the updates can be propagated through all forks based off that repository, as well as give the most recent versions to any new forks.
**

Une fourche (fork)

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 qui s'appelle une fusion (expliquée ci-dessous).

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.

===== 2 =====
**
A Merge

Once you've committed changes to your remote repository, and believe that it would help the original project, you can then send a merge request for that commit (or a series of commits). This then sends a notification to the owner of the original repository, and includes information on the commit, displays a comparison of the before/after, and indicates any conflicts (if, for example, you've already changed the line of code slightly, and the patch can therefore no longer “find” it). Say you write a patch for the web browser that allows users to define their own CSS (cascading style sheets), in order to style their browser and website views to their specifications. To do so, you adjusted a for-loop that runs over all files within folders called “config” and “data”, to include the folder “styles”. However, upstream (the original project), has changed the name of the config folder to “conf”. This means that the loop looks different than expected to the merge request – which raises a conflict with the original developer. They can then choose to resolve it, or ignore it.
**

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

**
Resolving Conflicts

If you run into conflicts with merges (i.e. two people edit the same file, or one person edits it and another deletes it), you will generally need to resolve it manually. To go about doing this, you would run

git status

This will give you information about what files are in conflict, as well as give you instructions to indicate when you have solved the conflict.

Viewing the actual conflict is as simple as opening the file after the merge has failed – the file should contain a block that looks something like:

the number of planets are
<<<<<<< HEAD
nine
=======
eight
>>>>>>> branch-a
**

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 :

git status

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 :

Le nombre de planètes est
<<<<<<< HEAD
neuf
=======
huit
>>>>>>> branch-a
===== 3 =====
**
The series of less than/greater than signs mark the area of the conflict, and the line of equals signs mark the two different changes. Branch-a refers to which branch this conflict is occurring in. To resolve this, simply delete the conflict markers (less than, greater than, and the equals signs), as well as deleting either your change, the other person's change, or replacing the entirety of the conflict with a new edit (i.e. something that contains both edits). Once the markers are gone, you can go about adding it to the commit list, and pushing it to the remote repository.

In the case of a conflict caused by someone deleting a file, you can resolve it in one of two ways:
• Adding the file back, and then committing it (which essentially overrules the commit where it was deleted).
• Deleting the file with git rm, and then committing the change again.

What is a Pull?

A pull is a combination of git-fetch and git-merge. Fetch essentially asks for any changes to the repository, and downloads the commits. Merge then tries to integrate the new information into your existing copy of the repository. Instead of having to do these things one by one, Git instead offers the pull command, which automatically attempts to merge anything downloaded via fetch.
**

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 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 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) ?

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.

**
What, no code?!

This month, I decided I would focus on explaining the terminology and illustrate some aspects of Git. Next month, I will run you through a series of examples for setting up a git repository, cloning it, editing the branches, creating a commit and resolving a conflict. For anyone who does not want to wait a month, there are links to information in the further reading section below.

Hopefully this article has helped to shine some light on the terminology of Git. If you have questions, comments, recommendations, or suggestions, you are welcome to email me at lswest34+fcm@gmail.com.


Further Reading

http://git-scm.com/doc – Git Documentation

http://githowto.com/ - Git Howto website

https://help.github.com/ - Github offers some well-written explanations for the typical uses of Git, as well as explaining Github-specific features well.
**

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 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, n'hésitez pas à me contacter à lswest34+fcm@gmail.com.

Pour aller plus loin

http://git-scm.com/doc – Documentation 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.