Avez-vous lu Comment utiliser github pour gérer votre développement Si oui, ou si vous connaissez déjà git-scm, voici un cycle de développement très simple et propre à suivre lorsque vous travaillez au sein de notre réseau.

Le point de départ

Votre client vous demande de développer une nouvelle fonctionnalité, un correctif, un problème ou de réorganiser l'ensemble du site web ? Quelle que soit la demande, vous suivrez toujours le même chemin

Créez votre propre branche

Sur votre environnement de développement, vous commencerez par la dernière version de main commettre et créer votre propre branche #dev_branch# à partir de celui-ci

git checkout main # réinitialiser la branche si nécessaire.
git pull origin main
git checkout -b #dev_branch#
git push origin #dev_branch#

À ce stade, vous êtes prêt à commencer à travailler sur votre branche.

NOTE IMPORTANTE
Tant que vous n'avez pas terminé votre première livraison pour la production. JAMAIS git pull origin main sur votre branche.
Cela nous permettra de séparer vos problèmes de code des problèmes de fusion avec la branche main une fois que nous aurons besoin de pousser votre développement dans prod. (plus d'informations à ce sujet plus tard dans l'article)

Livrer pour l'UAT

Une fois que vous êtes prêt à passer en production, vous soumettez votre travail au client pour un test d'acceptation par l'utilisateur (UAT).
Cette étape et la validation directe du client sont requises avant que nous ne prenions en charge la mise en production.

Que se passe-t-il à ce stade ?

1. Nous avons réinitialisé l'UAT avec le dernier environnement main
2. Nous tirons votre branche sur la branche UAT*.
3. Nous vérifions s'il y a des conflits ou non

* La capture d'écran suivante est utilisée à titre d'exemple, ce type de commit n'est jamais poussé vers le repo, si c'était le cas pour une raison quelconque, ce type de commit serait surchargé sur l' UAT (branche) à un moment donné

Cas 1 - Sans conflit

S'il y a aucun conflit & le client a validé la mise en production

4. Nous tirons votre branche dans main et la commettons dans repo.

Cas 2 - Avec conflit

Si il y a un conflit

4. Nous vous demandons de git pull origin main sur votre branche pour résoudre les conflits
5. Soumettez votre livraison pour UAT

Si il n'y a plus de conflit (le conflit a été résolu) & le client a validé la mise en production

6. Nous tirons votre branche dans main et la commettons dans repo - ce qui ressemblerait à ceci

Exemple de conflit

Si nous vous avons demandé de fusionner la production à votre branche, vous allez git pull origin main sur votre branche, qui vous montrera le même résultat que celui que nous avons eu sur UAT. Ces conflits seront répertoriés comme résultat de git pull (sortie en ligne de commande)

user@server ~/public_html (uat)
$ git pull origin dev-lifecycle
Depuis https://github.com/owner/repo.git
 * branche dev-lifecycle -> FETCH_HEAD
Fusion automatique conflictingfile.txt
CONFLICT (contenu) : Fusionner le conflit dans conflictingfile.txt
La fusion automatique a échoué ; corrigez les conflits et livrez ensuite le résultat.

Ensuite, il ne vous reste plus qu'à résoudre le conflit, qui, dans notre cas, est devenu

De

Pour

En résumé

Ne tirez jamais la branche principale vers la vôtre, sauf si nous vous le demandons 🙂 .
Nous espérons que ce sujet est plus clair pour vous sur la façon de traiter vos branches de dev au sein de notre réseau.