1. Le problème sans contrôle de version : pourquoi simplement copier des fichiers — c'est une mauvaise idée
Commençons par une situation de la vie réelle. Imaginez que vous travaillez sur votre projet C#. Tout va bien jusqu'au moment des "expériences". Vous décidez de changer quelque chose, mais vous avez peur de casser la version qui marche. Que faire ? Bien sûr, copier le projet !
Au final, sur votre disque apparaissent de tels chefs-d'œuvre :
MyProject/
├── Main.cs
├── Main_backup.cs
├── Main_final.cs
├── Main_final2.cs
├── Main_exactly_final.cs
├── Main_exactly_exactly_final.cs
Ça vous parle ? Et maintenant imaginez qu'un ami rejoint le projet. Lui aussi aime copier des fichiers — mais à sa façon. Comment savoir quelle est la version la plus récente et fonctionnelle ? Comment savoir qui a changé quoi ? Comment tout restaurer si l'expérience a échoué ?
Sans contrôle de version :
- Il est facile de perdre ou de mélanger le code qui marche.
- Impossible de "revenir en arrière" vers une ancienne version.
- Difficile de travailler à deux ou à trois.
- Chaos et peur d'expérimenter.
Ce sont précisément ces problèmes que résolvent les systèmes de contrôle de version — comme Git.
2. Pourquoi un développeur a besoin de Git ?
Git — c'est un puissant système de gestion de versions, utilisé pour suivre les modifications dans le code source pendant le développement logiciel. Il permet aux développeurs de sauvegarder différentes versions des fichiers et de coordonner le travail de plusieurs personnes sur un projet commun.
Concepts principaux de Git :
Repository
Le repository (ou "repo") — c'est l'endroit où est conservée toute l'histoire du projet, y compris toutes les modifications et versions des fichiers.
Commits
commit — c'est l'état sauvegardé du projet. Chaque commit dans Git contient l'information sur quelles modifications ont été faites, par qui et quand. Les commits forment l'historique du projet et permettent de revenir à n'importe quelle version précédente.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
Chaque commit est un "instantané" du projet, qui suit le précédent et forme une histoire séquentielle des changements.
Branches
branch — c'est une ligne de développement indépendante. Par défaut Git crée la branche main. Vous pouvez créer de nouvelles branches pour développer de nouvelles features ou des fixes, puis les merge dans la branche principale.
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
De la branche principale main "bifurque" la branche develop pour un développement parallèle. Après avoir terminé le travail, les changements de develop sont fusionnés de nouveau dans main.
3. Commandes Git principales (ce qui se passe sous le capot)
Voici la liste des commandes principales pour travailler avec Git via le terminal. Il est important de comprendre quelles commandes se trouvent à la base de toutes les opérations. Cependant, nous adopterons une approche GUI et apprendrons à effectuer toutes ces actions via l'interface graphique conviviale d'IntelliJ IDEA. Considérez ces commandes comme ce qui se passe "sous le capot".
| Commande | Description |
|---|---|
git init |
Initialise un nouveau Git-repository dans le répertoire courant. |
git clone |
Clone un repository depuis une URL dans un nouveau répertoire. |
git add |
Ajoute des fichiers à l'index pour le prochain commit. |
git commit |
Enregistre les changements préparés dans le repository. |
git push |
Envoie les changements du repository local vers le remote. |
git pull |
Met à jour la branche courante avec la dernière version depuis le repository distant. |
git branch |
Affiche, crée ou supprime des branches. |
git merge |
Fusionne les changements de la branche spécifiée dans la branche courante. |
Ces commandes représentent les outils principaux pour travailler avec Git, permettant de gérer les changements de code, les branches et les merges dans des projets de toute taille.
sequenceDiagram
participant Repertoire_de_travail
participant Zone_d_indexation_Staging
participant Repository_local
participant Repository_distant
Repertoire_de_travail ->> Zone_d_indexation_Staging: git add (Prepare)
Zone_d_indexation_Staging ->> Repository_local: git commit (Save locally)
Repository_local ->> Repository_distant: git push (Send to server)
Repository_distant ->> Repertoire_de_travail: git pull (Download updates)
4. Trois emplacements de stockage du code
Quand vous utilisez un système de contrôle de version pour votre code, il sera, grossièrement, stocké à trois endroits :
1. Repository distant
C'est l'endroit centralisé pour stocker votre code, généralement hébergé sur des services comme GitHub, GitLab ou Bitbucket. Ils fournissent un stockage centralisé du code et sont la base pour la collaboration. Le repository distant sert de point d'intégration pour l'automatisation — build, tests et déploiement.
2. Repository local
Le repository local — c'est votre copie personnelle du code, stockée sur votre machine. Dans ce repository vous pouvez effectuer toutes les opérations Git (commits, branching, merges) sans être connecté à Internet.
3. Répertoire de travail
Le répertoire de travail sur votre ordinateur contient les fichiers actuels du projet sur lesquels vous travaillez. C'est l'endroit où vous voyez et modifiez les fichiers, ajoutez de nouvelles fonctionnalités ou corrigez des bugs.
Ces composants ensemble fournissent une infrastructure puissante pour la gestion du code source, permettant aux développeurs de gérer l'historique du projet et de collaborer.
5. GitHub — votre portfolio
GitHub — c'est la principale plateforme web pour l'hébergement du code source, utilisant le système de contrôle de version Git. Fondée en 2008, elle est rapidement devenue un des outils clés pour les développeurs à travers le monde.
GitHub permet aux utilisateurs de créer des repositories pour gérer leurs projets, contrôler et suivre les changements dans le code et collaborer avec d'autres développeurs. Pour le développeur moderne, un profil GitHub est une partie importante du portfolio à montrer aux employeurs potentiels.
6. Créer votre premier repository sur GitHub
Étape 1. Allez sur https://github.com et inscrivez-vous.
Étape 2. Cliquez sur le bouton New repository pour créer un nouveau repository.
Étape 3. Réglez les paramètres du repository :
- Nom du repository : choisissez un nom significatif.
- Public ou privé : pour les projets d'apprentissage, mieux choisir "Public" pour que les autres puissent le voir.
- Add a README file : cochez cette case. README — c'est la "vitrine" de votre projet.
- Add .gitignore : ouvrez la liste déroulante et choisissez le template pour votre langage.
- Choose a license : peut être ignoré.
- Cliquez sur
Create repository.
Étape 4. Félicitations, votre premier repository distant est créé !
7. Installation et configuration de Git
Même si les bases de Git peuvent être apprises via les commandes en console (comme montré dans la vidéo), dans le travail quotidien 99% des développeurs utilisent des outils intégrés dans l'IDE. Notre objectif est de vous apprendre à travailler comme le font les pros.
L'interface pour travailler avec Git dans toutes les IDE modernes de JetBrains — que ce soit IntelliJ IDEA pour Java/Kotlin, Rider pour C# ou PyCharm pour Python — est pratiquement identique. Ça veut dire qu'en apprenant Git dans une IDE, vous pourrez appliquer ces compétences dans n'importe quelle autre. C'est pourquoi nous utiliserons IntelliJ IDEA comme exemple universel. Tout ce que vous verrez ici aura le même aspect et fonctionnera de la même façon dans votre IDE préférée.
Pour utiliser Git sur votre machine, il faut d'abord l'installer. Si vous utilisez IntelliJ IDEA, elle vous proposera probablement d'installer Git automatiquement si elle ne le trouve pas. Nous recommandons d'accepter — c'est la façon la plus simple.
Fermez le projet courant via File > Close Project, et cliquez sur Clone Repository.
Si vous préférez l'installer manuellement, utilisez le site officiel : https://git-scm.com/downloads.
8. Un peu d'histoire : main vs master
Autrefois la branche par défaut dans Git s'appelait master. Mais en 2020 la communauté des développeurs et les grandes plateformes, y compris GitHub, sont passées à un terme plus neutre — main.
C'est utile à savoir, car dans certains anciens articles ou projets vous pouvez encore voir la branche master. Dans nos leçons et dans les projets modernes la branche principale sera toujours main.
Pour en savoir plus sur la transition vers main, consultez les liens suivants :
GO TO FULL VERSION