Les commandes Git et GitHub que tout développeur doit connaître

Git est devenu le standard incontournable pour la gestion de versions, utilisé par plus de 70 % des développeurs dans le monde. Mais le maîtriser va bien au-delà de la simple mémorisation de quelques commandes. Il s'agit de comprendre des workflows efficaces, d'adopter des bonnes pratiques de collaboration et de savoir comment garder un historique de projet propre et lisible.

Initialiser un dépôt et configurer les bases

Tout projet sous Git commence par l'initialisation d'un dépôt. C'est la première étape qui permet de commencer à suivre les modifications de vos fichiers.

git init : créer un nouveau dépôt

La commande git init transforme un dossier ordinaire en un dépôt Git. Elle crée un sous-dossier caché .git qui contient toute la configuration et l'historique de votre projet. C'est le point de départ de toute gestion de version. Une fois cette commande exécutée, Git commence à observer ce dossier.

git status : vérifier l'état de votre projet

La commande git status est votre meilleur allié au quotidien. Elle vous donne un aperçu complet de l'état de votre projet à un instant T :

Les fichiers qui ont été modifiés mais pas encore préparés pour le prochain commit.
Les fichiers qui sont "stagés" (prêts à être inclus dans le prochain commit).
Les nouveaux fichiers que Git ne suit pas encore.
La branche sur laquelle vous vous trouvez et sa synchronisation avec le dépôt distant.

Prendre l'habitude de lancer git status fréquemment vous évite bien des surprises.

git config : personnaliser votre environnement

Avant de faire votre premier commit, il est crucial de configurer votre identité. Git enregistre un nom et une adresse e-mail avec chaque commit, il est donc important que cette information soit correcte.

git config --global user.name "Votre Nom"
git config --global user.email "votre.email@example.com"

L'option --global applique cette configuration à tous vos projets Git sur votre machine. Vous pouvez aussi la définir localement pour un projet spécifique en omettant cette option.

Suivre, préparer et enregistrer les modifications

Le cycle de vie d'une modification dans Git se déroule en trois temps : la modification dans votre espace de travail, l'ajout à la zone de "staging", et enfin l'enregistrement permanent via un commit.

git add : préparer les fichiers pour le commit

La commande git add permet de sélectionner les modifications que vous souhaitez inclure dans votre prochain commit. C'est une étape intermédiaire appelée "staging" ou "indexation". Elle vous donne un contrôle précis sur ce qui sera enregistré.

Pour ajouter un fichier spécifique : git add nom-du-fichier.js
Pour ajouter toutes les modifications dans le dossier courant : git add .

Cette étape permet de construire des commits atomiques, c'est-à-dire des commits qui regroupent des modifications logiquement liées, même si vous avez travaillé sur plusieurs choses en parallèle.

git commit : enregistrer les modifications

Un commit est un instantané de votre projet à un moment donné. La commande git commit enregistre les fichiers que vous avez préparés avec git add dans l'historique du projet.

Un bon commit est atomique et accompagné d'un message clair. Le message doit expliquer pourquoi la modification a été faite, pas seulement ce qui a été changé.

Une pratique courante est d'utiliser le format "Conventional Commits". Par exemple, au lieu d'un message vague comme "correction", on écrira fix: corrige le bug de connexion lors du timeout. Cela rend l'historique beaucoup plus facile à lire et permet même d'automatiser la génération de changelogs.

Collaborer avec les dépôts distants

La plupart des projets impliquent une collaboration via une plateforme comme GitHub, GitLab ou Bitbucket. Les commandes suivantes sont essentielles pour synchroniser votre travail avec un dépôt distant.

git clone : copier un dépôt existant

Pour commencer à travailler sur un projet qui existe déjà, vous utiliserez git clone [URL-du-dépôt]. Cette commande ne se contente pas de télécharger les fichiers ; elle copie l'intégralité de l'historique Git et configure une connexion (nommée "origin" par défaut) avec le dépôt distant.

git fetch vs git pull : synchroniser les changements

C'est un point de confusion courant pour les débutants. Bien que similaires, ces deux commandes ont des rôles différents.

git fetch télécharge les dernières modifications depuis le dépôt distant mais ne les fusionne PAS dans votre branche de travail. Cela vous permet de voir ce qui a changé sans impacter votre travail en cours.
git pull est une combinaison de deux commandes : git fetch suivi de git merge. Elle télécharge les modifications ET tente de les fusionner immédiatement dans votre branche actuelle.

Pour un meilleur contrôle, il est souvent recommandé de faire un git fetch d'abord, d'inspecter les changements, puis de faire un git merge ou un git rebase manuellement.

git push : envoyer vos commits

Une fois que vous avez créé un ou plusieurs commits en local, git push les envoie vers le dépôt distant pour les partager avec votre équipe. La commande git push origin main envoie par exemple les commits de votre branche main locale vers la branche main du dépôt distant origin.

La gestion des branches, le cœur de Git

Les branches sont l'une des fonctionnalités les plus puissantes de Git. Elles permettent de travailler sur de nouvelles fonctionnalités ou de corriger des bugs en toute isolation, sans affecter la branche principale (souvent nommée main ou master).

git branch : lister, créer et supprimer des branches

git branch (sans argument) liste toutes les branches locales.
git branch nom-de-la-branche crée une nouvelle branche.
git branch -d nom-de-la-branche supprime une branche (uniquement si elle a été fusionnée).

Une bonne pratique est d'adopter une convention de nommage claire, par exemple :

feature/nouvelle-sidebar pour une nouvelle fonctionnalité.
fix/probleme-authentification pour une correction de bug.
hotfix/vulnerabilite-critique pour une correction urgente en production.

git checkout et git switch : changer de branche

Historiquement, git checkout était utilisé à la fois pour changer de branche et pour restaurer des fichiers. Pour plus de clarté, des commandes plus récentes ont été introduites.

git switch nom-de-la-branche permet de changer de branche.
git switch -c nouvelle-branche crée une nouvelle branche et bascule dessus immédiatement.

Bien que git checkout fonctionne toujours, git switch rend l'intention plus explicite et est recommandé pour les nouveaux usages.

Fusionner le travail : merge et rebase

Une fois le travail sur une branche terminé, il faut l'intégrer à la branche principale. Git propose deux stratégies principales pour cela : merge et rebase.

git merge : combiner deux branches

La commande git merge nom-de-la-branche intègre les modifications de la branche spécifiée dans votre branche actuelle. Elle crée un "commit de fusion" (merge commit) qui relie les deux historiques, préservant ainsi le contexte exact de l'existence des deux branches. C'est une méthode sûre qui ne réécrit pas l'historique.

Parfois, des conflits surviennent si les mêmes lignes de code ont été modifiées dans les deux branches. Git vous demandera alors de résoudre ces conflits manuellement avant de finaliser la fusion.

git rebase : réécrire l'historique pour plus de clarté

La commande git rebase offre une approche différente. Au lieu de créer un commit de fusion, elle prend les commits de votre branche et les rejoue un par un "par-dessus" la dernière version de la branche cible. Le résultat est un historique linéaire, comme si tout le travail avait été fait séquentiellement.

Attention : Ne jamais utiliser git rebase sur une branche qui est partagée avec d'autres collaborateurs. La réécriture de l'historique peut causer des problèmes majeurs pour synchroniser le travail de l'équipe. Le rebase est un outil puissant, mais à réserver pour nettoyer votre historique local avant de le partager.

Critère	git merge	git rebase
Historique du projet	Non linéaire. Conserve l'historique exact de chaque branche. Le commit de fusion sert de trace.	Linéaire et propre. Réécrit l'historique pour donner l'impression d'un développement séquentiel.
Lisibilité	Peut devenir complexe et difficile à lire sur de gros projets avec beaucoup de branches.	Très facile à suivre, car l'historique est une simple ligne droite.
Collaboration	Sûr pour toutes les branches, y compris celles partagées (publiques). C'est la méthode par défaut.	Dangereux sur les branches partagées. À n'utiliser que sur vos branches locales avant de les fusionner.
Résolution des conflits	Les conflits sont résolus une seule fois, lors du commit de fusion final.	Les conflits peuvent devoir être résolus à chaque commit rejoué, ce qui peut être répétitif.

Commandes utiles pour le quotidien

Voici quelques commandes qui vous sauveront la mise dans de nombreuses situations.

git log : explorer l'historique

git log affiche l'historique des commits. Cette commande est extrêmement puissante avec ses nombreuses options :

git log --oneline : Affiche une version condensée de l'historique, un commit par ligne.
git log --graph : Montre l'historique sous forme de graphe, très utile pour visualiser les branches et les fusions.
git log -p : Affiche les modifications (le "patch") introduites par chaque commit.

git stash : mettre de côté des modifications non terminées

Vous travaillez sur une fonctionnalité, mais une demande urgente arrive. Vos modifications ne sont pas prêtes à être commitées. git stash est la solution : cette commande sauvegarde temporairement vos modifications locales (non commitées) et nettoie votre espace de travail. Vous pouvez alors changer de branche pour travailler sur l'urgence. Une fois terminé, revenez à votre branche et utilisez git stash pop pour récupérer vos modifications et continuer votre travail.

git reset et git revert : annuler des modifications

Il existe plusieurs façons d'annuler des changements dans Git.

git reset : Déplace la tête de la branche (HEAD) vers un commit précédent. L'option --hard supprime toutes les modifications, tandis que --soft les conserve dans la zone de staging. C'est une commande puissante mais destructive, à utiliser avec prudence sur l'historique local.
git revert [hash-du-commit] : Crée un NOUVEAU commit qui annule les modifications introduites par un commit précédent. C'est la méthode la plus sûre pour annuler des changements sur une branche partagée, car elle ne réécrit pas l'historique.

Les Pull Requests : le cœur de la collaboration sur GitHub

Une Pull Request (ou Merge Request sur GitLab) n'est pas une commande Git, mais un mécanisme essentiel des plateformes de collaboration. C'est une demande formelle pour fusionner une branche dans une autre.

C'est l'endroit où se déroulent les discussions et les revues de code. L'équipe peut commenter le code, demander des modifications et valider le travail avant qu'il ne soit intégré à la branche principale. Utiliser les Pull Requests est une pratique fondamentale pour garantir la qualité du code et le partage des connaissances au sein d'une équipe.

Commandes avancées pour les situations complexes

Une fois que vous maîtrisez les bases, ces commandes vous donneront encore plus de contrôle.

git cherry-pick : appliquer un commit spécifique

Imaginez qu'un bug a été corrigé sur une branche de développement, mais que cette correction est également nécessaire de toute urgence sur la branche de production. git cherry-pick [hash-du-commit] vous permet d'appliquer uniquement ce commit spécifique sur votre branche actuelle, sans avoir à fusionner toute la branche de développement.

git reflog : votre filet de sécurité

Vous avez supprimé une branche par erreur ? Fait un git reset --hard trop agressif ? git reflog est là pour vous sauver. Cette commande affiche un journal de toutes les actions qui ont modifié la tête de vos branches (HEAD). Vous pouvez y retrouver l'identifiant d'un commit que vous pensiez perdu et le restaurer. C'est un véritable historique de vos actions locales.

git bisect : trouver le commit qui a introduit un bug

Quand un bug apparaît, mais que vous ne savez pas quand il a été introduit, git bisect est un outil de débogage incroyablement efficace. Vous lui indiquez un commit "sain" et un commit "buggé", et Git va automatiquement naviguer entre les commits (en utilisant une recherche binaire) pour vous aider à identifier précisément celui qui a introduit le problème.

En résumé, maîtriser Git et GitHub est un investissement qui porte ses fruits à chaque étape du développement logiciel. En allant au-delà des commandes de base et en comprenant les stratégies de branche, de fusion et de collaboration, vous et votre équipe pouvez construire des logiciels de manière plus rapide, plus propre et plus sereine.

Commandes Git et GitHub : Le guide pour optimiser votre workflow

Maîtriser Git et GitHub est devenu une compétence incontournable pour tout développeur. Ces outils ne servent pas seulement à sauvegarder du code, ils transforment la manière de collaborer, de gérer les versions et de garantir la qualité des projets. Que vous débutiez ou cherchiez à solidifier vos acquis, comprendre les commandes essentielles est la clé pour travailler plus efficacement. Cet article décompose les commandes Git et GitHub les plus importantes, des bases aux workflows plus avancés, pour vous aider à prendre le contrôle de votre code.

Les bases : configurer et démarrer un projet

Avant de pouvoir enregistrer votre travail, quelques étapes de configuration sont nécessaires. C'est simple, rapide et vous n'aurez à le faire qu'une seule fois sur votre machine.

Configurer votre identité

La première chose à faire est de dire à Git qui vous êtes. Ces informations seront associées à chaque modification (commit) que vous ferez.

Définir votre nom d'utilisateur : git config --global user.name "Votre Nom"
Définir votre adresse e-mail : git config --global user.email "votre.email@example.com"

L'option --global applique cette configuration à tous vos projets Git sur votre ordinateur.

Créer un nouveau dépôt

Vous avez deux manières de démarrer un projet avec Git.

Initialiser un projet existant Si vous avez déjà un dossier de projet, naviguez dedans via votre terminal et lancez la commande suivante. git init Cette commande crée un sous-dossier caché .git qui contient toute la logique de suivi des versions. Votre projet est maintenant un dépôt Git local.
Cloner un projet distant Pour travailler sur un projet qui existe déjà sur une plateforme comme GitHub, vous devez en créer une copie locale. C'est ce qu'on appelle cloner. git clone <URL_DU_DÉPÔT> Cette commande télécharge l'intégralité du projet et son historique sur votre machine.

Le cycle de vie d'un fichier : la base du travail avec Git

Comprendre comment Git suit les modifications est fondamental. Le processus se déroule en trois étapes principales.

Le répertoire de travail (Working Directory) : C'est votre dossier de projet, là où vous modifiez, créez et supprimez des fichiers.
La zone de préparation (Staging Area) : C'est une étape intermédiaire où vous sélectionnez les modifications spécifiques que vous souhaitez inclure dans le prochain "snapshot" (commit).
Le dépôt local (Local Repository) : C'est là que Git sauvegarde de manière permanente les snapshots de votre projet sous forme de commits.

Les commandes pour enregistrer vos modifications

Voici les trois commandes que vous utiliserez constamment.

Vérifier l'état de vos fichiers La commande git status est votre meilleure amie. Elle vous montre quels fichiers ont été modifiés, lesquels sont prêts à être enregistrés et ceux que Git ne suit pas encore. git status

Pour ajouter tous les fichiers modifiés d'un coup, utilisez git add .

Préparer les fichiers pour l'enregistrement La commande git add déplace les modifications du répertoire de travail vers la zone de préparation. git add <nom_du_fichier>

Un bon message de commit est court, descriptif et explique le pourquoi du changement, pas seulement le quoi.

Enregistrer les modifications La commande git commit prend tout ce qui se trouve dans la zone de préparation et le sauvegarde de manière permanente dans votre dépôt local. Chaque commit est accompagné d'un message qui explique les changements. git commit -m "Un message descriptif de vos modifications"

Travailler avec les branches : la puissance de la collaboration

Les branches sont la fonctionnalité la plus puissante de Git. Elles vous permettent de travailler sur de nouvelles fonctionnalités ou de corriger des bugs en toute sécurité, sans affecter la version principale de votre code (la branche main ou master).

Gérer les branches

Lister toutes les branches git branch La branche sur laquelle vous vous trouvez est marquée par un astérisque.
Créer une nouvelle branche git branch <nom_de_la_branche>
Changer de branche Pour commencer à travailler sur une autre branche, vous devez vous y déplacer. git checkout <nom_de_la_branche>

Astuce : vous pouvez créer et vous déplacer sur une nouvelle branche en une seule commande avec git checkout -b <nouveau_nom_de_branche>.

Fusionner les branches

Une fois votre travail sur une branche terminé, vous voudrez intégrer vos modifications dans la branche principale. C'est ce qu'on appelle une fusion (merge).

Retournez sur la branche qui doit recevoir les modifications (généralement main). git checkout main
Lancez la commande de fusion en spécifiant la branche que vous voulez intégrer. git merge <nom_de_la_branche_à_fusionner>

Une fois la fusion terminée et poussée sur le dépôt distant, vous pouvez supprimer la branche de fonctionnalité. git branch -d <nom_de_la_branche>

Collaborer avec un dépôt distant (comme GitHub)

Jusqu'à présent, toutes nos actions étaient locales. Pour collaborer, il faut synchroniser votre travail avec un dépôt distant.

Voir vos dépôts distants Par défaut, le dépôt distant principal s'appelle origin. Pour vérifier, utilisez : git remote -v
Envoyer vos modifications vers le distant La commande git push envoie vos commits locaux vers le dépôt distant. git push origin <nom_de_la_branche> La première fois que vous poussez une nouvelle branche, vous devrez peut-être utiliser git push --set-upstream origin <nom_de_la_branche>.
Récupérer les modifications du distant Pour mettre à jour votre dépôt local avec les dernières modifications du distant, utilisez git pull. git pull origin <nom_de_la_branche>

git pull est en réalité une combinaison de deux commandes : git fetch (qui récupère les informations) et git merge (qui les fusionne dans votre branche locale).

Commandes utiles au quotidien

Voici quelques commandes qui vous sauveront la vie plus d'une fois.

Inspecter l'historique

Pour voir la liste des commits passés, utilisez git log. git log

Pour une vue plus concise, essayez git log --oneline --graph.

Annuler des modifications

Parfois, on fait des erreurs. Git offre plusieurs moyens de revenir en arrière.

Annuler les modifications locales non commitées Pour annuler toutes les modifications sur un fichier depuis le dernier commit : git checkout -- <nom_du_fichier>
Modifier le dernier commit Si vous avez oublié d'ajouter un fichier ou fait une faute dans le message du dernier commit : git commit --amend
Revenir à un commit précédent La commande git reset permet de réinitialiser l'état du projet à un commit antérieur. Soyez prudent avec cette commande, surtout si vous avez déjà poussé vos modifications. git reset --hard <ID_du_commit> Une alternative plus sûre est git revert, qui crée un nouveau commit annulant les modifications d'un commit précédent sans réécrire l'historique. git revert <ID_du_commit>

Mettre de côté des modifications temporairement

Imaginez que vous êtes en plein milieu d'une fonctionnalité, mais qu'une urgence vous oblige à changer de branche. Vous ne voulez pas commiter un travail inachevé. git stash est la solution.

Sauvegarder vos modifications git stash Cette commande met de côté vos modifications et nettoie votre répertoire de travail.
Réappliquer les modifications sauvegardées Une fois revenu sur votre branche, récupérez votre travail : git stash pop

Le workflow avec les Pull Requests sur GitHub

Sur GitHub, la collaboration passe principalement par les Pull Requests (ou Merge Requests sur d'autres plateformes). C'est un mécanisme qui permet de proposer des modifications, de les discuter et de les valider avant de les intégrer au projet principal.

Le processus est simple :

Forkez le dépôt : Créez une copie personnelle du projet sur votre compte GitHub.
Clonez votre fork : Téléchargez votre version du projet sur votre machine.
Créez une branche : Isolez vos modifications dans une nouvelle branche.
Faites vos modifications : Codez, commitez et poussez votre branche sur votre fork.
Ouvrez une Pull Request : Depuis l'interface de GitHub, proposez de fusionner votre branche dans la branche main du projet original.
Discussion et revue de code : D'autres développeurs peuvent commenter votre code, suggérer des améliorations et finalement approuver les changements.
Fusion : Une fois approuvée, la Pull Request est fusionnée, et votre code fait officiellement partie du projet.

Rebase vs Merge : quelle stratégie choisir ?

git merge et git rebase résolvent le même problème : intégrer des changements d'une branche à une autre. Cependant, ils le font de manière très différente.

Critère	git merge	git rebase
Objectif	Combine l'historique de deux branches en créant un nouveau "commit de fusion".	Réécrit l'historique en déplaçant une branche pour qu'elle parte du sommet d'une autre.
Historique	Préservé et non-linéaire. Chaque fusion est visible, ce qui peut rendre l'historique complexe.	Linéaire et propre. L'historique ressemble à une ligne droite, comme si le travail avait été fait en série.
Facilité de lecture	Peut devenir difficile à suivre sur des projets avec de nombreuses fusions.	Très facile à lire et à comprendre, idéal pour naviguer dans l'historique.
Collaboration	Sûr pour les branches partagées (publiques), car il ne modifie pas l'historique existant.	Dangereux sur les branches partagées. Ne jamais rebaser une branche que d'autres personnes utilisent.
Cas d'usage	Idéal pour intégrer une branche de fonctionnalité dans la branche principale (`main`).	Parfait pour mettre à jour votre branche de fonctionnalité avec les derniers changements de `main` avant de créer une Pull Request.

En règle générale : utilisez rebase pour nettoyer votre historique local avant de partager votre travail, et utilisez merge pour intégrer le travail final dans une branche commune.