SlideShare une entreprise Scribd logo
1  sur  24
DXC Proprietary and Confidential
February 6, 2024
GIT & Feature Branching
Guidelines and best practice
February 6, 2024 2
DXC Proprietary and Confidential
Agenda
1. À propos de Git
2. Installation & Configuration
3. Comprendre le Branching Workflows
– Les branches principales
– Les branches de support
– Les branches de fonctionnalités (Feature
branches)
– Les branches de versions (Release branches)
– Les branches de correctifs (Hotfix branches)
4. Commandes de base
5. Git: What is / how to Pull Request
6. Git: Pull Request
February 6, 2024 3
DXC Proprietary and Confidential
Git est un gestionnaire de version, libre et trés
performant.
Il posséde de nombreux avantages par rapport `a
svn, notamment, la possibilité de travailler
localement.
À propos de Git
February 6, 2024 4
DXC Proprietary and Confidential
• Pouvoir travailler en local tout en ayant accés au dépôt central.
• L’utilisation de plusieurs branches est simplifiée.
• Pouvoir éditer des commits précédents avec git rebase.
• Pouvoir switcher rapidement d’une version à une autre et les comparer
sans changer de dossier et sans avoir `a communiquer avec le serveur
distant
• Chaque utilisateur possède une copie complète du dépôt central
• Git conserve un historique accessible avec la commande git reflog
• Il n’y a un seul répertoire .git, contrairement à svn ou l’on a un répertoire
.svn dans chaque sous-dossier
Avantages
February 6, 2024 5
DXC Proprietary and Confidential
Git à l’image d’être difficile à adopter au
début,
mais une fois que vous l'apprenez, vous ne
voulez jamais revenir en arrière.
February 6, 2024 6
DXC Proprietary and Confidential
Popularité de Git selon Google Trends VS SVN
February 6, 2024 7
DXC Proprietary and Confidential
• Git Bash : https://git-scm.com/downloads
• Une télécharger il est accessible via le menu contextuelle de windows
Installation & Configuration
February 6, 2024 8
DXC Proprietary and Confidential
• Configuration
• Pour modifier le de configuration git qui contient des informations sur vous :
– Nom
– adresse e-mail
– éditeur de texte.
• Votre nom apparaitra dans le fichier de log lorsque vous ferez des commits.
• git config - -global user.name <votre nom>
• git config - -global user.email <votre adresse mail>
• git config color.ui auto : permet d’avoir une coloration dans le terminal
Installation & Configuration
February 6, 2024 9
DXC Proprietary and Confidential
Comprendre le Branching Workflows -1
• Quand on démarre avec Git, on commence toujours par la technique, les commandes, les
subtilités techniques…
• Puis vient le moment du workflow. Celui où on essaie de mettre la méthodologie au propre,
d’être cohérents sur la durée, de rationaliser tout ça. Et poser cette question
Quel workflow mettre en place pour gérer efficacement mon projet, sans me compliquer la
vie avec ce sympathique système de branches ?
• Le git-flow est probablement le plus connu, voire le seul d’ailleurs.
• Il s’agit d’un modèle de branches standard qui semble s’adapter à n’importe quel projet, pas trop
complexe à prendre en main, avec quelques subtilités cependant.
February 6, 2024 10
DXC Proprietary and Confidential
Le git-flow
Ce workflow a été présenté le 5 Janvier 2010 par Vincent
Driessen comme un workflow de branchements git efficace.
Il couvre l’ensemble des besoins standards d’un projet de
développement classique.
https://nvie.com/posts/a-successful-git-branching-model/
Comprendre le Branching Workflows -2
February 6, 2024 11
DXC Proprietary and Confidential
Master :
• Nous considérons origin/master comme étant la branche
principale où le code source de HEAD reflète l’état de prêt
pour être déployé en production.
Develop :
• Nous considérons origin/develop comme étant la branche
principale où le code source de HEAD reflète les derniers
changements livrés pour la prochaine version. Certains
l’appelleraient « branche d’intégration ».
• C’est à partir de cet emplacement que sont compilées les
versions quotidiennes.
Les branches principales
February 6, 2024 12
DXC Proprietary and Confidential
A côté des branches principales master et develop, notre modèle de développement utilise une
variété de branches
Contrairement aux branches principales, ces branches ont toujours une durée de vie limitée,
puisqu’elles seront effacées au final.
Les différents types de branches que nous pouvons utiliser sont :
• les branches pour les fonctionnalités (Feature branches)
• les branches pour les versions (Release branches)
• les branches de correctifs (Hotfix branches)
Chacune de ces branches a un but précis et elles obéissent à des règles strictes comme :
• quelles branches elles peuvent provenir
• quelles branches elles peuvent être fusionnées
Les branches de support
February 6, 2024 13
DXC Proprietary and Confidential
• Lorsque vous commencez à travailler sur une
nouvelle fonctionnalité, partez de la
branche develop
• Les fonctionnalités terminées peuvent être
fusionnées dans la branche develop pour
être ajoutées à la prochaine version
Les branches de fonctionnalités
(Feature branches)
February 6, 2024 14
DXC Proprietary and Confidential
• Les branches de version servent à préparer
les nouvelles versions de production.
• Elles permettent les optimisations de
dernière minute. De plus elles permettent la
correction d’anomalies mineures
• Peuvent provenir de :
– develop
• Doivent être fusionnées dans:
– develop et master
• Convention de nommage de la branche :
– release-*
Les branches de version
(Release branches)
February 6, 2024 15
DXC Proprietary and Confidential
• Les branches Hotfix ressemblent beaucoup aux
branches de Relase (nouvelle version de
production)
• bien que non planifiées. Elles viennent de la
nécessité d’agir immédiatement sur un état
indésirable d’une version en production.
• Peuvent provenir de
– :master
• Doivent être fusionnées dans:
– develop et master
• Convention de nommage de la branche :
– hotfix-*
Les branches de correctifs
(Hotfix branches)
February 6, 2024 16
DXC Proprietary and Confidential
Commandes de base
Initialiser un dépôt git (git init)
• La commande git init lancée dans un répertoire permet d’initialiser un dépôt git.
• Par défaut, git se place sur une branche appelé ”master”.
• Vous pouvez ensuite y ajouter des fichiers avec la commande  git add.
• Ces fichiers seront suivi par git et leurs modifications pourront être enregistrées.
Récupération et synchronisation de la branch develop:
• git checkout develop
• git pull
February 6, 2024 17
DXC Proprietary and Confidential
Commandes de base
Créer une branche de fonctionnalité (Feature branch)
• git checkout -b <branch type>/<name>
• git push origin <branch type>/<name>
• Maintenant, la branche locale et la branche distante sont "liées", vous pouvez
pousser le code sans préciser la branche distante.
Obtenir et fusionner les commit potentielles d'autres développeurs
travaillant sur votre Feature branche
• git pull
February 6, 2024 18
DXC Proprietary and Confidential
Commandes de base
Fusionner les modifications de la branche develop avec votre
Feature branch
• git merge origin/develop
• résoudre les conflits, puis faire un push
• Essayer de faire cette modification le tous les jours, afin que votre branche soit
aussi proche que possible de develop
Lorsque le développement de votre branche est terminé
• Pousser votre Branch local vers la branche Distant (remote) avec la commande :
git push
• Ensuite, créez une Pull Request
February 6, 2024 19
DXC Proprietary and Confidential
Commandes de base
Messages d'erreur courants
there are still refs :
git error: there are still refs under 'refs/remotes/origin/release'
Essayez de nettoyer votre local repository avec:
• git gc --prune=now
• git remote prune origin
• git-gc - Cleanup unnecessary files and optimize the local repository
• git-remote - manage set of tracked repositories
February 6, 2024 20
DXC Proprietary and Confidential
Git: What is / how to Pull Request
February 6, 2024 20
February 6, 2024 21
DXC Proprietary and Confidential
Git: What is / how to Pull Request
February 6, 2024 21
develop
February 6, 2024 22
DXC Proprietary and Confidential
Top things to check before merging Pull Request
•Les tests doivent être corrects (tests unitaires et tests
d'intégration)
•Vous devriez avoir une couverture de test unitaire minimum
•Respect des guidelines de l’architecture du projet
•Elle doit être validé par un collègue ou deux (RT / Archi)
•Le respect des convention de nommage du projet
February 6, 2024 23
DXC Proprietary and Confidential
Trunk-based Development
To be continued
Autre Alternative
DXC Proprietary and Confidential
Merci
Questions

Contenu connexe

Similaire à GIT & Future Branching-0d86ea39-71ad-4a19-940c-c10be7c33b08-9feea918-d69a-47e9-9f0c-ee01bd479ad9.pptx

Au cœur du Framework .NET 4.5.1
Au cœur du Framework .NET 4.5.1Au cœur du Framework .NET 4.5.1
Au cœur du Framework .NET 4.5.1Microsoft
 
Git utilisation quotidienne
Git   utilisation quotidienneGit   utilisation quotidienne
Git utilisation quotidienneSylvain Witmeyer
 
Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Cellenza
 
Git ou le renouveau du contrôle de version
Git ou le renouveau du contrôle de versionGit ou le renouveau du contrôle de version
Git ou le renouveau du contrôle de versiongoldoraf
 
GIT training - basic for software projects
GIT training - basic for software projectsGIT training - basic for software projects
GIT training - basic for software projectsThierry Gayet
 
Utilisation de git avec Delphi
Utilisation de git avec DelphiUtilisation de git avec Delphi
Utilisation de git avec Delphipprem
 
Git et les systèmes de gestion de versions
Git et les systèmes de gestion de versionsGit et les systèmes de gestion de versions
Git et les systèmes de gestion de versionsAlice Loeser
 
Initiation à Git, GitHub2.pdf
Initiation à Git, GitHub2.pdfInitiation à Git, GitHub2.pdf
Initiation à Git, GitHub2.pdfmouad55
 
Elasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésElasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésMathieu Elie
 
Presentation of GWT 2.4 (PowerPoint version)
Presentation of GWT 2.4 (PowerPoint version)Presentation of GWT 2.4 (PowerPoint version)
Presentation of GWT 2.4 (PowerPoint version)Celinio Fernandes
 
Versionning et travail en équipe avec Salesforce - 27/11/2014
Versionning et travail en équipe avec Salesforce - 27/11/2014Versionning et travail en équipe avec Salesforce - 27/11/2014
Versionning et travail en équipe avec Salesforce - 27/11/2014Paris Salesforce Developer Group
 
Presentation of GWT 2.4 (PDF version)
Presentation of GWT 2.4 (PDF version)Presentation of GWT 2.4 (PDF version)
Presentation of GWT 2.4 (PDF version)Celinio Fernandes
 
Le système de versioning git
Le système de versioning gitLe système de versioning git
Le système de versioning gitNassim Bahri
 

Similaire à GIT & Future Branching-0d86ea39-71ad-4a19-940c-c10be7c33b08-9feea918-d69a-47e9-9f0c-ee01bd479ad9.pptx (20)

Versioning avec Git
Versioning avec GitVersioning avec Git
Versioning avec Git
 
Au cœur du Framework .NET 4.5.1
Au cœur du Framework .NET 4.5.1Au cœur du Framework .NET 4.5.1
Au cœur du Framework .NET 4.5.1
 
Git utilisation quotidienne
Git   utilisation quotidienneGit   utilisation quotidienne
Git utilisation quotidienne
 
Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1
 
Les bases de git
Les bases de gitLes bases de git
Les bases de git
 
Git ou le renouveau du contrôle de version
Git ou le renouveau du contrôle de versionGit ou le renouveau du contrôle de version
Git ou le renouveau du contrôle de version
 
Outils de gestion de projets
Outils de gestion de projetsOutils de gestion de projets
Outils de gestion de projets
 
GIT training - basic for software projects
GIT training - basic for software projectsGIT training - basic for software projects
GIT training - basic for software projects
 
GIT Fundamentals
GIT FundamentalsGIT Fundamentals
GIT Fundamentals
 
Utilisation de git avec Delphi
Utilisation de git avec DelphiUtilisation de git avec Delphi
Utilisation de git avec Delphi
 
Git et les systèmes de gestion de versions
Git et les systèmes de gestion de versionsGit et les systèmes de gestion de versions
Git et les systèmes de gestion de versions
 
Initiation à Git, GitHub2.pdf
Initiation à Git, GitHub2.pdfInitiation à Git, GitHub2.pdf
Initiation à Git, GitHub2.pdf
 
Universitélang scala tools
Universitélang scala toolsUniversitélang scala tools
Universitélang scala tools
 
Phigrate
PhigratePhigrate
Phigrate
 
Elasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésElasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautés
 
Presentation of GWT 2.4 (PowerPoint version)
Presentation of GWT 2.4 (PowerPoint version)Presentation of GWT 2.4 (PowerPoint version)
Presentation of GWT 2.4 (PowerPoint version)
 
Versionning et travail en équipe avec Salesforce - 27/11/2014
Versionning et travail en équipe avec Salesforce - 27/11/2014Versionning et travail en équipe avec Salesforce - 27/11/2014
Versionning et travail en équipe avec Salesforce - 27/11/2014
 
Git
GitGit
Git
 
Presentation of GWT 2.4 (PDF version)
Presentation of GWT 2.4 (PDF version)Presentation of GWT 2.4 (PDF version)
Presentation of GWT 2.4 (PDF version)
 
Le système de versioning git
Le système de versioning gitLe système de versioning git
Le système de versioning git
 

GIT & Future Branching-0d86ea39-71ad-4a19-940c-c10be7c33b08-9feea918-d69a-47e9-9f0c-ee01bd479ad9.pptx

  • 1. DXC Proprietary and Confidential February 6, 2024 GIT & Feature Branching Guidelines and best practice
  • 2. February 6, 2024 2 DXC Proprietary and Confidential Agenda 1. À propos de Git 2. Installation & Configuration 3. Comprendre le Branching Workflows – Les branches principales – Les branches de support – Les branches de fonctionnalités (Feature branches) – Les branches de versions (Release branches) – Les branches de correctifs (Hotfix branches) 4. Commandes de base 5. Git: What is / how to Pull Request 6. Git: Pull Request
  • 3. February 6, 2024 3 DXC Proprietary and Confidential Git est un gestionnaire de version, libre et trés performant. Il posséde de nombreux avantages par rapport `a svn, notamment, la possibilité de travailler localement. À propos de Git
  • 4. February 6, 2024 4 DXC Proprietary and Confidential • Pouvoir travailler en local tout en ayant accés au dépôt central. • L’utilisation de plusieurs branches est simplifiée. • Pouvoir éditer des commits précédents avec git rebase. • Pouvoir switcher rapidement d’une version à une autre et les comparer sans changer de dossier et sans avoir `a communiquer avec le serveur distant • Chaque utilisateur possède une copie complète du dépôt central • Git conserve un historique accessible avec la commande git reflog • Il n’y a un seul répertoire .git, contrairement à svn ou l’on a un répertoire .svn dans chaque sous-dossier Avantages
  • 5. February 6, 2024 5 DXC Proprietary and Confidential Git à l’image d’être difficile à adopter au début, mais une fois que vous l'apprenez, vous ne voulez jamais revenir en arrière.
  • 6. February 6, 2024 6 DXC Proprietary and Confidential Popularité de Git selon Google Trends VS SVN
  • 7. February 6, 2024 7 DXC Proprietary and Confidential • Git Bash : https://git-scm.com/downloads • Une télécharger il est accessible via le menu contextuelle de windows Installation & Configuration
  • 8. February 6, 2024 8 DXC Proprietary and Confidential • Configuration • Pour modifier le de configuration git qui contient des informations sur vous : – Nom – adresse e-mail – éditeur de texte. • Votre nom apparaitra dans le fichier de log lorsque vous ferez des commits. • git config - -global user.name <votre nom> • git config - -global user.email <votre adresse mail> • git config color.ui auto : permet d’avoir une coloration dans le terminal Installation & Configuration
  • 9. February 6, 2024 9 DXC Proprietary and Confidential Comprendre le Branching Workflows -1 • Quand on démarre avec Git, on commence toujours par la technique, les commandes, les subtilités techniques… • Puis vient le moment du workflow. Celui où on essaie de mettre la méthodologie au propre, d’être cohérents sur la durée, de rationaliser tout ça. Et poser cette question Quel workflow mettre en place pour gérer efficacement mon projet, sans me compliquer la vie avec ce sympathique système de branches ? • Le git-flow est probablement le plus connu, voire le seul d’ailleurs. • Il s’agit d’un modèle de branches standard qui semble s’adapter à n’importe quel projet, pas trop complexe à prendre en main, avec quelques subtilités cependant.
  • 10. February 6, 2024 10 DXC Proprietary and Confidential Le git-flow Ce workflow a été présenté le 5 Janvier 2010 par Vincent Driessen comme un workflow de branchements git efficace. Il couvre l’ensemble des besoins standards d’un projet de développement classique. https://nvie.com/posts/a-successful-git-branching-model/ Comprendre le Branching Workflows -2
  • 11. February 6, 2024 11 DXC Proprietary and Confidential Master : • Nous considérons origin/master comme étant la branche principale où le code source de HEAD reflète l’état de prêt pour être déployé en production. Develop : • Nous considérons origin/develop comme étant la branche principale où le code source de HEAD reflète les derniers changements livrés pour la prochaine version. Certains l’appelleraient « branche d’intégration ». • C’est à partir de cet emplacement que sont compilées les versions quotidiennes. Les branches principales
  • 12. February 6, 2024 12 DXC Proprietary and Confidential A côté des branches principales master et develop, notre modèle de développement utilise une variété de branches Contrairement aux branches principales, ces branches ont toujours une durée de vie limitée, puisqu’elles seront effacées au final. Les différents types de branches que nous pouvons utiliser sont : • les branches pour les fonctionnalités (Feature branches) • les branches pour les versions (Release branches) • les branches de correctifs (Hotfix branches) Chacune de ces branches a un but précis et elles obéissent à des règles strictes comme : • quelles branches elles peuvent provenir • quelles branches elles peuvent être fusionnées Les branches de support
  • 13. February 6, 2024 13 DXC Proprietary and Confidential • Lorsque vous commencez à travailler sur une nouvelle fonctionnalité, partez de la branche develop • Les fonctionnalités terminées peuvent être fusionnées dans la branche develop pour être ajoutées à la prochaine version Les branches de fonctionnalités (Feature branches)
  • 14. February 6, 2024 14 DXC Proprietary and Confidential • Les branches de version servent à préparer les nouvelles versions de production. • Elles permettent les optimisations de dernière minute. De plus elles permettent la correction d’anomalies mineures • Peuvent provenir de : – develop • Doivent être fusionnées dans: – develop et master • Convention de nommage de la branche : – release-* Les branches de version (Release branches)
  • 15. February 6, 2024 15 DXC Proprietary and Confidential • Les branches Hotfix ressemblent beaucoup aux branches de Relase (nouvelle version de production) • bien que non planifiées. Elles viennent de la nécessité d’agir immédiatement sur un état indésirable d’une version en production. • Peuvent provenir de – :master • Doivent être fusionnées dans: – develop et master • Convention de nommage de la branche : – hotfix-* Les branches de correctifs (Hotfix branches)
  • 16. February 6, 2024 16 DXC Proprietary and Confidential Commandes de base Initialiser un dépôt git (git init) • La commande git init lancée dans un répertoire permet d’initialiser un dépôt git. • Par défaut, git se place sur une branche appelé ”master”. • Vous pouvez ensuite y ajouter des fichiers avec la commande  git add. • Ces fichiers seront suivi par git et leurs modifications pourront être enregistrées. Récupération et synchronisation de la branch develop: • git checkout develop • git pull
  • 17. February 6, 2024 17 DXC Proprietary and Confidential Commandes de base Créer une branche de fonctionnalité (Feature branch) • git checkout -b <branch type>/<name> • git push origin <branch type>/<name> • Maintenant, la branche locale et la branche distante sont "liées", vous pouvez pousser le code sans préciser la branche distante. Obtenir et fusionner les commit potentielles d'autres développeurs travaillant sur votre Feature branche • git pull
  • 18. February 6, 2024 18 DXC Proprietary and Confidential Commandes de base Fusionner les modifications de la branche develop avec votre Feature branch • git merge origin/develop • résoudre les conflits, puis faire un push • Essayer de faire cette modification le tous les jours, afin que votre branche soit aussi proche que possible de develop Lorsque le développement de votre branche est terminé • Pousser votre Branch local vers la branche Distant (remote) avec la commande : git push • Ensuite, créez une Pull Request
  • 19. February 6, 2024 19 DXC Proprietary and Confidential Commandes de base Messages d'erreur courants there are still refs : git error: there are still refs under 'refs/remotes/origin/release' Essayez de nettoyer votre local repository avec: • git gc --prune=now • git remote prune origin • git-gc - Cleanup unnecessary files and optimize the local repository • git-remote - manage set of tracked repositories
  • 20. February 6, 2024 20 DXC Proprietary and Confidential Git: What is / how to Pull Request February 6, 2024 20
  • 21. February 6, 2024 21 DXC Proprietary and Confidential Git: What is / how to Pull Request February 6, 2024 21 develop
  • 22. February 6, 2024 22 DXC Proprietary and Confidential Top things to check before merging Pull Request •Les tests doivent être corrects (tests unitaires et tests d'intégration) •Vous devriez avoir une couverture de test unitaire minimum •Respect des guidelines de l’architecture du projet •Elle doit être validé par un collègue ou deux (RT / Archi) •Le respect des convention de nommage du projet
  • 23. February 6, 2024 23 DXC Proprietary and Confidential Trunk-based Development To be continued Autre Alternative
  • 24. DXC Proprietary and Confidential Merci Questions

Notes de l'éditeur

  1. La branche master sur origin devrait être connue des utilisateurs de Git. Parallèlement à la branchemaster, une autre branche appelée develop est présente. Nous considérons origin/master comme étant la branche principale où le code source de HEAD reflète l’état de prêt pour être déployé en production. Nous considérons origin/develop comme étant la branche principale où le code source de HEAD reflète les derniers changements livrés pour la prochaine version. Certains l’appelleraient « branche d’intégration ». C’est à partir de cet emplacement que sont compilées les versions quotidiennes. Quand le code source dans la branche develop est considéré stable et prête à être livré, tous les changements doivent être fusionnés dans master puis se voient assignés d’un numéro de version. Nous verrons comment faire cela en détails plus loin. En conséquence, à chaque fois que des changements sont reportés dans master, par définition c’est une nouvelle version de production. Nous devons être très strict avec ceci, pour qu’hypothétiquement nous puissions utiliser un hook Git afin de compiler et déployer automatiquement notre logiciel sur nos serveurs de production à chaque fois qu’il y a un commit sur master.
  2. A côté des branches principales master et develop, notre modèle de développement utilise une variété de branches de support pour aider le développement en parallèle entre les membres de l’équipe, faciliter le suivi des fonctionnalités, préparer les versions de productions et nous aider à réparer rapidement les problèmes survenus en production. Contrairement aux branches principales, ces branches ont toujours une durée de vie limitée, puisqu’elles seront effacées au final. Les différents types de branches que nous pouvons utiliser sont : les branches pour les fonctionnalités Lorsque vous commencez à travailler sur une nouvelle fonctionnalité, partez de la branche develop Les fonctionnalités terminées peuvent être fusionnées dans la branche develop pour être ajoutées à la prochaine version : les branches pour les versions Sdsds Sdsds les branches de correctifs Chacune de ces branches a un but précis et elles obéissent à des règles strictes comme de quelles branches elles peuvent provenir et dans quelles branches elles peuvent être fusionnées
  3. les branches pour les fonctionnalités Lorsque vous commencez à travailler sur une nouvelle fonctionnalité, partez de la branche develop Les fonctionnalités terminées peuvent être fusionnées dans la branche develop pour être ajoutées à la prochaine version L’option --no-ff va créer un nouveau commit lors de la fusion, même si la fusion aurait pu se faire avec un fast-forward. Cela évite de perdre l’information de l’existence historique d’une branche de fonctionnalité et groupe ensemble tous les commits qui ont été ajoutés à la fonctionnalité.
  4. En faisant tout ce travail sur une branche de version (release), la branche develop peut incorporer des fonctionnalités pour la prochaine version majeure. Report de code Les branches de version sont créées à partir de la branche develop Quand l’état de la branche de version est prêt à devenir une vraie version, quelques actions doivent êtres effectuées. Premièrement, la branche de release est fusionnée dans master Ensuite, ce commit sur master doit être tagué pour pouvoir faire simplement référence par la suite à cette version historique. Enfin, les changements fais sur la branche de version doivent être reporter dans develop, afin que les version futures contiennent aussi ces correctifs de cette release.
  5. Les branches de correctifs ressemblent beaucoup aux branches de version, dans le sens où elles sont également destinées à préparer une nouvelle version de production, bien que non planifiées. Elles viennent de la nécessité d’agir immédiatement sur un état indésirable d’une version en production.  Quand une anomalie critique doit être résolu immédiatement, une branche de correctif peut être crée à partir du tag correspondant sur la branche master qui marque la version de production. L’objectif est que le travail des membres de l’équipe (sur la branche develop) puisse continuer, pendant qu’une autre personne prépare un correctif rapide pour la production.
  6. Create a feature branch: Create the new branch from master, and push it : git checkout -b <branch type>/<name> git push origin <branch type>/<name> Now, the local branches and remote branch are "linked", you can push code without precising the remote branch. Get and merge potential commits from others developers working on your feature branch  If you are several developers working on the same feature branch, you need to synchronize their code with your using  : git pull
  7. Merge changes from develop with your feature branch  Do it daily, so that your feature branch is as close as possible to develop: git merge origin/develop  fix any conflicts, then push When the code of the feature branch is finished Push your changes on the git remote  git push Then create a pull request, refer to Git : What is / how to Pull Request ?
  8. Common error messages there are still refs git error: there are still refs under 'refs/remotes/origin/release'  Try cleaning-up your local repository with : git gc --prune=now git remote prune origin git-gc - Cleanup unnecessary files and optimize the local repository git-remote - manage set of tracked repositories
  9. Avant le merge , vous devez vous assurer que vous maintenez la qualité du code et ne briserez pas les fonctionnalités déjà existantes Pour obtenir les commentaires dont vous avez besoin pour les mises à jour et les améliorations de code, vous pouvez créer une PR incluant toutes les lignes de code que vous avez ajoutées.
  10. the pictures below gives a good summary of the PR process create a new feature branch dev update your branch by merging develop in it do code review improve your PR with code review comments PR is approved and merged in develop
  11. a new feature → a new branch and a new PR PR should be as small as possible (for readability and to facilitate merging) PR should not be very long (if not merging might will be difficult) you can keep up to date your feature branch by merging master into your feature regularly
  12. a new feature → a new branch and a new PR PR should be as small as possible (for readability and to facilitate merging) PR should not be very long (if not merging might will be difficult) you can keep up to date your feature branch by merging master into your feature regularly