Git, c'est bien !

Git est un système de gestion de versions. Il permet de sauvegarder et de récupérer une version passée d'un fichier ou d'un projet complet. Git permet également de partager une modification.

Le but de ce document n'est pas d'être la bible de git. Elle existe déjà, elle est là. Le but est d'être un point d'entrée rapide sur le sujet, permettant au lecteur de trouver les points qu'il souhaite approfondir.

Git est organisé en dépôt. Chaque dépôt va contenir un projet avec son historique et les différentes évolutions en cours de développement.

Lorsque vous avez un dépôt pour travailler sur votre ordinateur, vous avez de visible le répertoire de travail. Dans ce répertoire, se cache un sous-répertoire nommé .git. Le répertoire .git contient toutes les informations de votre projet, tous ses fichiers et leur historique. Tant que vous ne détruisez pas - ou n’altérez pas - ce répertoire, vous pourrez récupérer votre projet.

Dans le répertoire de travail, chaque fichier peut avoir 3 états :

• Modifié : Cette version du fichier n'existe que dans votre répertoire de travail.
• Indexé : Le fichier a été ajouté à la zone d'index. Il est marqué pour faire partie de la prochaine version que vous créerez.
• Validé : La version de ce fichier fait partie de l'historique du projet.

À la fois pour sauvegarder son projet et pour travailler en équipe, il est courant d'avoir plusieurs dépôts d'un même projet. Un dépôt sera sur le PC de la personne qui travaille sur le projet, un second dépôt sur une _forge logicielle_ telle que : * Forjego * Gitea * Gitlab * Github

• 0) Installer git
• 1) Créer un dépôt ou récupérer un dépôt existant
• 2) Modifier le projet
• 3a) Ajouter les fichiers à la zone d'index
• 3b) Valider les modifications

Dans la pratique, les commandes de git, dans le terminal, sont assez simples à mémoriser et à utiliser. Cependant, presque chaque IDE dispose d'une gestion de git, que ce soit nativement ou par l'intermédiaire d'un plug-in.

Sous Linux, prenez la version dans votre distribution. Sur les dérivées de Debian :

apt get install git

Sous Windows, installez Git for windows

Sous Mac, lancez 'git' dans un terminal, s'il n'est pas installé, il vous demandera de le faire.

git init

Pour cloner un dépôt :

git clone <adresse du dépôt>

git status

La commande indique quelle branche est active, les fichiers modifiés, ceux ajoutés à l'index, ceux qui ne sont pas suivis.

git add <fichier>

git commit

La commande “git commit” valide les modifications présente dans l'index.

Ceux qui sont pressés utiliseront la commande :

git commit -a -m "<Description des modifications>"

Cette commande ajoute tous les fichiers modifiés à l'index et valide les modifications. Attention, cette commande ne tiendra pas compte des nouveaux fichiers.

Les tags, ou étiquettes en français, permettent d'identifier une version précise, statique, du projet. C'est le mécanisme à utiliser lors d'une livraison du logiciel ou pour identifier le code utilisé pour une opération spécifique - telle que l'homologation.

Comme les tags, les branches permettent d'identifier une version du projet. Mais cette version est dynamique. Si la branche est active, l'ajout d'une modification fait évoluer la branche. Dans un projet, il existe généralement une branche principale, main ou master. Les gros projets s'organisent en ayant une branche par fonctionnalité. Lorsque la fonctionnalité est prête, celle-ci est fusionnée avec la branche principale.

Sur un projet comme tel qu'un robot, deux ou trois branches sont suffisantes :

• La branche principale, contient le code testé et validé.
• La branche de test, contient le code qui a pu être testé.
• la branche de développement, contient le code non testé, pour ceux qui codent beaucoup avant de tester.

Les deux dernières branches pouvant n'en être qu'une…

L'utilisation d'une branche spécifique pour un développement se justifie lorsque ce développement est long et où le besoin de modifier le code “qui marche” peut se faire sentir avant que le développement soit terminé.

Dans le cadre de la coupe, vous développez une nouvelle stratégie, branche strat-v2. Vous n'êtes pas sûr que cette stratégie soit prête pour votre prochain match. Vous créez une branche pour votre nouvelle stratégie. En attendant, vous analysez votre précédent match et trouvez des corrections à apporter à la vieille stratégique. Vous pouvez éditer votre branche principale et continuer à travailler sur votre stratégie v2 en parallèle.

• Votre code
• Votre système de compilation (Makefile, cmake) si vous le personnalisez

• Les fichiers temporaires - tels que les sauvegardes automatiques de votre éditeur de texte
• Les fichiers intermédiaires de compilation

Pour éviter que git vous signale encore et encore ces fichiers comme non-suivis, créez un fichier .gitignore dans lequel vous indiquerez la liste des fichiers et répertoires à ignorer. Plus d'information ici.

Voici quelques bonnes pratiques dans le cadre d'un petit projet.

• Un commit toutes les deux heures - surtout la nuit
• Envoyer tous les jours le code sur un dépôt distant
• Au moins deux branches sur le dépôt local : une avec le code qui marche, une sur laquelle vous travaillez

Si vous devez n'en retenir que trois, prenez celles-ci:

• La documentation dont cet article s'est inspiré
• Utilisation des branches - en anglais
• Aide-mémoire de Git/Github

Autres ressources :

• Vincent Dubroeucq - Les base
• Vincent Dubroeucq - Les branches
• Vincent Dubroeucq - dépôts distants

Pour s'entraîner sans rien installer:

• Learn Git Branching - en français