Différences

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

--- fr:informatics:utilisez_git_pour_gerer_vos_versions [09/06/2024 11:07]
Keuronde [Principe de base de fonctionnement]
+++ fr:informatics:utilisez_git_pour_gerer_vos_versions [09/06/2024 16:12] (Version actuelle)
Keuronde [Ressources externe]
@@ Ligne 4: / Ligne 4: @@
 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à, [[https://git-scm.com/book/fr/v2|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.
 ==== La structure de git ====
@@ Ligne 9: / Ligne 11: @@
 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 projets, tout 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.
+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 parti de l'historique du projet.
+  * **Validé** : La version de ce fichier fait partie de l'historique du projet.
-A 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 :
+À 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
@@ Ligne 35: / Ligne 37: @@
 Sous Linux, prenez la version dans votre distribution. Sur les dérivées de Debian :
-`apt get install git`
+<code>apt get install git</code>
-Sous Windows, installez *[Git for windows](https://git-scm.com/download/win)*
+Sous Windows, installez [[https://git-scm.com/download/win|Git for windows]]
 Sous Mac, lancez 'git' dans un terminal, s'il n'est pas installé, il vous demandera de le faire.
@@ Ligne 43: / Ligne 45: @@
 ==== Créer un dépôt ====
-=== A partir du répertoire d'un projet ===
+=== À partir du répertoire d'un projet ===
-git init
+<code>git init</code>
-=== A partir d'un dépôt existant ===
+=== À partir d'un dépôt existant ===
 Pour cloner un dépôt :
-git clone <adresse du dépôt>
+<code>git clone <adresse du dépôt></code>
 ==== État du dépôt ====
-git status
+<code>git status</code>
 La commande indique quelle branche est active, les fichiers modifiés, ceux ajoutés à l'index, ceux qui ne sont pas suivis.
@@ Ligne 62: / Ligne 64: @@
 ==== Ajouter un fichier à l'index ====
+<code>git add <fichier></code>
-git add <fichier>
 ==== Valider les modifications ====
-git commit
+<code>git commit</code>
 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>"
+<code>git commit -a -m "<Description des modifications>"</code>
 Cette commande ajoute tous les fichiers modifiés à l'index et valide les modifications. Attention, cette commande ne tiendra pas compte des nouveaux fichiers.
 ==== Identification des versions ====
@@ Ligne 81: / Ligne 81: @@
 === Les tags ===
-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.
+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.
 === Les branches ===
-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.
+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 principale, contient le code testé et validé.
-- La branche de test, contient le code qui a pu être testé.
+  * 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.
+  * 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...
@@ Ligne 97: / Ligne 97: @@
 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éé 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._
+//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.//
+==== Que suivre avec Git et que ne pas suivre avec Git ====
+=== A suivre avec Git ===
+  * Votre code
+  * Votre système de compilation (Makefile, cmake) si vous le personnalisez
+=== A ne pas suivre avec Git ===
+  * 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. [[https://git-scm.com/docs/gitignore/fr|Plus d'information ici]].
 ==== Les bonnes pratiques ====
@@ Ligne 103: / Ligne 114: @@
 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
+==== Ressources externe ====
+Si vous devez n'en retenir que trois, prenez celles-ci:
-Ressources externe
+  * [[https://git-scm.com/book/fr|La documentation dont cet article s'est inspiré]]
-==================
+  * [[https://nvie.com/posts/a-successful-git-branching-model/|Utilisation des branches - en anglais]]
+  * [[https://training.github.com/downloads/fr/github-git-cheat-sheet.pdf|Aide-mémoire de Git/Github]]
-- [La documentation dont cet article s'est inspiré](https://git-scm.com/book/fr)
+Autres ressources :
-- [Utilisation des branches - en anglais](https://nvie.com/posts/a-successful-git-branching-model/)
+  * [[https://vincentdubroeucq.com/apprendre-git-partie-1/|Vincent Dubroeucq - Les base]]
+  * [[https://vincentdubroeucq.com/apprendre-git-partie-2-les-branches/|Vincent Dubroeucq - Les branches]]
+  * [[https://vincentdubroeucq.com/apprendre-git-partie-3-travailler-avec-un-depot-distant/|Vincent Dubroeucq - dépôts distants]]
-- [Vincent Dubroeucq - Les base](https://vincentdubroeucq.com/apprendre-git-partie-1/)
+Pour s'entraîner sans rien installer:
-- [Vincent Dubroeucq - Les branches](https://vincentdubroeucq.com/apprendre-git-partie-2-les-branches/)
+  * [[https://learngitbranching.js.org/?locale=fr_FR|Learn Git Branching - en français]]
-- [Vincent Dubroeucq - dépots distants](https://vincentdubroeucq.com/apprendre-git-partie-3-travailler-avec-un-depot-distant/)