Utiliser Git et GitHub

Pour partager un code et faciliter la collaboration, le suivi des modifications et la sauvegarde de votre projet, GitHub est l'une des solutions les plus populaires.
GitHub se distingue par sa facilité d'utilisation et ses fonctionnalités de gestion de projets open source ou privés.
Dans cet article, vous trouverez les étapes essentielles pour déposer un projet sur GitHub depuis une distribution Linux.
De l'installation de Git à la configuration de votre dépôt local, vous découvrirez comment structurer efficacement vos fichiers pour un suivi optimal et comment pousser votre travail vers un dépôt distant.

Déposer un projet sur GitHub depuis une distribution linux

Pour déposer un projet sur GitHub depuis Ubuntu, vous pouvez suivre les étapes suivantes :

1. Installer Git (si ce n'est pas déjà fait) :

(pour savoir si git est installé :)

Ouvrez un terminal et tapez :

2. Configurer Git avec votre nom d'utilisateur et votre email GitHub :

3. Initialiser le dépôt Git dans votre projet :

Accédez au répertoire de votre projet et initialisez un dépôt Git :

4. Ajouter les fichiers à votre dépôt Git :

5. Créer un commit :

6. Créer un dépôt sur GitHub :

- Allez sur GitHub et connectez-vous.

- Cliquez sur le bouton "New repository".

- Donnez un nom à votre dépôt, ajoutez une description si vous le souhaitez, et cliquez sur "Create repository".

7. Lier votre dépôt local au dépôt distant GitHub :

Copiez l'URL du dépôt GitHub (par exemple, https://github.com/votre_nom_utilisateur/votre_depot.git) et tapez :

La commande git remote permet de lister et gérer les dépôts distants auxquels votre dépôt local est lié.

Utilisez cette commande pour afficher les dépôts distants et leurs URLs.

La commande git remote get-url origin vous permet de récupérer l'URL du dépôt distant associé à un alias (souvent origin).

Cela est utile pour vérifier l'URL distante de votre dépôt Git.

8. Pousser votre projet sur GitHub :

'-u' = '--set-upstream'

Récapitulatif des commandes :

Et voilà, votre projet est maintenant déposé sur GitHub.

Cloner un dépôt GitHub en local

1. Installer Git (si ce n'est pas déjà fait)

Si Git n'est pas installé sur ta machine, tu peux le télécharger et l'installer à partir de git-scm.com. Assure-toi que Git est bien configuré en exécutant la commande suivante dans un terminal :

Cela devrait afficher la version de Git installée.

2. Cloner ton dépôt GitHub

Une fois Git installé, ouvre un terminal (ou une invite de commandes) et exécute la commande suivante pour cloner ton dépôt :

Remplace TON-NOM-DUTILISATEUR par ton nom d'utilisateur GitHub et NOM-DU-DEPOT par le nom du dépôt que tu veux cloner.

3. Accéder au dépôt cloné

Après avoir cloné le dépôt, tu peux accéder au répertoire en tapant :

4. Utiliser ton dépôt en local

Tu peux maintenant faire des modifications, créer des branches, ou synchroniser ton dépôt avec GitHub via des commandes comme :

• git pull : pour récupérer les dernières modifications du dépôt distant.
• git add, git commit, git push : pour ajouter, valider et pousser tes modifications.

5. remarque sur le pull

Un pull fait un merge.

Si il n'y a pas de nouveaux commit par rapport au remote, il fait un fast-forward.

Dans le cas inverse il fait une fusion avec un commit de merge.
Le pull est alors l'équivalent d'un git fetch && git merge origin/main

6. Différences entre Git Pull et Git Fetch

Git Fetch

• Fonctionnement : git fetch récupère les nouvelles données du dépôt distant (tous les commits, branches, et tags) sans les intégrer automatiquement dans votre branche de travail.
• Utilité : Permet de voir les modifications distantes sans altérer votre environnement local. Idéal pour examiner les changements avant de les appliquer.

Git Pull

• Fonctionnement : git pull combine un git fetch suivi d’un merge. Il récupère les modifications distantes et les fusionne dans votre branche locale.
• Utilité : Permet d’intégrer rapidement les modifications distantes dans votre travail local. Cependant, cette méthode peut créer des commits de fusion non désirés.

Rebaser avec Git Fetch (Pull Rebase)

Le rebase avec pull --rebase permet de placer vos modifications locales au-dessus des commits distants, conservant ainsi un historique plus linéaire et évitant les commits de fusion inutiles.

Étapes pour faire un pull avec rebase en utilisant fetch

1. Récupérez les modifications distantes avec fetch :
   git fetch origin
2. Appliquez un rebase pour intégrer les modifications distantes sans créer de commit de fusion :
   git rebase origin/main

   Remplacez main par le nom de votre branche si nécessaire.

Effectuer un Pull Rebase Directement

Pour combiner le fetch et le rebase en une seule commande, utilisez git pull --rebase :

Cette commande effectue le fetch puis intègre les modifications distantes en utilisant le rebase.

Avantages du Pull Rebase

• Historique linéaire : Maintient un historique de commits ordonné sans commits de fusion inutiles.
• Prévention des conflits : Vous pouvez traiter les conflits étape par étape pendant le rebase, ce qui simplifie la gestion des modifications avant de les pousser.

Utilisation de la commande git status

La commande git status est utilisée pour obtenir un état instantané du répertoire de travail dans Git. Elle te permet de voir les fichiers qui ont été modifiés, ajoutés ou supprimés, ainsi que l'état de ces modifications par rapport à l'index (staging area) et le dernier commit.

Ce que git status affiche :

1. Fichiers dans le répertoire de travail :
   • Modifiés mais non ajoutés à la zone de staging : Git te montre les fichiers qui ont été modifiés dans ton répertoire de travail mais qui n'ont pas encore été ajoutés à la zone de staging avec git add. Ils apparaissent sous une section généralement intitulée "Changes not staged for commit".
2. Fichiers dans la zone de staging (staged) :
   • Prêts à être commités : Les fichiers qui ont été modifiés et ensuite ajoutés à la zone de staging avec git add apparaissent dans une section intitulée "Changes to be committed". Ces fichiers sont prêts à être validés (committed) avec la commande git commit.
3. Fichiers non suivis (untracked files) :
   • Les fichiers nouveaux ou non suivis qui n'ont jamais été ajoutés au suivi par Git s'affichent dans une section intitulée "Untracked files". Ces fichiers ne sont pas encore pris en compte par Git tant que tu ne les ajoutes pas avec git add.

Exemple d'utilisation :

Ce qui pourrait afficher quelque chose comme ceci :

Ce que cela signifie :

1. On branch master : Tu es actuellement sur la branche master.
2. Your branch is up to date with 'origin/master'. : La branche locale est à jour avec la branche distante origin/master.
3. Changes to be committed: : Ces fichiers sont dans la zone de staging (staged) et prêts à être commités :
   • fichier1.txt a été modifié et ajouté à la zone de staging.
   • fichier2.txt est un nouveau fichier qui a été ajouté à la zone de staging.
4. Changes not staged for commit: : Ces fichiers ont été modifiés, mais n'ont pas encore été ajoutés à la zone de staging :
   • fichier3.txt est modifié mais non staged.
5. Untracked files: : Ces fichiers sont nouveaux et non suivis par Git :
   • fichier4.txt est un fichier qui n'est pas encore suivi et qui n'a pas été ajouté à la zone de staging.

Actions courantes après git status :

• Pour ajouter des fichiers modifiés à la zone de staging :
  git add fichier3.txt

  Cela va déplacer fichier3.txt dans la section "Changes to be committed".

• Pour committer les changements :

  Une fois que les fichiers sont dans la zone de staging, tu peux valider (committer) les changements :

  git commit -m "Message de commit"
• Pour ajouter des fichiers non suivis (untracked) :
  git add fichier4.txt

Résumé :

• git status te donne une vue claire de l'état de tes fichiers dans Git.
• Il montre les fichiers modifiés, les fichiers prêts à être commités et les fichiers non suivis.
• Cette commande est essentielle pour vérifier ce qui est prêt pour le prochain commit ou pour voir les changements en cours dans ton projet.

Explorer l'historique Git

Git permet de suivre les changements effectués dans un projet via un historique des commits. Voici quelques commandes utiles pour naviguer dans cet historique :

1. Afficher l'historique avec git log --pretty=oneline

Cette commande permet d'afficher l'historique des commits de manière concise, en affichant chaque commit sur une seule ligne :

Elle montre le hash abrégé du commit suivi du message de commit. Cela est très pratique pour avoir une vue d'ensemble rapide des changements.

2. Créer un alias pour cette commande avec git config

Tu peux configurer un alias pour cette commande afin de l'utiliser plus rapidement. Par exemple, en créant l'alias git lo :

Dès lors, tu pourras taper git lo pour obtenir le même résultat que git log --pretty=oneline.

3. Utiliser git log -p pour voir les différences

Pour visualiser les différences (ou diffs) entre les versions de chaque fichier modifié dans l'historique, utilise :

Cela montre les détails des changements ligne par ligne pour chaque commit, en affichant ce qui a été ajouté ou supprimé dans chaque fichier.

4. Voir les détails d'un commit avec git show

Si tu souhaites voir les détails d'un commit spécifique, par exemple les fichiers modifiés et les changements appliqués, tu peux utiliser la commande suivante :

Remplace <hash_du_commit> par le hash du commit que tu veux inspecter. Cette commande affiche les changements complets pour ce commit.

Voir les différences entre différentes zones

git diff

Cette commande montre ce qui a changé dans les fichiers locaux et qui n'a pas encore été ajouté à l'index (ou zone de staging).

git diff --staged

Cette commande montre les modifications qui ont été ajoutées à la zone de staging avec git add, mais qui n'ont pas encore été validées (committed).

Comparer deux commits spécifiques

Cette commande montre les différences entre deux commits spécifiques dans l'historique Git.

<commit1> et <commit2> sont les identifiants (SHA-1) ou références des commits.

Voir les différences locales pour un fichier modifié :

Cette commande montre les différences non commités entre les fichiers locaux modifiés et la version qui est déjà commitée dans la branche master

Comparer avec la branche distante origin/master :

Cette commande montre les difference entre les fichiers locaux et les fichiers actuels dans la branche origin/master (sur le dépôt distant)

Voir les différences entre deux commits pour un fichier spécifique :

Cette commande montre les difference entre les fichiers locaux et les fichiers actuels dans la branche origin/master (sur le dépôt distant)

Les branches

1. Créer une nouvelle branche et basculer immédiatement dessus.

C'est un raccourci pour deux commandes : git branch <nom_de_branche> (création) suivi de git checkout <nom_de_branche> (basculement).

Exemple :

Cette commande crée une nouvelle branche appelée nouvelle_branche et change la branche actuelle vers cette nouvelle branche.

2. Lister, créer ou supprimer des branches Git.

Usage :

• Lister les branches :
git branch
• Créer une nouvelle branche sans basculer dessus :
git branch nom_de_branche
• Supprimer une branche locale :
git branch -d nom_de_branche

3. Bascule entre les branches dans un dépôt Git.

Exemple :

Cela bascule vers la branche develop, mettant à jour le répertoire de travail pour refléter l'état de cette branche.

4. Comparer des branches

La commande git diff permet de comparer les différences entre deux branches.

• Comparer deux branches :
git diff brancheA brancheB

Cela montre les différences (ajouts/suppressions) entre les branches brancheA et brancheB.

• Comparer une branche avec la branche actuelle :
git diff brancheB

Si vous êtes sur brancheA, cela montre les différences avec brancheB.

• Options supplémentaires : Pour obtenir un résumé des fichiers modifiés sans voir le contenu exact :
git diff brancheA brancheB --stat

Résumé général :

• git checkout -b : Crée une nouvelle branche et bascule dessus.
• git branch : Liste, crée ou supprime des branches.
• git checkout : Change de branche dans le dépôt.
• git diff : Compare les différences entre deux branches.

Ces commandes sont utiles pour visualiser comment une branche diffère d'une autre avant de procéder à une fusion.

git merge et git rebase

1. git checkout -b mabranche

• But : Crée une nouvelle branche nommée mabranche et bascule immédiatement sur celle-ci.
• C'est un raccourci pour deux commandes : git branch mabranche (création de la branche) suivi de git checkout mabranche (basculement sur la nouvelle branche).

Exemple :

Cela crée une nouvelle branche appelée mabranche et passe dessus automatiquement. C’est une manière pratique de démarrer une nouvelle branche de travail directement à partir de la branche courante.

2. git merge

• But : Fusionne une branche source (par exemple mabranche) dans la branche courante (par exemple main).
• Cela combine les modifications de deux branches en une seule.

Exemple :

Fast-forward merge : Si la branche main n'a pas de nouveaux commits par rapport à mabranche, Git effectuera un "fast-forward".

3. git merge --no-ff

• But : Force la création d'un commit de fusion, même si un "fast-forward" est possible.
• Cela garde un historique clair de la fusion, avec un commit de merge dédié.

Exemple :

4. Exemples concrets : git merge et git merge --no-ff

Exécution de git merge (fast-forward possible) :

Si mabranche contient 3 commits et que main n'a pas de nouveaux commits depuis que mabranche a divergé, Git peut effectuer une fusion fast-forward. Cela signifie que Git avance simplement la branche main jusqu'au dernier commit de mabranche sans créer de commit de fusion.

L'historique après un fast-forward ressemblerait à ceci :

Dans ce cas, l'historique est linéaire, comme si les commits de mabranche avaient été effectués directement dans main, car il n'y a eu aucun travail supplémentaire dans main. Aucun commit de fusion n'est créé.

---

Exécution de git merge --no-ff (force la création d'un commit de fusion) :

Même si une fusion fast-forward est possible, l'option --no-ffforce la création d'un commit de fusion. Cela permet de conserver une trace explicite de la fusion dans l'historique.

L'historique après une fusion avec --no-ff ressemblerait à ceci :

---

Différences clés entre git merge et git merge --no-ff :

• git merge (fast-forward) : Si aucun commit n'a été fait sur main après la divergence avec mabranche, Git avance simplement main pour pointer vers le dernier commit de mabranche. Cela ne crée pas de commit de fusion et l'historique reste linéaire.
• git merge --no-ff : Même lorsque Git pourrait avancer la branche avec un fast-forward, l'option --no-ff force la création d'un commit de fusion, ce qui rend l'historique plus explicite en montrant qu'une branche a été fusionnée.

Pourquoi utiliser --no-ff ?

• Clarté de l'historique : L'option --no-ff est utile pour garder une trace visible de la fusion des branches. Cela permet de voir clairement dans l'historique que deux branches distinctes ont été combinées, même si la fusion aurait pu se faire en fast-forward.

5. git rebase

• But : Applique les commits d'une branche sur une autre, en les repositionnant au sommet de la branche cible.

Exemple :

Cas d'utilisation :

Lorsqu'une branche de fonctionnalité doit intégrer les changements récents d'une branche principale, le rebase permet de "mettre à jour" cette branche sans ajouter de commit de fusion.

6. git merge --abort

• But : Annule une fusion en cours si quelque chose ne va pas (comme des conflits complexes).

Exemple :

7. Résolution des conflits

Lorsque tu fais un git merge ou un git rebase, il peut y avoir des conflits. Voici comment les résoudre :

Comment identifier un conflit :

Étapes pour résoudre les conflits :

1. Ouvre les fichiers en conflit et modifie les parties voulues.
2. Supprime les marqueurs de conflit (<<<<<<< HEAD, =======, >>>>>>>).
3. git add fichier_conflit.txt
4. Finalise la fusion avec git commit ou le rebase avec git rebase --continue.

8. Différence entre Merge et Rebase en Git

Lors de la gestion de branches avec Git, deux méthodes populaires pour intégrer des changements d'une branche dans une autre sont le merge et le rebase. Chacune de ces méthodes a ses avantages selon les besoins et la situation.

Merge : Fusion de branches

Le merge (fusion) est l'approche la plus courante pour intégrer les changements d'une branche à une autre. Cette méthode crée un commit de merge, qui enregistre une nouvelle étape dans l'historique en combinant les deux branches, tout en préservant leur historique. Cela signifie que l'historique des commits reste intact, avec une trace claire du moment où les branches ont divergé et convergé.

L'historique après un commit de merge ressemblerait à ceci :

• Avantages :
  • L'historique de la branche reste intact, ce qui rend facile de suivre l'évolution du projet.
  • Le processus est simple et rapide pour intégrer les changements.
  • Utile lorsque vous voulez conserver l'historique complet des commits pour un suivi transparent.
• Inconvénients :
  • Peut rendre l'historique plus complexe à lire, surtout avec beaucoup de branches et de commits.

Exemple :

Rebase : Réorganisation des commits

Le rebase réécrit l'historique en appliquant les commits d'une branche au-dessus de l'autre branche. Il permet de conserver un historique linéaire, sans commit de merge. Le rebase fait comme si tous les commits de la branche étaient appliqués à partir du dernier commit de la branche cible, donnant un historique plus propre.

• Avantages :
  • Crée un historique linéaire, facile à suivre et à lire, sans commits de merge.
  • Utile pour des projets avec beaucoup de collaborateurs où la clarté de l'historique est primordiale.
• Inconvénients :
  • Réécrit l'historique, ce qui peut créer des conflits compliqués à gérer.
  • Doit être utilisé avec précaution, surtout si la branche a déjà été partagée avec d'autres utilisateurs.

Exemple :

Quand utiliser Merge ou Rebase ?

Merge est idéal pour les situations où vous souhaitez préserver l'historique des branches et lorsque l'importance est accordée à la traçabilité des branches divergentes.
Rebase est parfait pour maintenir un historique propre et linéaire, particulièrement utile dans des branches privées ou lors de la préparation de pull requests.

Conclusion

Choisir entre merge et rebase dépend principalement de vos préférences et des besoins de votre projet. Le merge est sûr et préserve tout l'historique, tandis que le rebase offre une vision plus claire et ordonnée de l'évolution du code, au prix de manipuler avec soin l'historique.

Résoudre les conflits lors de la synchronisation de votre dépôt local avec le dépôt distant. :

1. Stasher les modifications locales

Sauvegarde temporairement les modifications locales.

2. Tirer les nouvelles modifications du dépôt distant

Récupère les nouvelles modifications depuis le dépôt distant.

3. Appliquer les modifications stashées

Réapplique les modifications sauvegardées temporairement.

4. Résoudre les conflits

Ouvrir les fichiers en conflit, résoudre les conflits

puis les ajouter à l'index

5. Valider la résolution des conflits

Valide les modifications après résolution des conflits.

6. Pousser les modifications vers le dépôt distant

Publie les modifications résolues sur le dépôt distant.

-------

Naviguer dans l'Historique Git

Git propose de nombreuses commandes pour naviguer, réécrire et ajuster l'historique d'un projet. Voici quelques-unes des commandes les plus utiles pour la gestion de l'historique :

1. Modifier le Dernier Commit : git commit --amend

La commande git commit --amend permet de modifier le dernier commit, que ce soit pour corriger le message, ajouter des fichiers oubliés, ou ajuster les modifications effectuées.

2. Gérer les Branches avec git branch

Pour travailler avec plusieurs versions du projet, vous pouvez créer des branches en utilisant git branch :

• Créer une nouvelle branche : git branch
• Lister toutes les branches : git branch
• Supprimer une branche : git branch -d

3. Naviguer entre les Commits avec git checkout

• Pour passer d’une branche à une autre facilement :
git switch <nom_de_branche>
git checkout <nom_de_branche>
• Pour revenir à un commit précis en utilisant son hash :
git checkout <hash_du_commit>
• Accéder au commit immédiatement précédent :
git checkout^
• Accéder à un commit trois niveaux en amont dans l'historique :
git checkout~3

4. Fusionner les derniers Commits avec git rebase -i

Pour ajuster plusieurs commits à la fois, git rebase -i permet de réorganiser, éditer ou fusionner les derniers commits :

Ici, vous pourrez interagir avec les 4 derniers commits, en choisissant les actions à effectuer.

5. Créer un Commit Vide avec git commit --allow-empty

Pour ajouter un commit vide, souvent utilisé pour déclencher des scripts ou pipelines automatisés :

6. Annuler les modifications locales dans le répertoire de travail

Si vous avez modifié un fichier mais n'êtes pas satisfait des changements, vous pouvez restaurer le fichier à son état dans l'index (zone de staging) avec git restore.

La commande git restore --worktree permet de rétablir un fichier à son état précédent ( --worktree est le comportement par défaut) :

Cela remplace le contenu de nom_du_fichier dans le répertoire de travail par celui de l'index, annulant ainsi les modifications locales non validées.

7. Retirer des fichiers de l'index sans toucher aux fichiers locaux (unstage)

• Pour désindexer un fichier sans supprimer ses modifications locales :
git reset <nom_du_fichier>
• Pour revenir à un état antérieur de l'historique sans toucher aux fichiers locaux :
git reset

La commande git restore --staged permet aussi de rétablir un fichier à son état précédent :

Cette commande supprime le fichier de la zone de staging sans le supprimer du répertoire de travail.

La commande Git Reset

La commande git reset est une des commandes Git les plus puissantes et potentiellement dangereuses si elle est mal utilisée. Elle permet de réécrire l'historique en déplaçant la référence de la branche actuelle (HEAD) vers un autre commit, tout en offrant un contrôle précis sur l'état de l'index (staging area) et du répertoire de travail (working directory).

Fonctionnalités principales de git reset :

1. Déplacer HEAD vers un commit spécifique :
   git reset [options] commit_hash

   Cette commande réoriente la branche courante vers commit_hash, modifiant ainsi l'historique de cette branche.

2. Contrôler l'état de l'index et du répertoire de travail : Les options --soft, --mixed et --hard déterminent comment git reset affecte l'index et le répertoire de travail.

Options importantes :

--soft :

• Déplace HEAD vers le commit spécifié sans modifier l'index ni le répertoire de travail.
• Conserve les modifications pour être revalidées.
  Les modifications sont revenues à l'état staged.

--mixed (par défaut) :

• Déplace HEAD et met à jour l'index pour qu'il corresponde au nouveau HEAD.
• Les modifications non validées sont présentes dans le répertoire de travail mais ne sont pas indexées.

--hard :

• Déplace HEAD, met à jour l'index et le répertoire de travail pour qu'ils correspondent au nouveau HEAD.
• Attention : Les modifications non validées seront perdues.

Exemples pratiques :

1. Annuler le dernier commit tout en conservant les modifications dans l'index :

2. Annuler le dernier commit en conservant les modifications dans le répertoire de travail :

3. Réinitialiser complètement le projet à un état antérieur :

Diagramme des effets de git reset :

Considérons une situation où HEAD pointe vers commit C avec des modifications non validées dans le répertoire de travail. Voici les effets des différentes options :

--soft :

    Avant :
    HEAD -> C
    Index : C
    Travail : C + modifications

    Après `git reset --soft B` :
    HEAD -> B
    Index : C
    Travail : C + modifications
    

--mixed :

    Après `git reset --mixed B` :
    HEAD -> B
    Index : B
    Travail : C + modifications
    

--hard :

    Après `git reset --hard B` :
    HEAD -> B
    Index : B
    Travail : B
    

Précautions à prendre :

• Perte de données : L'utilisation de git reset --hard peut entraîner la perte définitive de modifications non validées.
• Historique partagé : Évitez de réécrire l'historique des branches partagées.

Différences avec d'autres commandes :

• git revert : Annule les modifications d'un commit avec un nouveau commit sans réécrire l'historique.
• git checkout et git restore : Bascule entre les branches ou restaure des fichiers sans affecter l'historique des commits.

Conseils supplémentaires :

• Visualiser l'historique : Utilisez git log --oneline --graph pour visualiser les commits avant un git reset.
• Sauvegarder les modifications : Utilisez git stash pour sauvegarder temporairement des changements non validés.

Cas d'utilisation courants :

1. Annuler plusieurs commits locaux :

2. Nettoyer le répertoire de travail :

3. Modifier le message du dernier commit :

En résumé :

• git reset déplace HEAD avec un contrôle sur l'index et le répertoire de travail.
• Les options --soft, --mixed, et --hard offrent des choix selon les besoins.
• Prudence : Vérifiez toujours les modifications non validées avant d'utiliser git reset, surtout avec --hard.

-------

Fonctionnement de .gitignore :

Le fichier .gitignore est utilisé par Git pour déterminer quels fichiers et répertoires doivent être ignorés dans un projet. Lorsqu'un fichier ou un répertoire est répertorié dans .gitignore, Git ne le suivra pas et ne l'ajoutera pas au dépôt. Cela est particulièrement utile pour exclure des fichiers temporaires, des fichiers de configuration locale, des fichiers générés automatiquement ou d'autres fichiers qui ne doivent pas être inclus dans le contrôle de version.

1. Création d'un fichier .gitignore

Vous pouvez créer un fichier .gitignore à la racine de votre projet (ou dans n'importe quel sous-répertoire) en utilisant un éditeur de texte. Par exemple :

2. Ajout de règles au fichier .gitignore

Vous pouvez spécifier les fichiers et répertoires à ignorer en ajoutant des règles dans le fichier .gitignore. Voici quelques exemples de règles courantes :

• Ignorer tous les fichiers d'un type spécifique :
  *.log
• Ignorer un répertoire spécifique et son contenu :
  /node_modules
• Ignorer tous les fichiers dans un répertoire spécifique :
  logs/
• Ignorer des fichiers spécifiques :
  secret.txt
• Ignorer tous les fichiers sauf un dans un répertoire :
  /directory/*
  !/directory/important.txt

Exemples de .gitignore pour différents projets :

Projet Python/Django :

Projet Node.js :

Projet général :

Important à savoir

• Les règles de .gitignore sont spécifiques au répertoire où le fichier .gitignore est placé. Si vous avez un .gitignore dans un sous-répertoire, il sera appliqué uniquement aux fichiers et sous-répertoires de ce répertoire.
• Si vous ajoutez une règle à .gitignore après que des fichiers ont déjà été ajoutés et suivis par Git, ces fichiers continueront d'être suivis. Vous devrez les retirer du suivi avec la commande git rm --cached <fichier> pour que Git commence à les ignorer.
• Vous pouvez utiliser des commentaires dans le fichier .gitignore en commençant une ligne par le symbole #.

En résumé, le fichier .gitignore est un outil puissant pour gérer les fichiers et répertoires que vous ne souhaitez pas inclure dans votre dépôt Git, vous aidant ainsi à garder votre projet propre et organisé.