Tu peux écrire du code sans Git & GitHub, bien sûr. Mais si tu veux collaborer proprement, retrouver une version stable en 30 secondes, ou faire relire ta feature avant de la livrer, ces outils deviennent vite indispensables. La bonne nouvelle : quelques commandes bien choisies couvrent 90% de ton quotidien. Voici un guide clair, pratique et concret pour maîtriser les bases (et un peu plus), du poste local jusqu’aux pull requests.
Git Versus GitHub : Comprendre Les Rôles Et Le Flux
Dépôts, Commits Et Historique
Git est un système de contrôle de version distribué. En clair, tu as toute l’historique du projet en local, avec des “commits” qui capturent des instantanés cohérents de ton code. Chaque commit a un identifiant (SHA), un auteur, une date et un message. Tu peux voyager dans le temps, comparer, bifurquer, revenir en arrière. Le dossier .git stocke tout.
GitHub (ou GitLab, Bitbucket) est une plateforme d’hébergement et de collaboration. Tu y pousses tes commits, tu ouvres des issues, des pull requests (PR), tu déclenches des actions CI/CD et tu publies des releases. Git fait la mécanique: GitHub fournit l’espace de travail partagé.
Workflow Local Versus Distant
Ton flux standard ressemble à ceci :
- Tu crées/changes une branche en local, tu codes, tu commits.
- Tu synchronises avec le dépôt distant (fetch/pull), puis tu pousses tes commits.
- Sur GitHub, tu ouvres une PR, demandes une revue, merges après validation, puis tu tires les changements à nouveau en local.
Astuce d’équipe : adopte une convention de branches (ex: main stable, develop d’intégration, feature/* pour les nouveautés) et des messages de commit clairs (impératifs courts).
Installation Et Configuration De Base
Installer Git Et Configurer L’Identité (git config)
Installe Git via ton gestionnaire (Windows: installer officiel, macOS: brew install git, Linux: apt/yum/pacman). Vérifie avec git --version.
Configure ton identité globale pour signer tes commits:
git config --global user.name "Ton Nom"git config --global user.email "ton@email"
Ajoute l’éditeur préféré: git config --global core.editor "code --wait" ou nano, vim. Liste tout: git config --list.
Générer Et Ajouter Une Clé SSH
Pour éviter de saisir ton mot de passe à chaque git push, utilise une clé SSH:
- Génère:
ssh-keygen -t ed25519 -C "ton@email" - Lance l’agent:
eval "$(ssh-agent -s)"puisssh-add ~/.ssh/id_ed25519 - Copie ta clé publique (
~/.ssh/id_ed25519.pub) dans GitHub: Settings > SSH and GPG keys.
Teste avec ssh -T git@github.com. Tu devrais voir un message de bienvenue.
Paramétrer Les Options Utiles (Aliases, Ligne De Commande)
Tu peux gagner du temps avec des alias et quelques réglages pratiques:
git config --global init.defaultBranch maingit config --global pull.rebase true(flux plus linéaire)git config --global fetch.prune true(nettoie les branches distantes supprimées)
Quelques alias malins:
git config --global alias.st statusgit config --global alias.co checkoutgit config --global alias.br branchgit config --global alias.lg "log --oneline --graph --decorate --all"
Référence utile: la doc officielle Git – documentation.
Commandes Locales Indispensables
Initialiser, Cloner Et Explorer (git init, git clone, git status)
Tu démarres un dépôt existant avec git clone <url> (SSH recommandé) ou tu initialises un projet vierge avec git init. Après avoir cloné/initié, git status devient ton tableau de bord: fichiers modifiés, suivis, non suivis, tout y est. Il t’indique quoi ajouter ou ignorer. Pense au .gitignore dès le début (dossiers node_modules/, .env, artefacts de build, etc.).
Mettre En Scène Et Valider (git add, git commit, .gitignore)
Le staging via git add te force à être intentionnel: git add -p te laisse choisir hunk par hunk. Valide ensuite avec git commit -m "message clair". Un bon message begin par un verbe à l’infinitif court: “Corriger bug d’auth”, “Ajouter pagination”. Pour ignorer des fichiers, crée un .gitignore au projet (ou global: ~/.config/git/ignore). Ajoute par exemple:
# Node / JS
node_modules/
dist/
.env*
Commits atomiques + messages précis = historique lisible et diff simple à relire.
Inspecter Les Modifications (git diff, git log, git show)
Avant de committer: git diff pour voir ce qui change. Après: git show <sha> affiche le détail d’un commit. git log --oneline --graph --decorate --all (ou ton alias lg) te donne une vue condensée et graphique de l’historique. Combine avec -p pour voir les patchs, ou --stat pour un résumé. Ces commandes t’évitent des PR surprises et te rendent autonome sur l’audit du code.
Branches Et Intégration Du Code
Créer Et Naviguer Entre Les Branches (git branch, git switch/checkout)
Travaille par branches pour isoler tes changements. Crée-en une depuis main:
git switch -c feature/login(ougit checkout -b feature/login)- Liste:
git branch(ajoute-apour voir les distantes) - Bascule:
git switch main
Nommer tes branches par fonctionnalité ou ticket (ex: feat/1234-upload) accélère la relecture et la traçabilité.
Fusionner En Sécurité (git merge, Résolution De Conflits)
Avant de merger, synchronise-toi: git fetch puis git merge origin/main dans ta branche de feature, ou git rebase main si l’équipe préfère un historique linéaire. En cas de conflits, Git marque les sections <<<<<<<, =======, >>>>>>>. Tu édites, testes, puis:
git add <fichiers_conflits>git merge --continue(ougit rebase --continuesi tu rebasais)
Teste localement après résolution. Un merge crée un commit de merge: c’est utile pour garder la trace du contexte d’intégration.
Réécrire Proprement (git rebase, git cherry-pick)
git rebase -i main te permet de réordonner, fusionner (squash) et réécrire les messages de commits avant d’ouvrir ta PR. Ça rend l’historique propre et pédagogique. Attention: réécrire l’historique partagé demande coordination (n’utilise pas --force à la légère sur des branches déjà poussées). git cherry-pick <sha> applique un commit précis sur ta branche actuelle, pratique pour porter un correctif urgent de main vers une release hotfix.
Travailler Avec Les Dépôts Distants Et GitHub
Configurer Les Remotes (origin, upstream)
Après un clone, origin pointe vers ton dépôt GitHub. Si tu as forké un projet, ajoute l’original comme upstream:
git remote add upstream git@github.com:org/projet.git- Vérifie:
git remote -v
Tu peux renommer une remote (git remote rename) ou en retirer une (git remote remove). Garde-les claires: origin pour ton fork, upstream pour la source.
Synchroniser Le Code (git fetch, git pull, git push)
git fetch télécharge les refs distantes sans modifier ta branche. git pull fait fetch + intégration (merge ou rebase suivant pull.rebase). Sur une feature, préfère: git fetch, puis git rebase origin/main pour rester à jour proprement. Pousse tes changements avec git push -u origin feature/login (le -u fixe la branche de suivi, pratique pour les futurs git push/git pull).
Collaborer Avec Les Pull Requests, Revues Et Protections
Sur GitHub, ouvre une PR depuis ta branche vers main (ou develop). Décris le “quoi/pourquoi”, lie l’issue (Fixes #123), ajoute des captures si utile. Sollicite des reviewers. Les “branch protections” (revue obligatoire, checks CI, interdiction de force-push) stabilisent la qualité. Les discussions, suggestions en ligne et règles de merge (“squash and merge”, “rebase and merge”) complètent un flux moderne. Référence: Créer une pull request sur GitHub.
Marquer Les Jalons (git tag, Releases)
Tague une version stable: git tag -a v1.2.0 -m "Release 1.2.0" puis git push origin v1.2.0. Utilise les tags annotés pour garder auteur/date/message. Sur GitHub, crée une Release à partir d’un tag, ajoute changelog et binaires si besoin. Les tags rendent les déploiements reproductibles et les rollbacks simples.
Annuler Et Récupérer Sans Perdre Son Calme
Revenir En Arrière Localement (git restore, git reset)
Tu as modifié un fichier par erreur ? git restore <fichier> annule les changements non indexés. Pour retirer du staging: git restore --staged <fichier>. Pour reculer la branche: git reset --hard <sha> replace HEAD, l’index et l’arborescence, dangereux si tu n’as pas tout poussé. Variante douce: git reset --mixed <sha> garde tes modifications dans le working directory.
Annuler Un Commit Public En Sécurité (git revert)
Sur une branche partagée, évite de réécrire l’historique. Utilise git revert <sha>: Git crée un nouveau commit qui annule les effets du précédent sans toucher à l’historique. Idéal pour corriger un mauvais merge déjà poussé.
Mettre De Côté Et Récupérer Son Travail (git stash)
Tu dois changer de branche sans committer ? git stash push -m "WIP: formulaire" range tes modifs de côté. Reviens plus tard avec git stash pop (applique et supprime) ou git stash apply (applique et garde). Liste-les avec git stash list. Combine avec des patchs ciblés: git stash push -p pour ne ranger qu’une partie.
No responses yet