-
1. Démarrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 Démon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 Sélection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 Réécrire l’historique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 Déboguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systèmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables d’environnement
- 10.9 Résumé
-
A1. Annexe A: Git dans d’autres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture d’instantané basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise à jour de projets
- A3.6 Inspection et comparaison
- A3.7 Débogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 Systèmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
3.4 Les branches avec Git - Travailler avec les branches
Travailler avec les branches
Maintenant que vous avez acquis les bases concernant les branches et les fusions (merges), que pouvez-vous ou devez-vous en faire ? Ce chapitre traite des différents processus que cette gestion de branche légère permet de mettre en place, de manière à vous aider à décider si vous souhaitez en incorporer un dans votre cycle de développement.
Branches au long cours
Comme Git utilise une fusion à 3 sources, fusionner une même branche dans une autre plusieurs fois sur une longue période est généralement facile. Cela signifie que vous pouvez avoir plusieurs branches ouvertes en permanence pour différentes phases de votre cycle de développement. Vous pourrez fusionner régulièrement ces branches entre elles.
De nombreux développeurs travaillent avec Git selon une méthode qui utilise cette approche.
Il s’agit, par exemple, de n’avoir que du code entièrement stable et testé dans leur branche master
ou bien même uniquement du code qui a été ou sera publié au sein d’une release.
Ils ont alors en parallèle une autre branche appelée develop
ou next
.
Cette branche accueille les développements en cours qui font encore l’objet de tests de stabilité — cette branche n’est pas nécessairement toujours stable mais quand elle le devient, elle peut être intégrée (via une fusion) dans master
.
Cette branche permet d’intégrer des branches thématiques (topic branches : branches de faible durée de vie telles que votre branche iss53
), une fois prêtes, de manière à s’assurer qu’elles passent l’intégralité des tests et n’introduisent pas de bugs.
En réalité, nous parlons de pointeurs qui se déplacent le long des lignes des commits réalisés. Les branches stables sont plus basses dans l’historique des commits tandis que les branches des derniers développements sont plus hautes dans l’historique.
![Vue linéaire de branches dans un processus de _stabilité progressive_](png/lr-branches-1.png)
Il est généralement plus simple d’y penser en termes de silos de tâches où un ensemble de commits évolue progressivement vers un silo plus stable une fois qu’il a été complètement testé.
![Vue _en silo_ de branches dans un processus de _stabilité progressive_](png/lr-branches-2.png)
Vous pouvez reproduire ce schéma sur plusieurs niveaux de stabilité.
Des projets plus gros ont aussi une branche proposed
ou pu
(proposed updates) qui intègre elle-même des branches qui ne sont pas encore prêtes à être intégrées aux branches next
ou master
.
L’idée est que les branches évoluent à différents niveaux de stabilité : quand elles atteignent un niveau plus stable, elles peuvent être fusionnées dans la branche de stabilité supérieure.
Une fois encore, disposer de multiples branches au long cours n’est pas nécessaire mais s’avère souvent utile, spécialement dans le cadre de projets importants et complexes.
Les branches thématiques
Les branches thématiques, elles, sont utiles quelle que soit la taille du projet. Une branche thématique est une branche ayant une courte durée de vie créée et utilisée pour une fonctionnalité ou une tâche particulière. C’est une méthode que vous n’avez probablement jamais utilisée avec un autre VCS parce qu’il y est généralement trop lourd de créer et fusionner des branches. Mais dans Git, créer, développer, fusionner et supprimer des branches plusieurs fois par jour est monnaie courante.
Vous avez déjà vu ces branches dans la section précédente avec les branches iss53
et correctif
que vous avez créées.
Vous y avez réalisé quelques commits et vous les avez supprimées immédiatement après les avoir fusionnées dans votre branche principale.
Cette technique vous permet de changer de contexte rapidement et complètement.
Parce que votre travail est isolé dans des silos où toutes les modifications sont liées à une thématique donnée, il est beaucoup plus simple de réaliser des revues de code.
Vous pouvez conserver vos modifications dans ces branches pendant des minutes, des jours ou des mois puis les fusionner quand elles sont prêtes, indépendamment de l’ordre dans lequel elles ont été créées ou traitées.
Prenons l’exemple suivant : alors que vous développez (sur master
), vous créez une nouvelle branche pour un problème (prob91
), travaillez un peu sur ce problème puis créez une seconde branche pour essayer de trouver une autre manière de le résoudre (prob91v2
).
Vous retournez ensuite sur la branche master
pour y travailler pendant un moment puis finalement créez une dernière branche (ideeidiote
) contenant une idée dont vous doutez de la pertinence.
Votre historique de commits pourrait ressembler à ceci :
![Branches thématiques multiples](png/topic-branches-1.png)
Maintenant, supposons que vous décidiez que vous préférez la seconde solution pour le problème (prob91v2
) et que vous ayez montré la branche ideeidiote
à vos collègues qui vous ont dit qu’elle était géniale.
Vous pouvez jeter la branche prob91
originale (perdant ainsi les commits C5
et C6
) et fusionner les deux autres branches.
Votre historique ressemble à présent à ceci :
![Historique après la fusion de `ideeidiote` et `prob91v2`](png/topic-branches-2.png)
ideeidiote
et prob91v2
Nous verrons au chapitre Git distribué, d’autres méthodes et processus possibles pour vos projets Git. Nous vous invitons à prendre connaissance de ce chapitre avant de vous décider pour une méthode particulière de gestion de vos branches pour votre prochain projet.
Il est important de se souvenir que lors de la réalisation de toutes ces actions, ces branches sont complètement locales. Lorsque vous créez et fusionnez des branches, ceci est réalisé uniquement dans votre dépôt Git local et aucune communication avec un serveur n’a lieu.