---
tags: forge, mémo
title: Distinction des Cas d'Usages d'une Branche dans un Projet ou d'un Clone
authors: Vincent-Xavier Jumel
affiliation: AEIF
date: dec. 2024
copyright: Creative Commmons CC BY-SA 4.0
---
# Mémo : distinction des cas d'usages d'une branche dans un projet ou d'un clone
:::info
**Objectif :**
Ce mémo clarifie les différents cas d'usages pour les branches dans un projet de développement logiciel et les scénarios où il est approprié d'utiliser des clones de dépôt.
:::
[TOC maxLevel=2]
## 1. Cas d'usages des branches dans un projet
Ce cas est celui à privilégier dans le cadre d'un projet avec plusieurs développeurs et un (ou des) mainteneur(s) en charge de l'intégration. C'est le modèle du [site de documentation](https://forge.apps.education.fr/docs/docs.forge.apps.education.fr). Ce modèle peut aussi être utilisé seul, pour permettre de travailler sur des fonctionnalités orthogonales les unes aux autres.
### 1.1. Branche principale (`main`) :
- **Utilisation :** Contient le code stable et prêt pour la production.
- **Exemple :** La branche `main` où le code est toujours dans un état déployable.
- **Remarques :** Devrait être protégée en écriture, sauf pour les fusions par les mainteneurs.
### 1.2. Branche de développement (`develop`) :
- **Utilisation :** Sert de zone de transit pour les nouvelles fonctionnalités avant qu'elles ne soient fusionnées dans la branche principale.
- **Exemple :** La branche `develop` où les développeurs intègrent leurs fonctionnalités pour des tests préliminaires.
- **Remarques :** Permet de travailler à plusieurs sur une même branche. Nécessite un fichier `.gitlab-ci.yml` plus complexe pour ne pas déployer le travail produit sur cette branche.
### 1.3. Branche de fonctionnalité (`feature`) :
- **Utilisation :** Utilisée pour développer une nouvelle fonctionnalité spécifique.
- **Exemple :** La branche `feature/new-login-system` pour ajouter un nouveau système de connexion.
- **Remarques :** Permet de mieux séparer plus précisément le travail quand plusieurs agents travaillent dans un même projet. De telles branches devraient être fusionnées dans `develop` par exemple. Nécessite un fichier `.gitlab-ci.yml` plus complexe pour ne pas déployer le travail produit sur cette branche.
<!--
```mermaid
gitGraph
commit
commit
branch develop
checkout develop
branch feature/a
branch feature/b
commit
checkout feature/a
commit
checkout feature/b
commit
checkout feature/a
commit
checkout develop
merge feature/b
merge feature/a
checkout main
merge develop
```
-->
### 1.4. Branche de correction de bugs (`bugfix`) :
- **Utilisation :** Créée pour corriger des bugs spécifiques.
- **Exemple :** La branche `bugfix/login-issue` pour résoudre un problème de connexion.
- **Remarques :** Ça complexifie pas mal le modèle.
<!--
```mermaid
gitGraph
commit
commit
branch develop
checkout develop
branch feature/a
branch feature/b
commit
checkout feature/a
commit
checkout feature/b
commit
checkout feature/a
commit
checkout develop
merge feature/b
merge feature/a
checkout main
merge develop
commit tag:"v1"
branch bugfix/1
checkout bugfix/1
commit id:"10"
checkout develop
branch feature/c
checkout feature/c
commit
checkout develop
merge feature/c
checkout main
merge bugfix/1
commit tag: "v1.1"
checkout feature/c
cherry-pick id:"10"
checkout develop
merge feature/c
checkout main
merge develop
commit tag: "v1.2"
```
-->
### 1.5. Branche de release (`release`) :
- **Utilisation :** Prépare une version spécifique pour la production, incluant des tests finaux et des corrections de dernière minute.
- **Exemple :** La branche `release/v1.2.0` pour préparer la version 1.2.0.
- **Remarques :** L'utilisation de `tag` est à mon avis largement suffisante pour ce besoin.
### 1.6. Branche de hotfix (`hotfix`) :
- **Utilisation :** Utilisée pour des corrections urgentes qui doivent être appliquées directement à la branche principale.
- **Exemple :** La branche `hotfix/critical-bug` pour corriger un bug critique en production.
- **Remarques :** C'est un des rares cas où on peut considérer que commettre directement les modifications dans `main` est acceptable.
## 2. Cas d'usages des clones avec branches ailleurs
C'est le modèle pour contribuer sur un projet externe ou sur un projet où on ne veut pas diffuser trop tôt des contributions, comme par exemple les corrections de devoirs.
À l'intérieur du dépôt cloné, on pourra, suivant les besoins, travailler sur `main` ou appliquer le principe des branches décrit ci-dessus.
Si une mise en production est réalisée par de la CI à partir de la branche `main`, cette mise en production sera réalisée dans votre espace personnel sur le clone.
### 2.1. Clone pour collaboration externe :
- **Utilisation :** Créer un clone du dépôt pour permettre à des collaborateurs externes de travailler sur la branche `main` sans accéder au dépôt principal.
- **Exemple :** Un collègue clone le dépôt et travaille sur `main` pour proposer une nouvelle fonctionnalité.
- **Remarques :** Cela ne nécessite souvent aucune action de votre part et permet de visualiser ce qui serait mis en production.
### 2.2. Clone pour collaboration externe avec des branches :
- **Utilisation :** Créer un clone du dépôt pour permettre à des collaborateurs externes de travailler sur des branches spécifiques sans accéder au dépôt principal.
- **Exemple :** Un collègue clone le dépôt et travaille sur `feature/nouvelle` pour proposer une nouvelle fonctionnalité.
- **Remarques :** Cela ne nécessite souvent aucune action de votre part et permet de visualiser ce qui serait mis en production.
### 2.3. Clone pour tests et validation :
- **Utilisation :** Cloner le dépôt pour effectuer des tests dans un environnement isolé, en utilisant des branches spécifiques pour différents scénarios de test.
- **Exemple :** Un clone du dépôt pour exécuter localement
- **Remarques :** C'est ce que réalise la CI.
### 2.4. Clone pour sauvegarde et archivage :
- **Utilisation :** Cloner le dépôt pour sauvegarder l'état actuel des branches avant des modifications majeures.
- **Exemple :** Un clone du dépôt avant une refonte majeure pour archiver l'état actuel des branches.
- **Remarques :** Conseillé si vous comptez faire des modifications de l'historique `git`. Pas nécessaire si vous pensez faire une nouvelle version.
### 2.5. Clone pour développement parallèle :
- **Utilisation :** Permettre à différentes équipes de travailler sur des branches spécifiques en parallèle sans interférer avec le travail des autres.
- **Exemple :** Une équipe travaille sur `feature/new-ui` tandis qu'une autre équipe travaille sur `feature/api-improvements` dans des clones séparés.
- **Remarques :** Cette méthode permet d'éviter le surcoût des clones complet.
:::success
**Point Clé :**
Dans le cas d'une branche dans le projet, si la CI n'est prévue que pour se déclencher sur `main`, il est difficile de voir facilement le résultat produit par la CI. En revanche, avec un clone/fork, on peut voir ce qui se passe sur `main` du fork sans impacter la production.
Attention, souvent la CI s'exécute sur toutes les branches, ce qui peut avoir des effets indésirables en cas de développement de fonctionnalité.
:::
:::info
**`git clone`** sur votre ordinateur
Le fonctionnement dans ce cas est assez similaire à ce qui est décrit en prenant les parties **2.1** et l'essentiel de **1**.
:::
**Conclusion :**
Les branches dans un projet de développement logiciel servent à organiser et gérer le flux de travail de manière structurée. Les clones de dépôt avec des branches situées ailleurs offrent des avantages supplémentaires pour la collaboration externe, les tests, la sauvegarde et le développement parallèle. Il est crucial de choisir le bon cas d'usage en fonction des besoins spécifiques du projet et de l'équipe.
Voir [utiliser des branches dans différentes situations](https://codimd.apps.education.fr/s/GnuQ6nGfl#) pour approfondir.
| | |
| ------- | ------------------------------------------------------- |
| Auteurs | Vincent-Xavier Jumel (vincent-xavier.jumel@ac-paris.fr) |
| Version | Version initiale 1.1 |
| Date | 2024-12-27 |