|
|
[:arrow_backward: Gestion des groupes et des projets](Gestion%20des%20groupes%20et%20des%20projets) | [Gestion des issues :arrow_forward:](Gestion%20des%20issues)
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
## Branche par défaut
|
|
|
|
|
|
La branche par défaut est nommée `main`. Ce paramètre est modifiable _via_ le menu _Settings_ > _Repository_ > _Default branch_.
|
|
|
|
|
|
## Créer, supprimer des branches ou des tags
|
|
|
|
|
|
La création ou suppression de branches peut se faire soit en ligne de commande classique git, soit depuis Gitlab en allant dans _Repository_ > _Branches_ (ou _Tags_) :
|
|
|
|
|
|
![image](uploads/2cc033cb8135a4376fabbc88471b2a8b/image.png)
|
|
|
|
|
|
## Modèle de gestion des branches
|
|
|
|
|
|
Il existe plusieurs façons de gérer les branches dans un projet Git. Un modèle de gestion des branches permet de clarifier où se font les développement, où se trouve le code de la production, comment préparer une _release_, comment gérer des _hotfix_, etc.
|
|
|
|
|
|
Voici trois exemples de modèles :
|
|
|
|
|
|
- [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) : un des plus connus, mais aussi des plus complexe. Une note au début de la page indique d'ailleurs que ce modèle n'est pas forcément le plus adapté aux principes de développement actuels.
|
|
|
- [GitHubFlow](https://docs.github.com/en/get-started/quickstart/github-flow) : plus simple d'utilisation
|
|
|
- [GitlabFlow](https://docs.gitlab.com/ee/topics/gitlab_flow.html) : également plus simple d'utilisation
|
|
|
|
|
|
Ces modèles fonctionnent souvent avec le principe de branches de _features_ et de _merge requests_ pour fusionner la nouvelle fonctionnalité.
|
|
|
|
|
|
Ce qui est important est de choisir un modèle compris et accepté par tous les acteurs, et qui ne génère pas plus de contraintes ou frictions que de problèmes censés être résolus.
|
|
|
|
|
|
## Branches protégées
|
|
|
|
|
|
Dans Gitlab, la notion de [branche protégée](https://src.koda-rec.cnrs.fr/help/user/project/protected_branches) permet de restreindre les rôles ayant le droit de pousser dans la branche (`git push`) et les rôles ayant le droit de fusionner la branche (dans la branche protégée).
|
|
|
|
|
|
Cela se fait en allant dans le menu _Settings_ > _Repository_ > _Protected branches_.
|
|
|
|
|
|
Par défaut, la configuration est la suivante :
|
|
|
|
|
|
![image](uploads/ecd064ffff4a15ff73dc21fae5cfe9b2/image.png)
|
|
|
|
|
|
Ce qui signifie que seuls les _Maintainers_ peuvent pousser et fusionner du code dans la branche _main_ ( la branche principale).
|
|
|
|
|
|
Les développeurs doivent donc développer dans une autre branche (par exemple _develop_, ou _feature/\*_) et demander l'intégration de leur code dans la branche principale via une _merge request_.
|
|
|
|
|
|
---
|
|
|
|
|
|
[:arrow_backward: Gestion des groupes et des projets](Gestion%20des%20groupes%20et%20des%20projets) | [Gestion des issues :arrow_forward:](Gestion%20des%20issues) |
|
|
\ No newline at end of file |