Guide du développeur sur l'utilisation de Git DMZ Flow

Comprendre et exécuter correctement une stratégie de workflow Git est essentiel au succès d'une équipe de développement. Les workflows Git tels que Gitflow et GitHub Flow sont populaires et assez faciles à comprendre pour les équipes de développement de tous niveaux de compétences et besoins de projet.

L'équipe Sitecore de Perficient a commencé à utiliser le excellent Git DMZ Flow Flux de travail Git pour nos projets, et bien qu'il soit très prometteur et puissant, il nécessite une compréhension fondamentale des concepts Git.

Git DMZ Flow est assez unique et peut-être un peu difficile à comprendre pour les nouveaux arrivants de Git. En fait, même les développeurs décents peuvent avoir du mal avec les concepts de fourche et de fusion de Git DMZ Flow, et la documentation sur l'utilisation quotidienne pour les développeurs est mince. Corrigeons cela.

Les développeurs qui ne sont pas familiers avec Git DMZ Flow peuvent utiliser ce guide pour commencer et comprendre le flux de travail de base de la fourche, de la création de branches et de la soumission des PR.

Qu'est-ce que Git DMZ Flow?

Daniel Spiewak a décrit pour la première fois DMZ Flow en 2015 et cela reste le meilleur aperçu du flux de travail.

Bien que Daniel fasse un excellent travail pour couvrir les aspects clés du flux de travail, il y a beaucoup à prendre en compte à la fois. Voici une version tl; dr qui est pertinente pour les nouveaux développeurs.

Git DMZ Flow:

• a un repo main avec deux branches clés: master et dmz
• s'adapte à n'importe quelle taille d'équipe sans pratiquement aucun changement de processus
• utilise fourches au lieu de branches pour gérer les flux de travail de code
• a toujours un maître propre dans le repo principal
  • master est toujours déployable et branchable
• seule la branche dmz du référentiel principal accepte les demandes d'extraction provenant d'autres fourchettes
  • seuls les changements de code PR sont visibles par le référentiel principal via la branche dmz

DMZ Flow renforce l'utilisation appropriée des concepts Git tels que la fourche, la fusion, le rebasage, les demandes d'extraction , et une bonne gestion des télécommandes. Étant donné que chaque développeur gère son propre fork du référentiel principal chaque développeur peut se déchaîner dans son fork sans interférer ou encombrer le dépôt main .

Note: J'appelle l'original repo « main » tout au long de ce guide, mais upstream est également un bon nom et peut-être plus évident pour certains développeurs.

Organigrammes pour DMZ Flow

La meilleure façon de comprendre DMZ Flow consiste à visualiser sa structure globale. Les développeurs suivront généralement ce flux de travail entre le référentiel principal et leur fork local:

Using Git DMZ Flow

Pour les développeurs novices dans DMZ Flow, ceci est un guide étape par étape pour l'utiliser comme flux de travail quotidien de Git. Cela suppose que le référentiel existant utilise déjà DMZ Flow et les processus de construction associés.

1) Créer un Fork et Clone Repo

Commencez par créer un nouveau fork du repo. Azure DevOps et GitHub rendent cela très facile.

AzDO:

GitHub:

]

Deuxièmement, clonez votre fork distant sur votre machine locale:

 $ git clone https://github.com/bmbruno/SparkServer.MyFork.git

2) Gérez vos télécommandes

Les développeurs auront deux situations qui les obligeront à gérer soigneusement les télécommandes:

• tirant le travail d'autres développeurs pour l'intégration ou le test
• poussant le code vers leur fork distant pour commencer à tirer demandes

Chaque développeur doit s'assurer d'avoir des télécommandes configurées pour son fork et le repo main . Pour ce faire, ajoutez le main comme télécommande:

 $ git remote add main https://github.com/bmbruno/SparkServer.git

Vous pouvez lui donner le nom que vous voulez, mais main ou amont sont assez courants.

Vérifiez que vous avez configuré les deux télécommandes:

 $ git remote - v

Sortie:

 origine https://github.com/bmbruno/SparkServer.MyFork.git (chercher)
origine https://github.com/bmbruno/SparkServer.MyFork.git (push)
main https://github.com/bmbruno/SparkServer.git (chercher)
principal https://github.com/bmbruno/SparkServer.git (push)

3) Gardez votre master Branch In Sync

Comme les développeurs gèrent leur propre fork, ils peuvent choisir de garder leur propre master branch sync with the main maître à tout moment. Il est recommandé de le faire pendant quelques points clés du flux de travail:

• avant de créer des branches
• juste avant de créer un PR

Dans les deux cas, toujours avance rapide votre synchronisation avec assurez-vous qu'un nouveau commit de fusion n'est pas créé et que l'historique reste propre.

Pour récupérer et fusionner dans votre branche master :

 (master)
$ git chercher main
$ git merge main / master --ff-only

4) Créer une branche et développer

Vous êtes maintenant prêt à commencer à travailler sur une fonctionnalité ou un bogue. Les développeurs doivent créer des branches en fonction de leur branche master mise à jour:

 (master)
$ git checkout -b fonctionnalité / travail à faire

À ce stade, les développeurs peuvent travailler sur leur fonctionnalité, extraire d'autres branches distantes pour obtenir le travail des autres, créer plus de branches si nécessaire – tout ce qui est nécessaire pour accomplir la tâche en cours.

5) Créer une requête d'extraction [19659024] Une fois qu'un développeur est prêt à soumettre son travail au repo principal il est temps de démarrer le processus de pull request.

Les conflits de fusion doivent être corrigés dans le fork du développeur (encore une fois, c'est

Tout d'abord, tirez le dernier master de main dans le master fourchu succursale:

 (maître)
$ git chercher main
$ git merge main / master --ff-only

(Et pour ceux qui enregistrent le score, oui, vous pouvez faire un git pull main master --ff-only pour obtenir le même résultat.)

Maintenant que le fork master est mis à jour avec le dernier main master il est temps d'intégrer ce code dans la branche des fonctionnalités. Rebasing fonctionne mieux ici: nous voulons intégrer l'historique complet et mis à jour de master dans la branche de fonctionnalité comme si nous venons de ramifier à partir de ce point dans master 's historique.

Assurez-vous que votre branche de travail actuelle est la branche de fonctionnalité ( git checkout feature / work-to-do si nécessaire). Pour rebaser votre branche d'entités à partir de la branche locale master :

 (feature / work-to-do)
$ git rebase master

Corrigez tous les conflits de fusion qui surviennent.

Enfin, poussez votre branche de fonctionnalité vers votre télécommande «origine» pour la rendre disponible sur le serveur.

 (fonctionnalité / travail à faire)
$ git push

Si vous n'avez pas encore poussé la branche, vous devrez peut-être identifier la télécommande:

 (fonctionnalité / travail à faire)
$ git push - fonction d'origine set-upstream / travail à faire

C'est tout! Vous pouvez maintenant créer une pull request qui devrait cibler la branche dmz du référentiel main . Avec une automatisation appropriée, le PR se terminera après examen et dmz sera automatiquement fusionné dans main master .

Lectures complémentaires