Vous avez appris les commandes Git mais souhaitez imaginer comment fonctionne l'intégration continue (CI) dans la réalité ? Ou peut-être souhaitez-vous optimiser vos activités quotidiennes ? Ce cours vous donnera des compétences pratiques en intégration continue à l'aide d'un référentiel GitHub. Ce cours n'est pas destiné à être un assistant sur lequel vous pouvez simplement cliquer ; au contraire, vous effectuerez les mêmes actions que les gens font réellement au travail, de la même manière qu'ils le font. J'expliquerai la théorie au fur et à mesure que vous suivrez les étapes impliquées.

Qu'est-ce qu'on fait?

Au fur et à mesure que nous progressons, nous créerons progressivement une liste d’étapes typiques de l’IC, ce qui constitue un excellent moyen de mémoriser cette liste. En d’autres termes, nous allons créer une liste d’actions que les développeurs entreprennent lors de l’intégration continue, en effectuant une intégration continue. Nous utiliserons également un ensemble de tests simples pour rapprocher notre processus CI du réel.

Ce GIF montre schématiquement les commits dans votre référentiel au fur et à mesure de votre progression dans le cours. Comme vous pouvez le constater, il n'y a rien de compliqué ici et seulement le plus nécessaire.

Vous passerez par les scénarios CI standard suivants :

• Travailler sur une fonctionnalité ;
• Application de tests automatisés pour garantir la qualité ;
• Mise en œuvre de la tâche prioritaire ;
• Résolution de conflits lors de la fusion de branches (conflit de fusion) ;
• Une erreur se produit dans un environnement de production.

Qu'allez-vous apprendre ?

Vous pourrez répondre aux questions suivantes :

• Qu'est-ce que l'intégration continue (CI) ?
• Quels types de tests automatisés sont utilisés dans CI et en réponse à quelles actions sont-ils déclenchés ?
• Que sont les pull request et quand sont-elles nécessaires ?
• Qu'est-ce que le développement piloté par les tests (TDD) et quel est son rapport avec le CI ?
• Dois-je fusionner ou rebaser les modifications ?
• Restaurer ou corriger dans la prochaine version ?

Au début, j'ai traduit des choses comme des « pull request » partout, mais j'ai finalement décidé de renvoyer des phrases en anglais à certains endroits pour réduire le degré de folie du texte. J'utiliserai parfois « programmeur surzhik » comme le merveilleux verbe « s'engager » là où les gens l'utilisent réellement au travail.

Qu’est-ce que l’intégration continue ?

Intégration continue, ou CI, est une pratique technique dans laquelle chaque membre de l'équipe intègre son code dans un référentiel commun au moins une fois par jour, et le code résultant doit au moins être construit sans erreurs.

Il y a des désaccords sur ce terme

Le point de discorde est la fréquence de l’intégration. Certains soutiennent que fusionner le code une seule fois par jour ne suffit pas pour une intégration continue. Un exemple est donné d'une équipe où chacun prend du nouveau code le matin et l'intègre une fois le soir. Bien qu’il s’agisse d’une objection raisonnable, on estime généralement que la définition d’une journée unique est raisonnablement pratique, spécifique et adaptée à des équipes de différentes tailles.

Une autre objection est que C++ n'est plus le seul langage utilisé dans le développement et qu'exiger simplement un assemblage sans erreur comme moyen de validation est faible. Certains ensembles de tests (par exemple, les tests unitaires exécutés localement) doivent également se terminer avec succès. Pour le moment, la communauté s'efforce d'en faire une exigence, et à l'avenir "build + tests unitaires" deviendra probablement une pratique courante, si ce n'est pas déjà fait.

Intégration continue différent de approvisionnement continu (Continuous Delivery, CD) dans la mesure où il ne nécessite pas de version candidate après chaque cycle d'intégration.

Liste des étapes que nous utiliserons tout au long du cours

1. Insérez le dernier code. Créer une branche à partir de master. Commencer à travailler.
2. Créez des commits sur votre nouvelle branche. Construisez et testez localement. Passer? Passez à l'étape suivante. Échouer? Corrigez les erreurs ou les tests et réessayez.
3. Poussez vers votre référentiel distant ou votre branche distante.
4. Créez une pull request. Discutez des changements, ajoutez d'autres commits à mesure que la discussion se poursuit. Faites réussir les tests sur la branche fonctionnalité.
5. Fusionner/rebase les commits du maître. Faites passer les tests sur le résultat de la fusion.
6. Déployez de la branche des fonctionnalités vers la production.
7. Si tout va bien en production pendant un certain temps, fusionnez les modifications dans le master.

️ Préparation

Assurez-vous d'avoir le bon logiciel

Pour suivre ce cours, vous aurez besoin Node.js и Client Git.

Vous pouvez utiliser n'importe quel client Git, mais je ne fournirai que des commandes pour la ligne de commande.

Assurez-vous d'avoir installé un client Git prenant en charge la ligne de commande

Si vous n'avez pas encore de client Git prenant en charge la ligne de commande, vous pouvez trouver les instructions d'installation ici.

Préparer le référentiel

Vous devrez créer une copie personnelle (fork) référentiel de modèles avec le code du cours sur GitHub. Convenons d'appeler cette copie personnelle référentiel de cours.

Fait? Si vous n'avez pas modifié les paramètres par défaut, votre référentiel de cours s'appelle probablement continuous-integration-team-scenarios-students, il se trouve dans votre compte GitHub et l'URL ressemble à ceci

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Je vais simplement appeler cette adresse <URL репозитория>.

Des équerres comme <тут> signifiera que vous devez remplacer une telle expression par la valeur appropriée.

Sois sûr que Actions GitHub inclus pour ce référentiel de cours. S'ils ne sont pas activés, veuillez les activer en cliquant sur le gros bouton au milieu de la page, auquel vous pouvez accéder en cliquant sur Actions dans l'interface GitHub.

Vous ne pourrez pas terminer le cours en suivant mes instructions si les actions GitHub ne sont pas activées.

Vous pouvez toujours utiliser la capacité de GitHub à rendre Markdown pour voir l'état actuel de la liste que nous composons ici

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

À propos des réponses

Même si la meilleure façon de suivre ce cours est de le faire vous-même, vous pourriez rencontrer certaines difficultés.

Si vous sentez que vous ne comprenez pas quoi faire et que vous ne pouvez pas continuer, vous pouvez consulter le fil de discussion. solution, qui se trouve dans votre référentiel de démarrage.
S'il vous plaît, ne fusionnez pas solution в master pendant le cours. Vous pouvez utiliser cette branche pour savoir quoi faire ou pour comparer votre code avec celui de l'auteur, en utilisant toutes les fonctionnalités que Git nous offre. Si vous êtes complètement perdu, vous pouvez remplacer complètement votre branche master sur une branche solution puis réinitialisez votre répertoire de travail à l'étape de cours dont vous avez besoin.

N'utilisez-le que si vous en avez vraiment besoin

Validez votre code

git add .
git commit -m "Backing up my work"

Ces commandes

• Renommer master в master-backup;
• Renommer solution в master;
• paiement vers une nouvelle succursale master et réécrire le contenu du répertoire de travail ;
• Créez une branche "solution" à partir de "master" (qui était auparavant "solution") au cas où vous auriez besoin d'une branche "solution" à l'avenir.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Après ces étapes, vous pouvez utiliser git log master pour déterminer de quel commit vous avez besoin.
Vous pouvez réinitialiser votre répertoire de travail sur ce commit comme ceci :

git reset --hard <the SHA you need>

Si vous êtes satisfait du résultat, vous devrez à un moment donné publier votre version du référentiel sur un référentiel distant. N'oubliez pas de spécifier explicitement la branche distante lorsque vous faites cela.

git push --force origin master

Veuillez noter que nous utilisons git push --force. Il est peu probable que vous souhaitiez faire cela très souvent, mais nous avons ici un scénario très spécifique avec un utilisateur du référentiel qui, en plus, comprend ce qu'il fait.

Commencer à travailler

Commençons par dresser notre liste d'étapes CI. Normalement, vous commenceriez cette étape en extrayant la dernière version du code du référentiel distant, mais nous n'avons pas encore de référentiel local, nous le clonons donc à partir du référentiel distant.

️ Tâche : mettre à jour le référentiel local, créer une branche à partir de master, commencer à travailler

1. Cloner le référentiel de cours à partir de <URL репозитория>.
2. Run npm install dans le répertoire du référentiel de cours ; Nous en avons besoin pour installer Jest, que nous utilisons pour exécuter des tests.
3. Créez une branche et nommez-la feature. Passez à ce fil.

4. Ajouter le code de test à ci.test.js entre les commentaires me demandant de le faire.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Ajouter du texte avec les 4 premières étapes au fichier ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Команды

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Créez des commits sur une nouvelle branche, construisez et testez localement

Nous allons configurer les tests à exécuter avant de valider, puis valider le code.

Scénarios typiques où les tests s'exécutent automatiquement

• Localement:
  • En continu ou en réponse à des modifications appropriées du code ;
  • A la sauvegarde (pour les langages interprétés ou compilés JIT) ;
  • Pendant l'assemblage (lorsque la compilation est requise) ;
  • Lors de la validation ;
  • Lors de la publication sur un référentiel partagé.

• Sur le serveur de build ou l'environnement de build :
  • Lorsque le code est publié dans une branche/un référentiel personnel.
  • Le code de ce fil est en cours de test.
  • Le résultat potentiel de la fusion est testé (généralement avec master).
  • En tant qu'étape d'intégration continue/pipeline de livraison continue

En règle générale, plus une suite de tests s’exécute rapidement, plus vous pouvez vous permettre de l’exécuter souvent. Une distribution de scène typique pourrait ressembler à ceci.

• Tests unitaires rapides - pendant la construction, dans le pipeline CI
• Tests unitaires lents, tests rapides de composants et d'intégration - lors de la validation, dans le pipeline CI
• Tests de composants et d'intégration lents - dans le pipeline CI
• Tests de sécurité, tests de charge et autres tests longs ou coûteux - dans les pipelines CI/CD, mais uniquement dans certains modes/étapes/pipelines de la build, par exemple, lors de la préparation d'une version candidate ou lors d'une exécution manuelle.

️Tâche

Je suggère d'exécuter les tests manuellement d'abord en utilisant la commande npm test. Après cela, ajoutons un hook git pour exécuter nos tests lors de la validation. Il y a un problème : les hooks Git ne sont pas considérés comme faisant partie du référentiel et ne peuvent donc pas être clonés depuis GitHub avec le reste du matériel de cours. Pour installer le hook, vous devez exécuter install_hook.sh ou copiez le fichier repo/hooks/pre-commit au répertoire local .git/hooks/.
Lorsque vous vous engagez, vous verrez que des tests sont exécutés et qu'ils vérifient si certains mots-clés sont présents dans la liste.

1. Exécutez les tests manuellement en exécutant la commande npm test dans le dossier de votre référentiel de cours. Vérifiez que les tests ont été terminés.
2. Définissez un hook de validation (hook de pré-commit) en exécutant install_hook.sh.
3. Validez vos modifications dans votre référentiel local.
4. Assurez-vous que les tests sont exécutés avant de vous engager.

Votre référentiel devrait ressembler à ceci après avoir suivi ces étapes.

Команды

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Publier du code sur un référentiel distant ou une branche distante

Une fois qu'ils ont fini de travailler localement, les développeurs rendent généralement leur code accessible au public afin qu'il puisse éventuellement être intégré au public. Avec GitHub, cela est généralement réalisé en publiant le travail soit sur une copie personnelle du référentiel (fork personnel), soit sur une branche personnelle.

• Avec les forks, un développeur clone un référentiel partagé distant, en créant une copie distante personnelle, également appelée fork. Il clone ensuite ce référentiel personnel pour pouvoir l'utiliser localement. Lorsque le travail est terminé et que les commits sont effectués, il les pousse dans son fork, où ils sont disponibles pour les autres et peuvent être intégrés dans le référentiel commun. Cette approche est couramment utilisée dans les projets open source sur GitHub. Il est également utilisé dans mon cours avancé [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Une autre approche consiste à utiliser un seul référentiel distant et à ne compter que la branche master référentiel partagé "protégé". Dans ce scénario, les développeurs individuels publient leur code dans les branches d'un référentiel distant afin que d'autres puissent consulter ce code, si tout est en ordre, le fusionner avec master référentiel partagé.

Dans ce cours particulier, nous utiliserons un workflow qui utilise des branches.

Publions notre code.

️Tâche

• Publier les modifications sur une branche distante portant le même nom que votre branche de travail

Команды

git push --set-upstream origin feature

Créer une pull request

Créer une pull request avec un titre Révision des étapes... Installer feature comme "branche principale" et master comme "branche de base".

Assurez-vous d'avoir installé master avant fork le dépôt En tant que « branche de base », je ne répondrai pas aux demandes de modifications du référentiel de supports de cours.

Dans le jargon GitHub, la « branche de base » est la branche sur laquelle vous basez votre travail, et la « branche principale » est la branche contenant les modifications proposées.

Discutez des changements, ajoutez de nouveaux commits au fur et à mesure que la discussion se poursuit

Demande de tirage (PR)

Demande de tirage (PR) est un moyen de discuter et de documenter le code, ainsi que de procéder à une révision du code. Les demandes d'extraction portent le nom de la manière générale d'intégrer les modifications individuelles dans le code global. En règle générale, une personne clone le référentiel officiel distant du projet et travaille sur le code localement. Après cela, il place le code dans son référentiel personnel distant et demande aux responsables du référentiel officiel de le récupérer (tirer) son code dans leurs référentiels locaux, où ils le révisent et éventuellement l'intègrent (fusionner) son. Ce concept est également connu sous d'autres noms, par exemple, demande de fusion.

Vous n'êtes pas réellement obligé d'utiliser la fonctionnalité de demande d'extraction de GitHub ou de plateformes similaires. Les équipes de développement peuvent utiliser d'autres méthodes de communication, notamment la communication en face à face, les appels vocaux ou le courrier électronique, mais il existe toujours un certain nombre de raisons d'utiliser des demandes d'extraction de type forum. En voici quelques uns:

• discussions organisées liées à des changements de code spécifiques ;
• comme un endroit pour consulter les commentaires sur les travaux en cours de la part des autotesteurs et des pairs ;
• formalisation des revues de codes ;
• afin que plus tard vous puissiez découvrir les raisons et les considérations derrière tel ou tel morceau de code.

En règle générale, vous créez une pull request lorsque vous avez besoin de discuter de quelque chose ou d'obtenir des commentaires. Par exemple, si vous travaillez sur une fonctionnalité qui pourrait être implémentée de plusieurs manières, vous pouvez créer une pull request avant d'écrire la première ligne de code pour partager vos idées et discuter de vos projets avec vos collaborateurs. Si le travail est plus simple, une pull request est ouverte lorsque quelque chose a déjà été fait, validé et peut être discuté. Dans certains scénarios, vous souhaiterez peut-être ouvrir un PR uniquement pour des raisons de contrôle qualité : pour exécuter des tests automatisés ou lancer des révisions de code. Quelle que soit votre décision, n'oubliez pas de @mentionner les personnes dont vous souhaitez l'approbation dans votre pull request.

En règle générale, lors de la création d'un PR, vous procédez comme suit.

• Indiquez ce que vous proposez de changer et où.
• Rédigez une description expliquant le but des modifications. Vous souhaiterez peut-être :
  • ajoutez tout ce qui est important qui n'est pas évident dans le code, ou quelque chose d'utile pour comprendre le contexte, comme des #bugs et des numéros de commit pertinents ;
  • @mentionnez toute personne avec laquelle vous souhaitez commencer à travailler, ou vous pouvez la @mentionner dans les commentaires plus tard ;
  • demandez à vos collègues de vous aider avec quelque chose ou de vérifier quelque chose de spécifique.

Une fois que vous ouvrez le PR, les tests configurés pour s'exécuter dans de tels cas sont exécutés. Dans notre cas, il s'agira du même ensemble de tests que nous avons exécutés localement, mais dans un projet réel, il peut y avoir des tests et des vérifications supplémentaires.

Veuillez patienter pendant que les tests sont terminés. Vous pouvez voir l'état des tests au bas de la discussion PR dans l'interface GitHub. Continuez lorsque les tests sont terminés.

️ Ajouter une note sur le caractère aléatoire de la liste des étapes CI

La liste utilisée dans ce cours est arbitraire et subjective, nous devrions ajouter une note à ce sujet.

️ Tâche : créer une pull request pour ce commentaire

1. Passer à la succursale master.
2. Créez une branche nommée bugfix.
3. Ajouter un texte de note à la fin du fichier ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Validez les modifications.
5. Publier le fil bugfix vers un référentiel distant.
6. Créez une pull request nommée Ajouter une remarque avec une branche principale bugfix et la branche de basemaster.

Assurez-vous d'avoir installé master avant fork le dépôt En tant que « branche de base », je ne répondrai pas aux demandes de modifications du référentiel de supports de cours.

Voici à quoi devrait ressembler votre référentiel.

Команды

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Approuver la pull request "Ajout d'une remarque"

️Tâche

1. Créez une pull request.
2. Cliquez sur "Fusionner la demande d'extraction".
3. Cliquez sur "Confirmer la fusion".
4. Cliquez sur "Supprimer la branche", nous n'en avons plus besoin.

Ceci est un diagramme des commits après une fusion.

️ Continuez à travailler et à ajouter des tests

Collaborer sur une pull request entraîne souvent du travail supplémentaire. C'est généralement le résultat d'une révision du code ou d'une discussion, mais dans notre cours, nous allons modéliser cela en ajoutant de nouveaux éléments à notre liste d'étapes CI.

L'intégration continue implique généralement une certaine couverture de tests. Les exigences de couverture des tests varient et se trouvent généralement dans un document appelé quelque chose comme « directives de contribution ». Nous allons garder les choses simples et ajouter un test pour chaque ligne de notre liste de contrôle.

Lorsque vous exécutez des affectations, essayez d’abord de valider les tests. Si vous avez installé correctement pre-commit hook plus tôt, le test nouvellement ajouté sera exécuté, échouera et rien ne sera validé. Notez que c'est ainsi que nous savons que nos tests testent réellement quelque chose. Il est intéressant de noter que si nous commencions avec le code avant les tests, la réussite des tests pourrait signifier soit que le code fonctionnait comme prévu, soit que les tests ne testaient rien. De plus, si nous n'avions pas écrit les tests en premier lieu, nous les aurions peut-être complètement oubliés, car rien ne nous l'aurait rappelé.

Développement piloté par les tests (TDD)

TDD recommande d'écrire des tests avant le code. Un flux de travail typique utilisant TDD ressemble à ceci.

1. Ajoutez un test.
2. Exécutez tous les tests et assurez-vous que le nouveau test échoue.
3. Écrivez le code.
4. Exécutez les tests, assurez-vous que tous les tests réussissent.
5. Refactorisez votre code.
6. Répéter.

Étant donné que les résultats des tests qui échouent sont généralement affichés en rouge et ceux qui réussissent sont généralement affichés en vert, le cycle est également connu sous le nom de refactor rouge-vert.

️Tâche

Tout d'abord, essayez de valider les tests et de les laisser échouer, puis ajoutez et validez le texte de la liste d'étapes CI elle-même. Vous verrez que les tests réussissent (« vert »).
Publiez ensuite le nouveau code dans le référentiel distant et regardez les tests exécutés dans l'interface GitHub au bas de la discussion sur la demande d'extraction et la mise à jour du statut du PR.

1. Passer à la succursale feature.

2. Ajoutez ces tests à ci.test.js après le dernier appel it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Essayez de valider les tests. Si pre-commit hook est installé, la tentative de validation échouera.
4. Ajoutez ensuite ce texte à ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Apportez et validez les modifications localement.
6. Publier les modifications dans la branche feature.

Vous devriez maintenant avoir quelque chose comme ça

Команды

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Fusionner les conflits

Aller à la demande de modification Révision des étapes.

Même si nous n'avons rien fait de mal et que les tests de notre code ont réussi, nous ne pouvons toujours pas fusionner la branche. feature и master. C'est parce que l'autre fil bugfix a fusionné avec master pendant que nous travaillions sur ce PR.
Cela crée une situation où la branche distante master a une version plus récente que celle sur laquelle nous avons basé la branche feature. À cause de cela, nous ne pouvons pas simplement rembobiner HEAD master jusqu'au bout du fil feature. Dans cette situation, nous devons soit fusionner, soit appliquer des commits feature rebase master. GitHub peut en fait effectuer des fusions automatiques s'il n'y a pas de conflits. Hélas, dans notre situation, les deux branches ont des changements concurrents dans le dossier ci.md. Cette situation est connue sous le nom de conflit de fusion et nous devons la résoudre manuellement.

Fusionner ou rebaser

aller

• Crée une validation de fusion supplémentaire et enregistre l'historique de travail.
  • Préserve les commits originaux des branches avec leurs horodatages et auteurs d'origine.
  • Enregistre le SHA des commits et établit des liens vers ceux-ci dans les discussions sur les demandes de modification.
• Nécessite une résolution unique du conflit.
• Rend l'histoire non linéaire.
  • L'histoire peut être difficile à lire en raison du grand nombre de branches (qui rappelle un câble IDE).
  • Rend le débogage automatique plus difficile, par ex. git bisect moins utile - il ne trouvera que le commit de fusion.

Rebase

• Rejoue les commits de la branche actuelle au-dessus de la branche de base l'un après l'autre.
  • De nouveaux commits avec de nouveaux SHA sont générés, ce qui fait que les commits dans GitHub correspondent aux demandes d'extraction d'origine, mais pas aux commentaires correspondants.
  • Les commits peuvent être recombinés et modifiés au cours du processus, ou même fusionnés en un seul.
• Plusieurs conflits devront peut-être être résolus.
• Vous permet de maintenir une histoire linéaire.
  • L’histoire peut être plus facile à lire à condition qu’elle ne soit pas trop longue sans raison raisonnable.
  • Le débogage et le dépannage automatiques sont un peu plus simples : cela est possible git bisect, peut rendre les restaurations automatiques plus claires et plus prévisibles.
• Nécessite de publier une branche avec des commits migrés avec un indicateur --force lorsqu'il est utilisé avec des demandes d'extraction.

En règle générale, les équipes conviennent de toujours utiliser la même stratégie lorsqu'elles doivent fusionner des modifications. Cela pourrait être une fusion "pure" ou un commit "pur" par dessus, ou quelque chose entre les deux, comme faire un commit par dessus de manière interactive (git rebase -i) localement pour les branches non publiées dans le référentiel public, mais fusionnez pour les branches "publiques".

Ici, nous utiliserons la fusion.

️Tâche

1. Assurez-vous que le code se trouve dans une succursale locale master mis à jour à partir d'un référentiel distant.
2. Passer à la succursale feature.
3. Initier une fusion avec une branche master. Un conflit de fusion dû à des modifications concurrentes du ci.md.
4. Résolvez le conflit afin que notre liste d'étapes CI et une note à ce sujet restent dans le texte.
5. Publier un commit de fusion sur une branche distante feature.
6. Vérifiez l'état de la demande d'extraction dans l'interface utilisateur de GitHub et attendez que la fusion soit résolue.

Команды

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Excellent travail!

Vous avez terminé avec la liste et vous devez maintenant approuver la demande d'extraction master.

️ Tâche : Approuver la demande d'extraction "Révision des étapes"

1. Ouvrez une pull request.
2. Cliquez sur "Fusionner la demande d'extraction".
3. Cliquez sur "Confirmer la fusion".
4. Cliquez sur "Supprimer la branche" puisque nous n'en avons plus besoin.

Ceci est votre référentiel pour le moment

Erreur de produit

On dit que « les tests peuvent être utilisés pour montrer la présence d’erreurs, mais jamais pour montrer leur absence ». Même si nous avons effectué des tests et qu'ils ne nous ont montré aucune erreur, un bug insidieux s'est glissé dans la production.

Dans un scénario comme celui-ci, nous devons prendre soin de :

• ce qui est déployé en production ;
• code dans le fil master avec une erreur, à partir de laquelle les développeurs peuvent commencer un nouveau travail.

Dois-je revenir en arrière ou le corriger dans la prochaine version ?

La restauration est le processus de déploiement d’une bonne version antérieure connue en production et d’annulation des validations contenant l’erreur. "Fixing forward" est l'ajout d'un correctif au master et déployer la nouvelle version dès que possible. Étant donné que les API et les schémas de base de données changent à mesure que le code est déployé en production, avec une livraison continue et une bonne couverture de tests, la restauration est généralement beaucoup plus difficile et risquée que la correction dans la version suivante.

Puisque le retour en arrière ne comporte aucun risque dans notre cas, nous emprunterons cette voie, car elle nous permet

• corriger l'erreur sur le produit dès que possible ;
• créer du code dans master immédiatement apte à démarrer un nouvel emploi.

️Tâche

1. Passer à la succursale master localement.
2. Mettez à jour le référentiel local à partir du référentiel distant.
3. Annuler la validation de fusion PR Révision des étapes в master.
4. Publiez les modifications dans un référentiel distant.

Ceci est l'historique d'un référentiel avec un commit de fusion annulé

Команды

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Auto-test

Sois sûr que ci.md ne contient plus le texte « bug sournois » après l'annulation d'une validation de fusion.

Corrigez la liste des étapes CI et renvoyez-la au maître

Nous avons complètement annulé le commit de fusion de la branche. feature. La bonne nouvelle est que nous n'avons désormais aucune erreur dans master. La mauvaise nouvelle est que notre précieuse liste d’étapes d’intégration continue a également disparu. Donc, idéalement, nous devons appliquer le correctif aux commits de feature et les rapporter à master avec le correctif.

Nous pouvons aborder le problème de différentes manières :

• annuler un commit qui annule une fusion feature с master;
• déplacer les commits de l'ancien feature.

Différentes équipes de développement utilisent des approches différentes dans ce cas, mais nous déplacerons les commits utiles vers une branche distincte et créerons une pull request distincte pour cette nouvelle branche.

️Tâche

1. Créez un fil de discussion appelé feature-fix et basculez dessus.

2. Migrer tous les commits de l'ancienne branche feature à un nouveau fil. Résolvez les conflits de fusion survenus lors de la migration.

   

3. Ajouter un test de régression à ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Exécutez les tests localement pour vous assurer qu’ils n’échouent pas.
5. Supprimez le texte "avec un bug sournois" dans ci.md.
6. Ajoutez des modifications de test et des modifications de liste d’étapes à l’index et validez-les.
7. Publiez la branche sur un référentiel distant.

Vous devriez obtenir quelque chose de similaire à ceci :

Команды

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Créez une pull request.

Créer une pull request avec un titre Correction de la fonctionnalité... Installer feature-fix comme "branche principale" et master comme "branche de base".
Veuillez patienter pendant la fin des tests. Vous pouvez voir l'état des tests au bas de la discussion PR.

Assurez-vous d'avoir installé master avant fork le dépôt En tant que « branche de base », je ne répondrai pas aux demandes de modifications du référentiel de supports de cours.

Approuver la demande d'extraction "Correction de la fonctionnalité"

Merci pour la correction ! Veuillez approuver les modifications apportées à master à partir de la demande d'extraction.

️Tâche

1. Cliquez sur "Fusionner la demande d'extraction".
2. Cliquez sur "Confirmer la fusion".
3. Cliquez sur "Supprimer la branche" puisque nous n'en avons plus besoin.

C'est ce que vous devriez avoir pour le moment.

Félicitations!

Vous avez effectué toutes les étapes que les gens suivent généralement lors d'une intégration continue.

Si vous remarquez des problèmes avec le cours ou si vous savez comment l'améliorer, veuillez créer un problème dans référentiels avec matériel de cours. Ce cours a également version interactive en utilisant GitHub Learning Lab comme plateforme.

Source: habr.com