Actifs, fusion de branches Git et versions
Tout le monde a un flux de travail git différent, mais pour les besoins de cet article, supposons que vous ayez quelque chose comme ce qui suit :
- Une succursale dans laquelle résident tous vos actifs, non construits.
- Un système d’intégration continue qui construit les actifs et crée une nouvelle branche ou peut-être une nouvelle version.
- Une branche créée par le système d’intégration continue qui contient les actifs construits.
Le composant principal de ce workflow est le système d’intégration continue. Autrement dit, si cela échoue, le travail responsable de la construction des actifs et de la création d’une nouvelle succursale ne fonctionne plus.
Et lorsque cela se produit, nous devons le faire manuellement. C’est fastidieux, certes, mais pas difficile. Si vous vous trouvez dans cette position, voici comment vous pouvez créer des actifs, fusionner des branches git et créer une version versionnée.
Fusionner des branches Git
Pour cet article, supposons que vous disposez d’un outil de construction chargé de compiler vos actifs. Cela peut être l’un des outils disponibles, mais je vais en utiliser plusieurs npmpour démontrer le point.
1 Configurer la branche source
La branche source inclut tous les actifs non construits. Essentiellement, ce sont toutes les sources JavaScript brutes, les feuilles de style et tout autre composant lié au front-end qui n’ont pas été construits.
Une fois que le code est prêt, il peut être construit et validé dans n’importe quelle branche sur laquelle vous travaillez. Pour les besoins de cet article, nous l’appellerons develop.
Après avoir poussé ces modifications, nous devons ensuite changer de branche en builtbranche.
2 Fusionner la branche source dans la branche construite
Une fois que nous sommes sur la branche construite, nous pouvons construire toutes les ressources (encore une fois, en utilisant l’outil qui vous convient le mieux). Mais avant de faire cela, nous devons nous assurer que nous apportons le travail dans la builtbranche depuis la developbranche.
developEn d’ autres termes, nous devons fusionner develop-builtmême si le code develop-builtpeut être – ou sera probablement – obsolète après la fusion.
Ensuite, nous effectuons les commandes nécessaires pour créer les actifs, les ajouter et les valider dans la branche, puis nous poussons le nouveau travail :
Cela nous donne maintenant une branche, developavec toutes les sources brutes et une branche, develop-builtque nous pouvons utiliser pour étiqueter nos versions.
3 Étiquetez la branche construite
À ce stade, vous voudrez peut-être simplement marquer develop-builtcomme une version versionnée, vous voudrez peut-être la fusionner masterou quoi que ce soit. Si, toutefois, vous souhaitez conserver deux balises distinctes, une pour la balise source et une pour la balise de version réelle, vous pouvez le faire en étiquetant developet develop-builtavant d’effectuer toute fusion supplémentaire.
Plus précisément, vous pouvez baliser developcomme source versionnée :
Et develop-builtcomme version taguée :
À ce stade, vous pouvez fusionner cela dans la masterbranche ou quelle que soit la branche principale que vous choisissez de maintenir. Si vous utilisez Composer, cependant, vous voudrez probablement référencer des versions versionnées, c’est donc ici que vous pouvez utiliser l’onglet.
Remarque finale
Notez que votre flux de travail peut – et c’est probablement le cas – varier. Peut-être que vous utilisez des branches, peut-être que vous utilisez des balises, peut-être que vous utilisez une combinaison des deux comme ci-dessus.
Le but n’est pas de dire comment vous devriez le faire mais, en fin de compte, comment fusionner les branches git afin que votre branche source puisse se frayer un chemin dans la branche construite afin que vous puissiez construire les actifs et les versionner selon vos besoins.