- Home
- Catalogue de cours
- technologies numériques
- devops
- Introduction à GIT
-
Module 00 : Présentation de la formation
-
Module 01 : Introduction au versioning
-
Module 02 : Les bases de GIT
-
Les bases de GIT
12 min
-
TP-2 : code à récupérer
-
TP-2 : Les bases de GIT
03 min
-
TP-2 : [correction] initialisation du repo et premier commit – README
06 min
-
TP-2: [correction] gitignore
02 min
-
TP-2 : [correction] validation du gitignore
02 min
-
TP-2 : [correction] parcourir l’historique des commit
02 min
-
TP-2 : [correction] git tag
02 min
-
TP-2 : [correction] git alias
01 min
-
Les bases de GIT
-
Module 03 : Les branches GIT
-
Module 04 : Serveur GIT
-
Module 05 : Travail collaboratif
-
Travail collaboratif
07 min
-
TP-5 : Travail collaboratif
02 min
-
TP-5 : [correction] creation des utilisateurs sur gitlab
03 min
-
TP-5 : [correction] assignation des utilisateurs aux utilisateurs
03 min
-
TP-5 : [correction] creation du projet sur gitlab
03 min
-
TP-5 : [correction] contribution du developpeur partie 1
13 min
-
TP-5 : [correction] contribution du developpeur partie 2
10 min
-
TP-5 : [correction] résumé et suppression de l’environnement de travail
01 min
-
Travail collaboratif
-
Module 06 : Github
-
Module 07 : BONUS
-
Module 08 : Conclusion
Il y a quelque chose que je ne comprend pas :
– j’ai essayé de faire un merge de feature1 depuis feature2, puis de merge feature2 vers master et je vois bien le commit de feature1 contrairement à ce qui est dit dans la vidéo. Par contre, ça m’a créé un nouveau commit “Merge branch ‘feature1’ into ‘feature2′” en plus dans l’historique final.
– et deuxièmement, pourquoi ne pas faire un git rebase de feature2 depuis master si ça garde un historique propre ? J’ai l’impression qu’il y a une histoire de “fast-forward” mais je ne comprends pas car votre historique semble propre même avec un merge …
hello
pour repondre à tes questions:
1- en fait le merge normal crée un commit automatiquement de l’ensemble des modifications ce qui devrait faire perdre l’historique des modifications
2- attention, le merge ne garde pas mon historique mais crée un merge pour toutes mes modificaitons, en réalité quand je fais le base pour que les commit de ma branches features soient exactement repris à identique (comme sur la branche feature 2) afin de savoir exactement ce qui s’est passé.
En réalité le merge cache les commits faits sur le branche feature, dans certains cas c’est souhaitable mais dans d’autres cas on souhaite avoir l’historique.
Regardes un peu cette PR : https://github.com/diranetafen/cursus-devops/pull/12
Tu verras que la seule chose que s’a m’affiche c’est que le commit c’est la résultante d’un merge alors que plein de commits ont été fait par le contributeur qui ici est sami.
Donc si j’avais voulu garder l’historique des ces modifications j’aurai fait un rebase mais dans mon cas comme je suis le mainteneur du code je m’en fou un peu et c’est le resultat final qui m’intéresse
N’hésites pas si je n’ai pas été clair, merci pour tes questions
En fait, ce que je comprend pas c’est que dans la vidéo vous dites que si on “merge” la branche “feature1” dans “feature2”, alors le commit “add mobile phone in form” ne sera plus dans l’historique.
-> Hors si je fais ce merge, je vois toujours ce commit “add mobile phone in form” dans mon historique suivi de mon commit de merge…
-> Pourquoi ? il ne devrait pas y avoir que le commit de merge ?
Du coup, je suis encore plus perdu entre git merge, git merge (avec fast-forward) et rebase.
En fait on utilise que le merge et des fois le rebase
vous avez une bonne doc ici qui explique le mécanisme
https://www.google.com/url?sa=i&url=https%3A%2F%2Ffr.sawakinome.com%2Farticles%2Fsoftware%2Funassigned-2334.html&psig=AOvVaw0oGtZ1xqRREfYyJz6zF5nV&ust=1594853811138000&source=images&cd=vfe&ved=0CA0QjhxqFwoTCLCyzobtzeoCFQAAAAAdAAAAABAb