Ton premier repo : init, add, commit

Tu as compris pourquoi Git existe. Maintenant, on passe aux mains. Ce chapitre couvre le workflow que tu vas répéter des dizaines de fois par jour en tant que dev ou DevOps : initialiser un dépôt, préparer tes changements, les enregistrer proprement. C’est la base absolue — et pourtant, beaucoup de développeurs expérimentés la maîtrisent mal.

À la fin de ce cours, tu sauras créer un repo, structurer tes commits comme un pro, protéger ton projet avec un .gitignore, et annuler tes erreurs sans stress.

Pourquoi c’est important

Sans workflow Git solide, tu accumules de la dette technique invisible. Des commits fourre-tout, des secrets qui traînent dans l’historique, des modifications impossibles à tracer — tout ça finit par exploser quand tu travailles en équipe.

🔥 Cas réel : Un développeur junior push un .env contenant des clés AWS sur un repo public. En moins de 5 minutes, des bots automatisés détectent les clés et lancent des instances de minage crypto. Facture : 14 000 €. Un .gitignore configuré dès le premier commit aurait évité le drame.

Le workflow init → add → commit n’est pas qu’une séquence de commandes. C’est une discipline. Chaque commit bien structuré, c’est un point de sauvegarde fiable vers lequel tu peux revenir. Chaque commit bâclé, c’est une bombe à retardement.

Comprendre le workflow Git

Git organise ton travail en trois zones distinctes :

• Working directory — tes fichiers tels qu’ils sont sur le disque, avec tes modifications en cours
• Staging area — la zone de préparation où tu sélectionnes ce qui entrera dans le prochain commit
• Repository — l’historique des commits, la mémoire permanente du projet

Le flux est toujours le même : tu modifies des fichiers, tu choisis lesquels inclure avec git add, puis tu enregistres le snapshot avec git commit. Le staging area est la clé de voûte — c’est lui qui te permet de faire des commits chirurgicaux plutôt que de tout balancer en vrac.

💡 Tip DevOps : Pense au staging comme un plateau photo. Tu places les éléments que tu veux capturer (git add), tu vérifies le cadrage (git diff --staged), puis tu prends la photo (git commit). Cette étape intermédiaire te donne un contrôle total sur ce que tu enregistres.

Quand tu fais git init, Git crée un dossier .git/ caché à la racine de ton projet. Ce dossier contient tout : l’historique, la config, les métadonnées. Ton dépôt est autosuffisant — tu peux le copier sur une clé USB et tu emportes l’intégralité de l’historique avec toi.

⚠️ Attention : Supprimer le dossier .git/ efface tout l’historique de version. Les fichiers restent, mais Git ne les connaît plus. C’est irréversible.

Les commandes essentielles

Commençons par créer un projet et initialiser Git. La commande git init transforme n’importe quel dossier en dépôt Git :

mkdir mon-projet && cd mon-projet
git init
echo "# Mon Projet" > README.md
git status

git status est ta boussole. Tape-la avant et après chaque action. Elle te dit exactement où tu en es : fichiers modifiés, fichiers stagés, fichiers inconnus. Prends le réflexe.

Pour préparer un commit, utilise git add pour déplacer tes fichiers vers le staging :

git add README.md
git add -p app.py          # mode interactif : choisir ligne par ligne
git diff --staged           # vérifier ce qui va être commité

Le mode interactif git add -p est sous-utilisé. Il te montre chaque bloc de changements et te laisse choisir ce que tu inclus. Indispensable quand tu as fait plusieurs modifications logiquement distinctes dans le même fichier.

Une fois le staging prêt, enregistre le snapshot avec git commit :

git commit -m "feat: initialisation du projet avec README"
git log --oneline           # vérifier l'historique

🧠 À retenir : Chaque commit reçoit un hash SHA-1 unique qui garantit l’intégrité de l’historique. Si quelqu’un modifie un commit passé, tous les hashs suivants changent. Impossible de falsifier l’historique discrètement.

Le .gitignore est ton bouclier. Il empêche Git de tracker les fichiers indésirables : dépendances, secrets, fichiers temporaires. Crée-le toujours avant le premier commit :

cat > .gitignore << 'EOF'
node_modules/
venv/
.env
*.pyc
__pycache__/
.DS_Store
*.log
.terraform/
*.tfstate
EOF
git add .gitignore
git commit -m "chore: configuration du .gitignore"

Si tu as déjà commité un fichier que tu veux ignorer, ajouter la règle au .gitignore ne suffit pas. Il faut le retirer du tracking avec git rm --cached fichier.env — ça le supprime du suivi Git sans toucher au fichier sur ton disque.

Pour tes messages de commit, adopte la convention Conventional Commits : un préfixe qui indique le type de changement (feat:, fix:, docs:, chore:, refactor:). Cette convention permet de générer automatiquement des changelogs et de filtrer l’historique efficacement.

Enfin, Git te permet d’annuler à chaque étape. Avant le staging, git restore fichier revient à la version du dernier commit. Après le staging, git restore --staged fichier retire du staging sans perdre tes modifications. Après un commit, tu as plusieurs options :

git commit --amend -m "message corrigé"   # corriger le dernier commit
git reset --soft HEAD~1                    # défaire le commit, garder les changements
git revert abc1234                         # annuler un commit déjà partagé (safe)

💡 Tip DevOps : git reset réécrit l’historique — ne l’utilise jamais sur des commits déjà pushés. Pour annuler un commit partagé, git revert crée un nouveau commit d’annulation propre. C’est la différence entre effacer l’histoire et la corriger.

Cas concret : ton premier projet en entreprise

Tu arrives sur un nouveau projet. Voici le workflow type pour démarrer proprement :

mkdir api-utilisateurs && cd api-utilisateurs
git init
git config user.name "Ton Nom"
git config user.email "ton@email.com"

# 1. Sécuriser d'abord
cat > .gitignore << 'EOF'
.env
node_modules/
dist/
*.log
EOF
git add .gitignore
git commit -m "chore: configuration initiale .gitignore"

# 2. Documenter
echo "# API Utilisateurs\n\nService REST pour la gestion des comptes." > README.md
git add README.md
git commit -m "docs: ajout du README projet"

# 3. Coder
echo 'from flask import Flask\napp = Flask(__name__)' > app.py
git add app.py
git commit -m "feat: squelette de l'application Flask"

Trois commits séparés, chacun avec un objectif clair. Ton historique raconte une histoire lisible : d’abord la sécurité, puis la doc, puis le code. Un reviewer peut comprendre chaque étape sans ouvrir les fichiers.

🔥 Cas réel : En code review, rien n’énerve plus qu’un commit géant mélangeant feature, refactor et fix. Impossible à relire, impossible à reverter proprement. Les équipes performantes rejettent systématiquement ce type de PR. Un commit = un changement logique, toujours.

Pièges fréquents et comment les éviter

Le git add . systématique. C’est tentant parce que c’est rapide, mais ça pousse à des commits fourre-tout. Préfère ajouter les fichiers par groupe logique. Ton futur toi te remerciera quand il faudra git bisect un bug.

Le -am sur des fichiers nouveaux. Le raccourci git commit -am ne fonctionne que pour les fichiers déjà trackés. Les fichiers nouveaux (untracked) sont ignorés silencieusement. Piège classique des premières semaines.

Le .gitignore ajouté trop tard. Si tu commites un secret avant de configurer le .gitignore, il reste dans l’historique même après suppression. Des bots scannent GitHub en temps réel. Règle absolue : .gitignore = premier commit du projet.

⚠️ Attention : git restore sans --staged supprime définitivement tes modifications locales. Pas de récupération possible. Vérifie toujours avec git status avant d’utiliser cette commande.

La confusion git diff vs git diff --staged. Le premier montre ce qui n’est pas stagé. Le second montre ce qui va être commité. Confondre les deux provoque le classique “mais j’ai rien modifié !?” alors que tu avais déjà stagé.

🧠 À retenir : Si tu es perdu, git status te remet sur les rails. Sa sortie te dit même quelles commandes utiliser. C’est le meilleur ami du débutant comme du senior.

Exercice pratique

Mets tout en application dans cet exercice complet :

# Crée un projet avec .gitignore, README et un script
mkdir exercice-git && cd exercice-git
git init

# Commit 1 : .gitignore
echo -e "*.log\n.env\n__pycache__/" > .gitignore
git add .gitignore && git commit -m "chore: ajout du .gitignore"

# Commit 2 : README
echo "# Exercice Git" > README.md
git add README.md && git commit -m "docs: ajout du README"

# Commit 3 : code
echo 'print("Hello DevOps")' > main.py
git add main.py && git commit -m "feat: script principal"

# Vérifie ton historique
git log --oneline

# Maintenant, entraîne-toi à annuler :
# - Modifie main.py, puis annule avec git restore main.py
# - Modifie main.py, stage avec git add, puis unstage avec git restore --staged
# - Fais un mauvais commit, puis annule avec git revert HEAD

À retenir :

• Le workflow add → commit est le geste fondamental de Git — maîtrise-le parfaitement
• Le staging area te donne un contrôle chirurgical sur tes commits
• Un commit = un changement logique, avec un message clair en Conventional Commits
• Le .gitignore se configure avant le premier commit, pas après
• git status est ta boussole — tape-la tout le temps, sans modération
• git revert pour annuler du code partagé, git reset uniquement en local

➡️ Prochain chapitre : les branches et le merge — le cœur de Git pour travailler en parallèle sans se marcher sur les pieds.