Đoạn xem trước bài giảng

À quoi sert Git exactement - et pourquoi il est indispensable pour trouver un emploi

Nous ne commencerons pas par les commandes, mais par la difficulté : nous verrons à quoi ressemble le développement sans contrôle de version - avec des dossiers 'projet_final_2', 'projet_final_VRAIMENT_FINAL' et la peur de supprimer le mauvais fichier. Vous comprendrez quel problème précis Git résout, pourquoi il est devenu un standard de l'industrie et ce que les employeurs recherchent exactement lorsqu'ils examinent votre profil GitHub.

système de contrôle de version historique des modifications architecture distribuée

Bạn sẽ học gì trong bài giảng này

Vous serez capable d'expliquer à un recruteur ou un employeur à quoi sert le contrôle de version - avec vos propres mots, sans définitions apprises par cœur.
Vous comprendrez en quoi le modèle distribué de Git diffère fondamentalement des systèmes centralisés et pourquoi c'est important en pratique.
Vous prendrez conscience des compétences spécifiques en Git qui sont évaluées lors des processus de recrutement.

Phần đầu bài giảng

« VRAIMENT_FINAL » — ce n'est pas votre faute

Dossiers familiers : projet_v2, final_modifs
Tout le monde fait comme ça sans système de contrôle de version
Ce n'est pas le chaos — c'est du versionnage primitif
Votre premier pas vers la compréhension de Git

Lorsque vous voyez sur votre ordinateur des dossiers nommés « projet_v2 » ou « final_modifs_a_faire », ne vous en voulez pas pour ce manque d'organisation. Absolument tout le monde fait la même chose lorsqu'il doit gérer différentes versions de fichiers sans outil dédié. Des étudiants aux développeurs expérimentés — tout le monde passe par cette étape avant de découvrir les systèmes de contrôle de version. En réalité, vous avez déjà inventé le versionnage — simplement sous sa forme la plus basique. Ce n'est pas du chaos, mais une étape naturelle vers la compréhension de l'utilité de Git.

La peur de supprimer : quand l'historique n'existe que dans votre tête

L'historique des modifications n'existe que dans votre tête
La peur de supprimer quelque chose d'important
40 versions d'un fichier — où est la bonne ?
La mémoire ne s'adapte pas et ne fait pas de sauvegardes

Imaginez que vous écrivez un roman et que chaque jour vous enregistrez une nouvelle copie : « roman_brouillon », « roman_FINAL », « roman_FINAL_corrections_editeur ». Au bout d'un mois, vous avez quarante fichiers et vous ne vous souvenez plus dans lequel se trouvait cette excellente version du troisième chapitre. Le principal problème de cette approche est que l'historique des modifications n'existe que dans votre tête — or la mémoire humaine est imparfaite et ne fait pas de sauvegardes. C'est pourquoi vous avez peur de supprimer les anciennes versions, même quand elles sont clairement obsolètes.

Un développeur brouillon, une équipe en perdition

Le chaos est inévitable en équipe
Des mails avec des archives des versions actuelles
Quelqu'un écrase les modifications des autres
Un outil de collaboration est nécessaire

Quand vous travaillez seul, un système de dossiers avec différentes versions peut sembler fonctionner. Mais dès qu'une deuxième personne rejoint le projet, le vrai chaos commence. Des modifications sont accidentellement écrasées, la version « actuelle » arrive par mail dans une archive, et après une semaine, personne ne sait plus quelle est vraiment la version finale. Le problème ne vient pas des gens ou de leur manque d'attention, mais de l'absence d'un outil qui garde l'historique des modifications et qui sait fusionner intelligemment les apports de chacun. C'est exactement ce que fait Git. Mais à quoi ressemble vraiment le travail sans contrôle de version dans un projet concret ? Examinons quelques scénarios de perte de données typiques.

Bài giảng đầy đủ dành cho thuê bao

Còn 28 slide nữa trong phiên bản đầy đủ.

Video, toàn bộ slide, ghi chú, bài kiểm tra, gia sư AI và phỏng vấn sẽ mở sau khi đăng nhập và đăng ký thuê bao.

Đăng nhập hoặc đăng ký Đăng ký thuê bao

Nội dung bài giảng

« VRAIMENT_FINAL » — ce n'est pas votre faute
La peur de supprimer : quand l'historique n'existe que dans votre tête
Un développeur brouillon, une équipe en perdition
Supprimer un fichier, et le code disparaît à jamais
Impossible de revenir en arrière ? Mieux vaut ne pas y toucher
En équipe : un fichier, un survivant
Le chaos sans historique : rapport_final_v3_DEFINITIF.docx
VCS — une machine à remonter le temps pour votre code
Les trois questions auxquelles répond un VCS
Les quatre composantes de chaque commit
Git stocke des instantanés, pas des différences entre fichiers
git log : explorer l'historique du projet en direct
VCS centralisée : le serveur stocke tout
Un seul serveur, un seul point de défaillance
L'équipe grandit — le goulot d'étranglement se resserre
Un seul serveur — un seul point de défaillance
Copie complète : historique, branches, tout en local
Les trois libertés offertes par la distribution décentralisée
Pourquoi Git a été créé à ce moment précis
Les trois raisons du succès de Git
Git ≠ GitHub : la principale confusion des juniors
La confusion qui handicape tous les juniors
Git — sur votre ordinateur, GitHub — dans le cloud
Word, Google Drive et les trois alternatives à GitHub
GitHub — votre CV en action
Trois signaux qui se lisent comme une documentation
Ce qui tue un profil : l'invisibilité et les déchets numériques
Activité sans sens : trois pièges du profil
Secrets dans le dépôt : pourquoi c'est une catastrophe
Un profil qui dit « je maîtrise le processus »
Récapitulatif et mission