Git et GitHub pour les débutants : Le guide complet pour enfin comprendre

Vous voyez tout le monde parler de Git et GitHub, vous avez essayé de comprendre, mais vous êtes perdu entre commit, push, pull, branch, et vous ne savez toujours pas pourquoi il faut "pousser" votre code ?

Si git add . suivi de git commit -m "fix" suivi de git push est votre seule connaissance de Git (et que vous ne comprenez même pas vraiment ce que ça fait)... cet article est fait pour vous.

Git n'est pas aussi compliqué qu'il y paraît. Une fois que vous comprenez les concepts de base, tout devient logique. Et je vais vous expliquer ça simplement, sans jargon technique inutile.

Dans ce guide, on va apprendre Git en pratique, avec des exemples concrets et des situations réelles que vous allez rencontrer.

Ce que vous allez apprendre :

• C'est quoi Git et pourquoi c'est indispensable

• La différence entre Git et GitHub (oui, c'est pas pareil !)

• Les commandes essentielles expliquées simplement

• Les branches : pourquoi et comment

• Collaborer avec d'autres développeurs

• Résoudre les problèmes courants (conflits, erreurs)

• Les bonnes pratiques pour ne pas galérer

Allez, on démarre de zéro ! 🚀

Partie 1 : Comprendre Git (la théorie simple)

C'est quoi Git, concrètement ?

Imaginez que vous écrivez un roman. Chaque jour, vous modifiez des chapitres, ajoutez des personnages, changez des dialogues. Parfois, vous voudriez revenir à une version précédente parce que vos modifications ne vous plaisent pas. Parfois, vous voulez tester une fin alternative sans perdre la version originale.

Git, c'est exactement ça pour votre code.

Git est un système de contrôle de version. Il garde une trace de chaque modification de vos fichiers, comme un historique complet de votre projet.

Avec Git, vous pouvez :

• Prendre des "photos" (snapshots) de votre code à différents moments

• Revenir à n'importe quelle version précédente

• Créer des versions parallèles (branches) pour tester des idées

• Collaborer avec d'autres sans tout casser

• Voir exactement qui a modifié quoi et quand

Git vs GitHub : Quelle différence ?

Grosse confusion de débutant : Git ≠ GitHub !

Git :

• Logiciel installé sur votre ordinateur

• Fonctionne en local

• Existe depuis 2005, créé par Linus Torvalds (créateur de Linux)

• Gratuit et open source

GitHub :

• Site web sur Internet (github.com)

• Héberge vos projets Git en ligne

• Permet de collaborer facilement

• Ajoute des fonctionnalités sociales (issues, pull requests, etc.)

• Appartient à Microsoft

• Gratuit pour les projets publics

Analogie :

• Git = Word (le logiciel sur votre PC)

• GitHub = Google Drive (où vous stockez et partagez vos documents)

Il existe aussi des alternatives à GitHub : GitLab, Bitbucket, Gitea, etc. Mais GitHub est le plus populaire.

Les concepts clés à comprendre

Repository (repo) : Le dossier de votre projet qui contient tout l'historique Git. C'est votre projet + son historique complet.

Commit : Une "photo" de votre code à un moment donné. Chaque commit a :

• Un message qui décrit les changements

• Un identifiant unique (hash)

• La date et l'auteur

Branch (branche) : Une version parallèle de votre code. La branche principale s'appelle main (ou master sur les vieux repos).

Remote : La version en ligne de votre repo (sur GitHub, GitLab, etc.).

Clone : Télécharger un repo depuis Internet vers votre ordinateur.

Pull : Récupérer les dernières modifications depuis le remote.

Push : Envoyer vos modifications locales vers le remote.

Gardez ces définitions en tête, on va les utiliser tout de suite en pratique !

Partie 2 : Installation et configuration

Installer Git

Linux (Alma, Ubuntu, Debian) :

# Alma Linux / Rocky / RHEL
sudo dnf install git

# Ubuntu / Debian
sudo apt install git

# Vérifier l'installation
git --version

macOS :

# Avec Homebrew (recommandé)
brew install git

# Ou télécharger depuis git-scm.com

Windows :

• Téléchargez Git depuis https://git-scm.com

• Installez avec les options par défaut

• Utilisez "Git Bash" pour les commandes

Configuration initiale (IMPORTANT !)

Avant tout, dites à Git qui vous êtes :

# Votre nom (sera visible dans les commits)
git config --global user.name "Votre Nom"

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

# Vérifier la config
git config --list

Pourquoi c'est important ? Chaque commit que vous faites sera signé avec ces infos. Si vous collaborez, les autres verront qui a fait quoi.

Configuration optionnelle mais utile

# Éditeur par défaut (nano, vim, code, etc.)
git config --global core.editor "nano"

# Couleurs dans le terminal (plus lisible)
git config --global color.ui auto

# Branche par défaut "main" au lieu de "master"
git config --global init.defaultBranch main

# Sauvegarde auto des identifiants (pratique)
git config --global credential.helper store

Partie 3 : Créer votre premier repository

Scénario 1 : Démarrer un nouveau projet

Vous créez un projet de zéro et voulez utiliser Git.

# 1. Créer un dossier pour votre projet
mkdir mon-super-projet
cd mon-super-projet

# 2. Initialiser Git
git init

# Vous verrez : "Initialized empty Git repository in..."

# 3. Vérifier
ls -la
# Vous verrez un dossier caché .git (c'est là que Git stocke tout)

Créons quelques fichiers :

# Créer un fichier
echo "# Mon Super Projet" > README.md
echo "print('Hello World')" > app.py

# Voir l'état
git status

Vous verrez quelque chose comme :

On branch main
No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md
    app.py

nothing added to commit but untracked files present

Traduction : Git voit ces fichiers mais ne les suit pas encore.

Les trois zones de Git

Avant de continuer, comprenons les 3 zones :

1. Working Directory : Votre dossier avec vos fichiers (ce que vous voyez)

2. Staging Area (Index) : Zone de préparation avant commit

3. Repository : L'historique des commits

Le workflow :

Working Directory → (git add) → Staging → (git commit) → Repository

Premier commit

# 1. Ajouter les fichiers à la staging area
git add README.md app.py
# Ou tout ajouter d'un coup :
git add .

# 2. Vérifier ce qui est staged
git status
# Vous verrez les fichiers en vert (prêts à être commités)

# 3. Créer le commit
git commit -m "Premier commit : ajout README et app.py"

# 4. Voir l'historique
git log

Félicitations ! 🎉 Vous venez de créer votre premier commit !

Scénario 2 : Cloner un projet existant

Vous voulez travailler sur un projet déjà sur GitHub.

# Cloner un repo
git clone https://github.com/username/nom-du-repo.git

# Aller dans le dossier cloné
cd nom-du-repo

# Voir l'historique
git log

Exemple concret :

# Cloner un projet populaire (Flask par exemple)
git clone https://github.com/pallets/flask.git
cd flask
git log --oneline

Partie 4 : Le workflow de base

Voici ce que vous allez faire 90% du temps :

1. Modifier des fichiers

# Éditer un fichier
nano app.py
# Ajoutez du code, sauvegardez

2. Voir ce qui a changé

# Statut général
git status

# Voir les différences (diff)
git diff
# Ça montre ligne par ligne ce qui a changé
# + = ajouté, - = supprimé

3. Ajouter à la staging area

# Ajouter un fichier spécifique
git add app.py

# Ajouter plusieurs fichiers
git add app.py utils.py

# Ajouter tout
git add .

# Ajouter tous les fichiers modifiés (pas les nouveaux)
git add -u

# Mode interactif (choisir ce qu'on ajoute)
git add -p

4. Commit

# Commit avec message
git commit -m "Ajout de la fonction de connexion"

# Commit avec message détaillé
git commit
# Ça ouvre votre éditeur pour un message plus long

Messages de commit : les bonnes pratiques

✅ BON :

git commit -m "Fix bug de validation email"
git commit -m "Add user authentication system"
git commit -m "Refactor database connection logic"

❌ MAUVAIS :

git commit -m "fix"
git commit -m "changes"
git commit -m "test"
git commit -m "azerty"
git commit -m "fzfzefze"  # Oui, on voit ça vraiment 😅

Règles d'or :

• Commencez par un verbe à l'impératif (Add, Fix, Update, Remove)

• Soyez descriptif mais concis

• En anglais de préférence (standard de l'industrie)

• Une ligne suffit pour les petits changements

5. Voir l'historique

# Historique complet
git log

# Version compacte (une ligne par commit)
git log --oneline

# Avec un graphique des branches
git log --oneline --graph --all

# Les 5 derniers commits
git log -5

# Historique d'un fichier spécifique
git log app.py

# Rechercher dans les commits
git log --grep="bug"

6. Modifier le dernier commit

Oups, vous avez oublié un fichier ou fait une typo dans le message ?

# Modifier le dernier commit
git add fichier-oublie.py
git commit --amend

# Ou juste changer le message
git commit --amend -m "Nouveau message corrigé"

⚠️ Attention : Ne faites ça que si vous n'avez PAS encore pushé !

Partie 5 : Travailler avec GitHub

Créer un compte GitHub

1. Allez sur https://github.com

2. Sign up (gratuit)

3. Confirmez votre email

Créer un repository sur GitHub

1. Cliquez sur le + en haut à droite → New repository

2. Nom du repo : mon-super-projet

3. Description (optionnelle)

4. Public ou Private (vous choisissez)

5. NE COCHEZ PAS "Initialize with README" (on a déjà fait ça en local)

6. Create repository

GitHub vous donne ensuite des instructions. On va les suivre.

Connecter votre repo local à GitHub

Si vous avez déjà un repo local (notre cas) :

# Ajouter le remote (lien vers GitHub)
git remote add origin https://github.com/votre-username/mon-super-projet.git

# Vérifier
git remote -v

# Pousser votre code
git push -u origin main

Décomposons :

• origin : nom du remote (par convention, toujours "origin" pour le principal)

• -u : set upstream (lie votre branche locale main à origin/main)

• main : nom de la branche

La première fois, Git va vous demander vos identifiants GitHub.

Authentification GitHub

Avant août 2021 : Mot de passe OK
Maintenant : Mot de passe refusé, il faut un Personal Access Token

Créer un token

1. GitHub → Settings (votre profil) → Developer settings

2. Personal access tokens → Tokens (classic)

3. Generate new token

4. Nom : "Mon PC de dev"

5. Expiration : 90 days (ou No expiration si vous voulez)

6. Scopes : Cochez repo (accès complet aux repos)

7. Generate token

8. COPIEZ LE TOKEN (vous ne le reverrez plus !)

Utiliser le token

# Au lieu du mot de passe, collez le token

# Pour ne pas le retaper à chaque fois :
git config --global credential.helper store
# Après la première fois, Git le sauvegarde

Alternative (mieux) : SSH

# Générer une clé SSH si vous n'en avez pas
ssh-keygen -t ed25519 -C "votre.email@example.com"

# Afficher la clé publique
cat ~/.ssh/id_ed25519.pub

# Copier cette clé

Sur GitHub :

1. Settings → SSH and GPG keys

2. New SSH key

3. Collez votre clé publique

4. Add SSH key

Maintenant, utilisez l'URL SSH :

git remote set-url origin git@github.com:votre-username/mon-super-projet.git

Fini les tokens !

Le cycle quotidien : Modifier → Commit → Push

# 1. Modifiez vos fichiers
nano app.py

# 2. Voir ce qui a changé
git status
git diff

# 3. Add et commit
git add .
git commit -m "Add login feature"

# 4. Push vers GitHub
git push

# Votre code est maintenant sur GitHub !

Récupérer les modifications (Pull)

Si vous travaillez sur plusieurs machines, ou avec d'autres personnes :

# Récupérer les dernières modifications
git pull

# Ça fait en réalité deux choses :
# git fetch (télécharge les changements)
# git merge (fusionne avec votre code local)

Workflow multi-machines :

# Sur votre PC de bureau
git add .
git commit -m "Work from desktop"
git push

# Plus tard, sur votre laptop
git pull  # Récupère le travail du desktop
# Vous avez maintenant le même code !

Partie 6 : Les branches (le vrai pouvoir de Git)

Pourquoi des branches ?

Imaginez : vous travaillez sur une fonctionnalité qui va prendre 3 jours. Pendant ce temps, vous découvrez un bug urgent à corriger. Comment faire sans tout mélanger ?

Les branches !

Une branche, c'est une version parallèle de votre code. Vous pouvez :

• Développer une nouvelle fonctionnalité sans toucher au code principal

• Corriger un bug sans impacter votre développement en cours

• Expérimenter sans risque

• Collaborer sans se marcher dessus

Créer et utiliser des branches

# Voir les branches
git branch
# * main (l'étoile = branche actuelle)

# Créer une nouvelle branche
git branch feature-login

# Changer de branche
git checkout feature-login
# Ou en une seule commande :
git checkout -b feature-login

# Vérifier
git branch
#   main
# * feature-login

# Maintenant, tout ce que vous faites est sur feature-login
echo "def login(): pass" >> app.py
git add .
git commit -m "Start login feature"

# Retour sur main
git checkout main

# Vérifiez app.py : pas de login() ici !
cat app.py

C'est magique ! En changeant de branche, vos fichiers changent instantanément.

Fusionner des branches (Merge)

Une fois votre fonctionnalité terminée, vous voulez l'intégrer dans main.

# 1. Assurez-vous d'être sur main
git checkout main

# 2. Fusionner feature-login dans main
git merge feature-login

# 3. Si tout va bien :
# "Fast-forward" ou "Merge made by..."

# 4. Supprimer la branche (optionnel)
git branch -d feature-login

# 5. Push
git push

Les conflits (et comment les résoudre)

Scénario : Vous et un collègue avez modifié la même ligne du même fichier.

git merge feature-autre-truc

# Git dit :
# CONFLICT (content): Merge conflict in app.py
# Automatic merge failed; fix conflicts and then commit the result.

Pas de panique ! Ouvrez le fichier :

def hello():
<<<<<<< HEAD
    print("Hello from main")
=======
    print("Hello from feature")
>>>>>>> feature-autre-truc

Explication des marqueurs :

• <<<<<<< HEAD : Votre version (branche actuelle)

• ======= : Séparateur

• >>>>>>> feature-autre-truc : L'autre version

Résoudre :

1. Éditez le fichier, gardez ce que vous voulez :

def hello():
    print("Hello from main and feature")

2. Supprimez les marqueurs de conflit

3. Add et commit :

git add app.py
git commit -m "Resolve conflict in hello function"

Astuce : Utilisez un outil graphique (VS Code affiche les conflits joliment).

Workflow de branches recommandé

GitHub Flow (simple et efficace) :

main (toujours déployable)
  ├─ feature-1 (nouvelle fonctionnalité)
  ├─ bugfix-urgent (correction de bug)
  └─ feature-2 (autre fonctionnalité)

Règles :

• main est toujours stable et déployable

• Une branche = une fonctionnalité ou un bug

• Nom de branche descriptif : feature-user-auth, bugfix-email-validation

• Merge dans main quand c'est terminé et testé

• Supprimez les branches mergées

# Créer une branche pour une feature
git checkout -b feature-dark-mode

# Développer...
git add .
git commit -m "Add dark mode toggle"
git commit -m "Style dark mode theme"

# Push la branche
git push -u origin feature-dark-mode

# Sur GitHub : créer une Pull Request
# Après review et tests : merge
# Localement :
git checkout main
git pull
git branch -d feature-dark-mode

Partie 7 : Collaborer sur GitHub

Forker un projet

Vous voulez contribuer à un projet open source ?

1. Sur GitHub, cliquez sur Fork (en haut à droite)

2. Vous avez maintenant votre copie du projet

3. Clonez VOTRE fork :

git clone https://github.com/VOTRE-USERNAME/projet-forke.git
cd projet-forke

4. Ajoutez l'original comme "upstream" :

git remote add upstream https://github.com/AUTEUR-ORIGINAL/projet-original.git
git remote -v
# origin : votre fork
# upstream : l'original

Créer une Pull Request (PR)

Scénario : Vous avez fixé un bug dans un projet open source.

# 1. Créer une branche
git checkout -b fix-typo-readme

# 2. Faire vos modifications
nano README.md

# 3. Commit
git add README.md
git commit -m "Fix typo in installation section"

# 4. Push vers VOTRE fork
git push origin fix-typo-readme

Sur GitHub :

1. Allez sur votre fork

2. Vous verrez : "fix-typo-readme had recent pushes"

3. Cliquez sur "Compare & pull request"

4. Décrivez vos modifications

5. Create pull request

Le mainteneur du projet peut maintenant :

• Reviewer votre code

• Demander des modifications

• Accepter et merger

• Refuser

Rester à jour avec l'upstream

# Récupérer les changements de l'original
git fetch upstream

# Fusionner dans votre main local
git checkout main
git merge upstream/main

# Push vers votre fork
git push origin main

Les issues

Sur GitHub, les issues = bugs, questions, demandes de fonctionnalités.

Créer une issue :

1. Onglet "Issues"

2. "New issue"

3. Titre clair

4. Description détaillée

5. Labels (bug, enhancement, question, etc.)

Lier un commit à une issue :

git commit -m "Fix login bug (fixes #42)"
# #42 = numéro de l'issue
# "fixes" = ferme automatiquement l'issue quand c'est mergé

Partie 8 : Commandes avancées (mais utiles)

Annuler des modifications

Fichier modifié, pas encore staged :

# Annuler les modifications
git restore app.py
# Ou l'ancienne syntaxe :
git checkout -- app.py

Fichier staged (déjà git add) :

# Unstage (retirer de la staging area)
git restore --staged app.py
# Ou :
git reset app.py

Annuler le dernier commit (local) :

# Garder les modifications
git reset --soft HEAD~1

# Annuler tout (DANGER !)
git reset --hard HEAD~1

Annuler un commit déjà pushé :

# Créer un nouveau commit qui annule
git revert abc123  # abc123 = hash du commit à annuler

Stash (mettre de côté temporairement)

Scénario : Vous travaillez sur une feature, un bug urgent arrive. Vous devez changer de branche mais vous n'êtes pas prêt à commit.

# Mettre de côté vos modifications
git stash

# Changer de branche, corriger le bug, etc.
git checkout main
# ...

# Revenir et récupérer vos modifications
git checkout feature-en-cours
git stash pop

# Voir ce qui est stashé
git stash list

# Appliquer un stash spécifique
git stash apply stash@{0}

Voir qui a modifié quoi (Blame)

# Qui a écrit chaque ligne ?
git blame app.py

# Version plus lisible
git blame -L 10,20 app.py  # Lignes 10 à 20 seulement

Chercher dans l'historique

# Chercher "login" dans tous les commits
git log -S "login"

# Chercher dans les messages de commit
git log --grep="fix bug"

# Voir les changements d'un commit spécifique
git show abc123

Cherry-pick (appliquer un commit spécifique)

# Appliquer le commit abc123 sur la branche actuelle
git cherry-pick abc123

Rebase (réécrire l'historique)

⚠️ Avancé, à utiliser avec précaution !

# Remettre votre branche sur main à jour
git checkout feature-branch
git rebase main

# Rebase interactif (modifier l'historique)
git rebase -i HEAD~3  # 3 derniers commits

Quand utiliser rebase vs merge ?

• Merge : Historique complet, plus sûr

• Rebase : Historique linéaire, plus propre

Règle d'or : Ne rebase JAMAIS des commits déjà pushés et partagés !

Partie 9 : Le fichier .gitignore

Certains fichiers ne doivent jamais être dans Git :

• Mots de passe, clés API (.env)

• Dépendances (node_modules/, venv/)

• Fichiers générés (*.pyc, __pycache__/)

• Fichiers système (.DS_Store, Thumbs.db)

Créer un .gitignore

nano .gitignore

Exemple pour un projet Python/Flask :

# Environnements virtuels
venv/
env/
ENV/

# Fichiers Python compilés
*.pyc
__pycache__/
*.pyo
*.pyd

# Fichiers de configuration locaux
.env
.env.local
instance/

# Bases de données
*.db
*.sqlite
*.sqlite3

# Logs
*.log

# IDE
.vscode/
.idea/
*.swp
*.swo

# OS
.DS_Store
Thumbs.db

# Backups
*.bak
*.backup

Exemple pour un projet Node.js :

# Dependencies
node_modules/
npm-debug.log
yarn-error.log

# Production
build/
dist/

# Environment
.env
.env.local

# IDE
.vscode/
.idea/

# OS
.DS_Store

Ajouter le .gitignore au repo :

git add .gitignore
git commit -m "Add .gitignore"

Templates .gitignore : GitHub a des templates pour chaque langage : https://github.com/github/gitignore

Ignorer un fichier déjà tracké

Oups, vous avez déjà commité .env !

# Retirer du tracking (mais garder le fichier localement)
git rm --cached .env

# Ajouter à .gitignore
echo ".env" >> .gitignore

# Commit
git add .gitignore
git commit -m "Remove .env from tracking"
git push

Partie 10 : Bonnes pratiques et workflow

Commits

✅ DO :

• Commits fréquents et petits

• Un commit = une modification logique

• Messages clairs et descriptifs

• Tester avant de commit

❌ DON'T :

• Commits géants avec 50 fichiers

• Messages vagues ("fix", "update")

• Commiter du code qui ne compile pas

• Commiter des secrets (.env, tokens)

Branches

✅ DO :

• Une branche par feature/bugfix

• Noms descriptifs (feature-user-auth, bugfix-email-validation)

• Supprimer les branches mergées

• Merge régulièrement main dans votre branche (rester à jour)

❌ DON'T :

• Tout développer sur main

• Garder des branches ouvertes pendant des mois

• Noms vagues (test, test2, new-branch)

Pull Requests

✅ DO :

• Description claire de ce que ça fait

• Lier aux issues concernées

• Petit et focalisé

• Tests passent

• Code review avant merge

❌ DON'T :

• PR géantes difficiles à review

• Pas de description

• Merger sans review

Sécurité

🔒 JAMAIS dans Git :

• Mots de passe

• Clés API

• Tokens

• Certificats

• Fichiers .env

• Données sensibles

Si vous avez accidentellement commité un secret :

1. CHANGEZ LE SECRET immédiatement !

2. Retirez-le de Git :

git rm --cached .env
git commit -m "Remove leaked secrets"
git push --force

3. Pour vraiment l'effacer de l'historique (avancé) :

# BFG Repo-Cleaner
java -jar bfg.jar --delete-files .env mon-repo.git

Partie 11 : Résoudre les problèmes courants

"I messed up, help!"

J'ai modifié un fichier et je veux annuler :

git restore fichier.txt

J'ai fait git add par erreur :

git restore --staged fichier.txt

Je veux annuler mon dernier commit (pas encore pushé) :

git reset --soft HEAD~1
# Vos modifications sont toujours là

J'ai fait un mauvais commit ET pushé :

git revert HEAD
git push

Je veux revenir à un commit précédent :

# Voir l'historique
git log --oneline

# Revenir (ATTENTION : perte de tout après)
git reset --hard abc123  # abc123 = hash du commit

# Si déjà pushé (créer un nouveau commit qui annule)
git revert abc123

J'ai mergé la mauvaise branche :

# Annuler le merge (pas encore pushé)
git reset --hard HEAD~1

# Si déjà pushé
git revert -m 1 HEAD

Je me suis trompé de branche pour mes commits :

# Vous êtes sur main, vous vouliez être sur feature

# Créer la branche feature avec vos commits
git branch feature

# Revenir main en arrière
git reset --hard origin/main

# Aller sur feature
git checkout feature
# Vos commits sont là !

Erreurs fréquentes

"fatal: not a git repository" → Vous n'êtes pas dans un dossier Git. Faites git init ou cd dans le bon dossier.

"error: failed to push some refs" → Quelqu'un a pushé avant vous. Faites git pull puis git push.

"Your branch is ahead of 'origin/main' by X commits" → Vous avez des commits locaux pas encore pushés. Faites git push.

"CONFLICT (content): Merge conflict" → Résolvez les conflits dans les fichiers, puis git add et git commit.

"Permission denied (publickey)" → Problème SSH. Vérifiez votre clé SSH sur GitHub.

"fatal: refusing to merge unrelated histories"

git pull origin main --allow-unrelated-histories

Partie 12 : Aller plus loin

Alias Git (raccourcis)

Créez vos propres commandes courtes :

# Dans ~/.gitconfig ou via commandes

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'
git config --global alias.visual 'log --oneline --graph --all'

# Maintenant :
git co main  # au lieu de git checkout main
git st       # au lieu de git status
git visual   # joli graphique

GUI pour Git

Si le terminal vous intimide :

VS Code :

• Intégration Git native

• Visualisation des diffs

• Gestion des conflits intuitive

GitHub Desktop :

• Application officielle GitHub

• Simple et visuelle

• Parfait pour débuter

GitKraken :

• Interface graphique puissante

• Visualisation des branches en arbre

• Gratuit pour les projets publics

Sourcetree :

• Gratuit et complet

• Windows et Mac

Mais... apprendre le terminal reste important ! Les GUI ont leurs limites.

GitHub Actions (CI/CD)

Automatisez des tâches à chaque push :

.github/workflows/test.yml :

name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          pip install -r requirements.txt

      - name: Run tests
        run: |
          pytest

À chaque push, GitHub lance automatiquement vos tests ! 🚀

GitHub Pages

Hébergez un site web gratuitement :

# Créer une branche gh-pages
git checkout -b gh-pages

# Pousser votre site
git push origin gh-pages

Votre site sera sur : https://votre-username.github.io/nom-repo/

README.md parfait

Un bon README contient :

# Nom du Projet

Description courte et accrocheuse

## 🚀 Installation

```bash
git clone https://github.com/votre-user/projet.git
cd projet
pip install -r requirements.txt
```

## 💻 Utilisation

```bash
python app.py
```

## 🤝 Contribuer

Les contributions sont bienvenues !

1. Fork le projet

2. Créez votre branche (`git checkout -b feature/AmazingFeature`)

3. Commit (`git commit -m 'Add some AmazingFeature'`)

4. Push (`git push origin feature/AmazingFeature`)

5. Ouvrez une Pull Request

## 📝 License

MIT

Cheat Sheet : Commandes essentielles

Imprimez-moi et gardez-moi sous la main ! 📄

Configuration

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

Démarrer

git init                           # Nouveau repo
git clone URL                      # Cloner un repo

Workflow de base

git status                         # Voir l'état
git add fichier                    # Stage un fichier
git add .                          # Stage tout
git commit -m "message"            # Commit
git push                           # Envoyer vers remote
git pull                           # Récupérer depuis remote

Branches

git branch                         # Lister les branches
git branch nom                     # Créer une branche
git checkout nom                   # Changer de branche
git checkout -b nom                # Créer et changer
git merge nom                      # Fusionner une branche
git branch -d nom                  # Supprimer une branche

Historique

git log                            # Historique complet
git log --oneline                  # Historique compact
git log --graph --all              # Avec graphique
git diff                           # Voir les changements
git show abc123                    # Voir un commit

Annuler

git restore fichier                # Annuler modifications
git restore --staged fichier       # Unstage
git reset --soft HEAD~1            # Annuler dernier commit
git revert abc123                  # Annuler un commit (safe)

Remote

git remote -v                      # Voir les remotes
git remote add origin URL          # Ajouter un remote
git push -u origin main            # Premier push
git fetch                          # Télécharger (pas merge)

Utilitaires

git stash                          # Mettre de côté
git stash pop                      # Récupérer
git blame fichier                  # Qui a modifié quoi
git tag v1.0                       # Créer un tag

Conclusion : Vous êtes prêt !

Félicitations ! Vous connaissez maintenant les bases (et plus) de Git et GitHub.

Ce qu'on a couvert :

• Les concepts fondamentaux (repo, commit, branch, remote)

• Le workflow quotidien (add, commit, push, pull)

• Les branches et la collaboration

• GitHub et les Pull Requests

• Résoudre les problèmes courants

• Les bonnes pratiques

Les commandements du Git-fu :

1. Commit souvent, push régulièrement

2. Toujours pull avant de push

3. Une branche par feature

4. Messages de commit descriptifs

5. Jamais de secrets dans Git

6. Tester avant de commit

7. Lire les messages d'erreur (ils aident !)

8. git status est votre ami

9. Backup avant les commandes destructives

10. La pratique rend parfait

Rappelez-vous :

• Vous allez faire des erreurs (on en fait tous !)

• Git permet presque toujours de revenir en arrière

• Google est votre ami ("git how to...")

• La communauté est bienveillante, posez des questions !

Prochaines étapes :

1. Créez un repo pour un de vos projets

2. Faites des commits réguliers

3. Essayez les branches

4. Contribuez à un projet open source

5. Pratiquez, pratiquez, pratiquez !

Git, c'est comme le vélo : au début c'est dur, puis ça devient naturel. Dans quelques semaines, vous ferez des git add, git commit, git push sans même y penser.

Vous avez des questions sur Git ? Une commande qui vous bloque ? Partagez en commentaire ! Et si ce guide vous a aidé, partagez-le avec d'autres devs qui débutent avec Git.

Bon Git, et que les commits soient avec vous ! 🐙✨

Articles connexes :

• Transférer des fichiers entre local et serveur

• Commandes Linux essentielles