Révision de git « DevOps »
Crée un dépôt Git local dans le dossier courant :
git init
Affiche les fichiers modifiés, en attente de commit, ou non suivis:
git status
Ajouter des fichiers au staging (Prépare les fichiers pour le commit) :
git add . (nom_fich_modifOuAjoute)
git commit -m “feat: la commit”
Affiche l’historique et la liste des commits effectuées dans le projet :
git log / log --oneline (affiche les ID des commits)
Le staging :
En Git, le staging (ou zone de préparation, appelée aussi index)
Concrètement :
Quand tu modifies un fichier, il est dans l’espace de travail (working
directory).
Quand tu fais git add fichier, tu l’ajoutes à la zone de staging : tu dis à Git
« ce fichier est prêt à être enregistré ».
Quand tu fais git commit, Git prend ce qu’il y a dans le staging et le
sauvegarde définitivement dans l’historique du projet.
Exemple :
# Tu modifies deux fichiers :
nano index.html
nano style.css
# Tu veux committer seulement index.html pour le moment
git add index.html
# style.css n’est pas encore dans le staging
git commit -m "Mise à jour de l'accueil"
git reset & restore:
-Imaginons que tu as fait un commit, mais tu veux "revenir en arrière" pour le
corriger ou le modifier(git add et git commit ).
-Maintenant tu veux annuler ce commit de manière contrôlée. C’est là
qu’intervient git reset.
1. git reset --soft HEAD~1 :
Revenir en arrière d’un commit, mais garder tous les changements dans
le staging :
🧠 Tu annules juste le commit.
✅ Les fichiers restent "ajoutés" (git add déjà fait).
👍 Parfait si tu veux refaire le commit avec un autre message ou
ajouter un fichier oublié.
2. git reset --mixed HEAD~1 :
Tu annules le commit et tu retires les fichiers du staging, mais tu gardes
les modifications dans les fichiers.
🧠 Les changements sont encore là, mais comme si tu n’avais jamais fait
de git add.
✅ Tu dois refaire git add pour les re-stager.
👍 Pratique si tu veux choisir à nouveau quoi ajouter.
3. git reset --hard HEAD~1 :
Tu annules tout : le commit, le staging et même les modifications dans
les fichiers.
Tes fichiers reviennent à l’état avant le commit.
⚠️Les changements dans tes fichiers sont perdus (⚠️irréversibles sauf
si tu les avais sauvegardés ailleurs).
4. git restore --satged:
Retirer des fichiers de la zone de staging
Les branches :
🌿 Pourquoi utilise-t-on des branches ?
Les branches permettent de :
Tester des idées sans casser le projet principal.
Travailler en équipe sur plusieurs fonctionnalités en parallèle.
Garder une branche stable (main ou master) et faire des
expérimentations ailleurs.
💡 Exemple concret :
Tu as un site Web qui fonctionne (main)
Tu veux ajouter un nouveau formulaire
→ tu crées une branche formulaire
→ tu développes dessus sans toucher au reste
→ une fois prêt, tu fusionnes (merge) dans main.
git branch :
Affiche la liste des branches.
L'astérisque * indique sur quelle branche tu es actuellement.
git branch nouvelle-branche :
Crée une branche mais ne change pas de branche !
git checkout name_branch :
Tu changes de branche, tu passes de main à le nom de branche déclarée.
💡 Tout ce que tu vas faire (ajouts, commits) sera dans la branche
déclarée.
git checkout -b name_branch :
Crée la branche et se déplace dedans immédiatement.
Maintenant lorsqu’on termine de travailler sur une branche et on verifier que
tous est ajoutés et committés , on veut la fusionner avec la branche principale
main .
git checkout main # d'abord tu vas dans la branche cible
git merge name_branch # puis tu fusionnes la branche dev dedans
git rebase # le meme fonctionnement que merge ,
utilsé dans les projets perso , par contre merge pour collaborer avec les
autres
Le dépôt local et dépôt distant(Gitlab) :
git remote add origin https://gitlab.com/ton-nom-utilisateur/mon-
projet.git : Lier le dépôt local au dépôt distant(Gitlab) .
git remote -v : Pour vérifier si ton projet est lié.
git push -u origin main : Envoyer ton projet sur GitLab , Si ton dépôt local
est en master au lieu de main ou tu peux renommer master en main
par git branch -M main
Collaboration avec les autres :
git clone https://gitlab.com/ton-nom-utilisateur/mon-projet.git : pour
cloner le projet.
git pull origin main # récupérer la dernière version
git checkout -b ma-branche # créer une branche perso
# ... travail ...
git add .
git commit -m "ajout X"
git push origin ma-branche # pousse sa branche
pour travailler ensemble proprement.
Création de Merge Requests dans Gitlab :
🎯 Qu’est-ce qu’une Merge Request ?
Une Merge Request (ou MR) est une demande de fusion :
Tu veux fusionner ton travail (ta branche) dans la branche
principale du projet (souvent main).
C’est aussi un moyen de montrer ton travail, de le faire relire ou valider
par tes coéquipiers avant de l’intégrer au projet final.
🌐 Ensuite, sur GitLab :
1. Va sur ton projet sur GitLab
2. Dans le menu à gauche, clique sur “Merge Requests”
3. Clique sur “New merge request”
4. Choisis :
o Source branch : ta branche (ex. ajout-formulaire)
o Target branch : la branche principale (souvent main)
5. Clique sur "Compare branches and continue"
6. Donne un titre (ex. "Ajout d’un formulaire de contact")
7. Clique sur “Create merge request”
🤝 Et ensuite ?
Un autre membre (ou toi-même si tu travailles seule) :
Peut voir les changements ligne par ligne
Peut faire des commentaires
Peut accepter la fusion (bouton "Merge") si tout est bon
