Introduction au contrôle de version Git

Important

Un guide plus détaillé sur Git est disponible sur le site Web de Git.

Git est un système de gestion de versions distribuée (VCS) créé par Linus Torvalds, également connu pour la création et la maintenance du noyau Linux. Un système de gestion de versions est un système de suivi des modifications de code pour les développeurs. Les avantages du système de gestion de versions Git sont les suivants:

  • Il sépare les environnements de test en branches

  • Il offre la possibilité de naviguer vers un commit particulier sans supprimer l’historique

  • Il offre la capacité à gérer les commits de différentes manières, y compris en les combinant

  • Et comporte diverses autres fonctionnalités, voir ici

Conditions préalables

Important

Ce didacticiel utilise le système d’exploitation Windows

Vous devez télécharger et installer Git à partir des liens suivants:

Note

Vous devrez peut-être ajouter Git à votre chemin de répertoire

Le vocabulaire Git

Git s’articule autour de plusieurs commandes principales: (N.D.T. La commande en anglais est suivie de sa traduction en français entre parenthèses)

  • Repository (Référentiel de données): la structure des données de votre code, y compris un dossier .git dans le répertoire racine

  • Commit (Validé): un état enregistré particulier du référentiel, cela inclut tous les fichiers et ajouts

  • Branch (Branche): un moyen de séparer les différents Commits, ayant une histoire unique. Ceci est principalement utilisé pour séparer le développement et les branches stables.

  • Push (Pousser): mettez à jour le référentiel distant avec vos modifications locales

  • Pull (Tirer): mettez à jour votre référentiel local avec les modifications à distance

  • Clone (Cloner): récupération d’une copie locale d’un référentiel pour fins de le modifier

  • Fork (Fourche): duplication d’un référentiel préexistant à modifier et à comparer avec l’original

  • Fusion: combinant divers changements de différentes branches / validations / fourchettes en un seul historique

Le Référentiel de données

Un référentiel Git est une structure de données contenant la structure, l’historique et les fichiers d’un projet.

Les référentiels Git comprennent généralement:

  • Un dossier .git. Ce dossier contient les différentes informations sur le référentiel.

  • Un fichier .gitignore. Ce fichier contient les fichiers ou répertoires que vous ne voulez pas inclure lors de la validation.

  • Fichiers et dossiers. Il s’agit du contenu principal du référentiel.

Création du Référentiel de données

Vous pouvez stocker le repertoire localement ou dans un serveur distant. Ce serveur distant étant le cloud, ou peut-être un autre support de stockage qui héberge votre repertoire. GitHub est un service d’hébergement gratuit populaire. De nombreux développeurs l’utilisent, et c’est ce que ce tutoriel va utiliser.

Note

Il existe différents fournisseurs qui peuvent héberger des dépôts. Gitlab et Bitbucket sont quelques alternatives à Github.

Création d’un compte GitHub

Allez-y et créez un compte GitHub en visitant le site Web et en suivant les propres invites d’écran.

How to create a new GitHub account.

Création locale

Après avoir créé et vérifié votre compte, vous irez ensuite visiter la page d’accueil. Cela ressemblera à l’image montrée ci-dessous.

Showing the newly created account homepage.

Cliquez sur l’icône « plus », ou + en haut à droite.

Location of the plus button.

Cliquez ensuite sur « New Repository »

Creating a new menu after clicking the plus button.

Remplissez les informations appropriées, puis cliquez sur « Create repository »

Showing the "create repository" button

Vous devriez voir un écran similaire à celui-ci

The quick setup screen after creating a repository.

Note

The keyboard shortcut Ctrl+~ can be used to open a terminal in Visual Studio Code.

Vous aimerez à ce point-ci ouvrir une fenêtre PowerShell et accéder à votre répertoire de projets. Un excellent tutoriel sur PowerShell peut être trouvé ici. Veuillez utiliser votre moteur de recherche afin de trouver la façon d’ouvrir un terminal sur les systèmes d’exploitation alternatifs.

An empty powershell window.

If a directory is empty, a file needs to be created in order for git to have something to track. In the below Empty Directory example, we created a file called README.md with the contents of # Example Repo. For FRC® Robot projects, the below Existing Project commands should be run in the root of a project created by the VS Code WPILib Project Creator. More details on the various commands can be found in the subsequent sections.

Note

Remplacez le chemin d’accès "C:\Users\ExampleUser9007\Documents\Example Folder" par celui dans lequel vous souhaitez créer le repo, et remplacez l’URL distante https://github.com/ExampleUser9007/ExampleRepo.git par l’URL du repo que vous avez créé dans les étapes précédentes.

> cd "C:\Users\ExampleUser9007\Documents\Example Folder"
> git init
Initialized empty Git repository in C:/Users/ExampleUser9007/Documents/Example Folder/.git/
> echo "# ExampleRepo" >> README.md
> git add README.md
> git commit -m "First commit"
[main (root-commit) fafafa] First commit
 1 file changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README.md
> git remote add origin https://github.com/ExampleUser9007/ExampleRepo.git
> git push -u origin main

Les Commits, ou Validés

Les référentiels sont principalement composés de Commits. Ceux-ci sont des états enregistrés ou des versions de code.

Dans l’exemple précédent, nous avons créé un fichier appelé README.md. Ouvrez ce fichier dans votre éditeur de texte préféré et modifiez-en quelques lignes. Après avoir joué avec le fichier pendant un moment, il suffit d’enregistrer et de fermer. Accédez à PowerShell et tapez les commandes suivantes.

> git add README.md
> git commit -m "Adds a description to the repository"
[main bcbcbc] Adds a description to the repository
 1 file changed, 2 insertions(+), 0 deletions(-)
> git push

Note

La rédaction de bons messages explicatifs lors d’un Commit est un élément clé de la maintenance d’un projet qui est écrit par une équipe de programmeurs. Un guide sur l’écriture des messages de Commit peut être trouvé ici.

La commande Git Pull

Note

git fetch peut être utilisé lorsque l’utilisateur ne souhaite pas fusionner automatiquement dans la branche de travail actuelle

Cette commande récupère l’historique ou valide à partir du référentiel distant. Lorsque la télécommande contient du travail que vous n’avez pas, elle tentera de fusionner automatiquement. Voir Le fusionnement (Merge).

Run: git pull

La commande Git Add

Cette commande ajoute un ou plusieurs fichiers sélectionnés à un Commit. Ceci va valider chaque fichier/dossier , sauf ceux qui sont exclus via gitignore.

Exécutez: git add FILENAME.txt où FILENAME.txt est le nom et l’extension du fichier à ajouter à un Commit. Exécuter: git add . Ceci ajoutera tous les fichiers non suivis et non exclus lorsque cette commande est exécutée à partir du répertoire « root », ou racine du référentiel de données.

La commande Git Commit

Cette commande crée le Commit et le stocke localement. Cela enregistre l’état du projet et l’ajoute à l’historique des référentiels.

Exécuter: git commit -m "type message here"

La commande Git Push

Téléchargez (Push) vos modifications locales sur le « Cloud » (à distance)

Exécuter: git push

Les Branches

Les branches sont similaires au concept de « mondes parallèles », mais appliqué à Git. Ils démarrent de la même façon, et ensuite peuvent « diverger » ou se « ramifier » sur différents chemins. Considérez le flux de contrôle Git comme similaire a cet exemple.

A branch workflow state diagram.

Dans l’exemple ci-dessus, la branche principale a été fusionnée (ou dupliquée) avec la branche dévolue à la Fonctionnalité 1 et quelqu’un a dupliqué la branche pour en avoir une copie locale. Ensuite, une personne fait un commit (ou téléchargé) de ses modifications, les fusionnant avec la branche de Fonctionnalité 1 de la branche. Vous « fusionnez » les changements d’une branche à l’autre.

Création d’une branche

Exécutez: git branch branch-name où branch-name est le nom de la branche à créer. Le nouvel historique de branche sera créé à partir de la branche active actuelle.

Entrer dans une branche

Une fois qu’une branche est créée, vous devez ensuite entrer dans la branche.

Exécutez: git checkout branch-name où branch-name est la branche qui a été créée précédemment.

Le fusionnement (Merge)

Dans les scénarios où vous souhaitez copier l’historique d’une branche dans une autre, vous pouvez les fusionner. Une fusion est effectuée en appelant git merge branch-name avec branch-name étant le nom de la branche à partir de laquelle fusionner. Il est automatiquement fusionné dans la branche active actuelle.

Il est courant qu’un référentiel distant contienne un travail (historique) que vous n’avez pas. Chaque fois que vous exécutez git pull, il tentera de fusionner automatiquement ces Commits. Cette fusion peut ressembler à ce qui suit.

A merge workflow state diagram.

Cependant, dans l’exemple ci-dessus, que se passe-t-il si le fichier 1 a été modifié par les deux branches FeatureA et FeatureB? C’est ce qu’on appelle un conflit de fusion. Un conflit de fusion peut être résolu en modifiant le fichier en conflit. Dans l’exemple, nous devons modifier le fichier 1 pour conserver l’historique ou les modifications souhaitées. Après que ceci est accompli, il suffit de rajouter, de faire un Commit, et ensuite un « Push » afin de pousser vos modifications.

Les réinitialisations (Resets)

Parfois, l’historique doit être réinitialisé ou un Commit doit être annulé. Cela peut se faire de plusieurs manières.

Revenir en arrière sur un Commit

Note

Vous ne pouvez pas annuler une fusion, car git ne sait pas quelle branche ou origine il doit choisir.

Pour revenir en arrière sur l’historique menant à un Commit, exécutez git revert commit-id. Les ID de validation peuvent être affichés à l’aide de la commande git log.

La commande de réinitialisation de la tête

Avertissement

Réinitialiser la tête est une commande dangereuse. Elle efface définitivement toute le travail que vous avez accompli, et qui n’a pas été validé (Commit). Vous êtes prévenus!

Exécutez: git reset --hard commit-id.

Fourches

Les fourches peuvent être traitées de la même manière que les branches. Vous pouvez fusionner le référentiel d’origine, (celui en amont, ou upstream) dans le référentiel fourché (celui d’origine).

Clonage d’un Dépôt existant

Dans la situation où un dépôt a déjà été créé et stocké dans un serveur distant, vous pouvez le cloner à l’aide

git clone https://github.com/myrepo.git

myrepo.git est remplacé par votre git repo. Si vous suivez cela, vous pouvez passer à :ref:commits <docs/software/basic-programming/git-getting-started:Commits>`.

Mettre à jour une fourche

  1. Ajoutez l’amont: git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

  2. Confirmez qu’il a été ajouté via: git remote -v

  3. Faire un « Fetch » sur les changements en amont: git fetch upstream

  4. Fusionnez les modifications dans la tête: git merge upstream/upstream-branch-name

Gitignore

Important

Il est extrêmement important que les équipes ne modifient pas le fichier .gitignore qui est intégré dans leur projet de robot. Cela peut conduire à un déploiement hors connexion qui ne fonctionne pas.

Un fichier .gitignore est couramment utilisé comme liste de fichiers à ne pas valider automatiquement avec git add. Tous les fichiers ou répertoires énumérés dans ce fichier ne seront pas validés. Ils ne s’afficheront pas non plus avec la commande git status.

Des informations supplémentaires peuvent être trouvées ici

Masquer un dossier

Ajoutez simplement une nouvelle ligne contenant le dossier à cacher, avec une barre oblique à la fin

EX: répertoire à exclure/

Masquer un fichier

Ajoutez une nouvelle ligne avec le nom du fichier à masquer, y compris tout répertoire précédant de la racine du référentiel.

EX: répertoire/fichier-à-cacher.txt

EX: file-to-hide2.txt

Information additionnelle

Un didacticiel beaucoup plus approfondi peut être trouvé sur le site officiel de git.

Un guide pour corriger les erreurs courantes se trouve dans le dépôt git flight rules