Aprendeches os comandos de Git pero queres imaxinar como funciona a integración continua (CI) na realidade? Ou quizais queres optimizar as túas actividades diarias? Este curso darache habilidades prácticas na integración continua usando un repositorio de GitHub. Este curso non pretende ser un asistente no que simplemente podes facer clic, pola contra, realizarás as mesmas accións que a xente realmente realiza no traballo, da mesma forma que o fan. Vou explicar a teoría a medida que vaia facendo os pasos implicados.

Que facemos?

A medida que avancemos, iremos creando gradualmente unha lista de pasos típicos de CI, o que é unha boa forma de lembrar esta lista. Noutras palabras, crearemos unha lista de accións que realizan os desenvolvedores mentres realizan a integración continua, facendo a integración continua. Tamén usaremos un conxunto sinxelo de probas para achegar o noso proceso de CI ao real.

Este GIF mostra esquemáticamente os commits no teu repositorio a medida que avanzas no curso. Como podes ver, aquí non hai nada complicado e só o máis necesario.

Pasará polos seguintes escenarios estándar de CI:

• Traballar nunha función;
• Aplicación de probas automatizadas para garantir a calidade;
• Realización da tarefa prioritaria;
• Resolución de conflitos ao fusionar ramas (conflito de fusión);
• Prodúcese un erro nun ambiente de produción.

Que vai aprender?

Poderás responder ás seguintes preguntas:

• Que é a integración continua (CI)?
• Que tipos de probas automatizadas se utilizan en CI e en resposta a que accións se desencadean?
• Que son as solicitudes de extracción e cando son necesarias?
• Que é o desenvolvemento impulsado por probas (TDD) e como se relaciona co CI?
• ¿Debo combinar ou rebase os cambios?
• Volver atrás ou corrixir na seguinte versión?

Ao principio traducín cousas como "pull requests" a todas partes, pero como resultado decidín devolver frases en inglés nalgúns lugares para reducir o grao de tolemia no texto. Ás veces usarei "programador surzhik" como o marabilloso verbo "commit" onde a xente realmente o usa no traballo.

Que é a integración continua?

Integración Continua, ou CI, é unha práctica técnica na que cada membro do equipo integra o seu código nun repositorio común polo menos unha vez ao día e, polo menos, o código resultante debe construírse sen erros.

Hai desacordos sobre este termo

O punto de discusión é a frecuencia de integración. Algúns argumentan que fusionar código só unha vez ao día non é suficiente para integrarse de forma continua. Dáse un exemplo dun equipo onde todos collen código novo pola mañá e o integran unha vez pola noite. Aínda que esta é unha obxección razoable, en xeral crese que a definición dunha vez ao día é razoablemente práctica, específica e adecuada para equipos de diferentes tamaños.

Outra obxección é que C++ xa non é a única linguaxe que se usa no desenvolvemento, e simplemente esixir unha montaxe sen erros como forma de validación é débil. Algúns conxuntos de probas (por exemplo, probas unitarias executadas localmente) tamén deben completarse correctamente. Nestes momentos, a comunidade avanza para facer isto un requisito e, no futuro, "construír + probas unitarias" probablemente se converterá nunha práctica habitual, se aínda non o fixo.

Integración Continua difiere de entrega continua (Entrega continua, CD) xa que non require un candidato de liberación despois de cada ciclo de integración.

Lista de pasos que utilizaremos ao longo do curso

1. Introduce o código máis recente. Crear unha rama dende master. Comeza a traballar.
2. Crea commits na túa nova rama. Construír e probar localmente. Pasar? Vaia ao seguinte paso. Fallar? Corrixe erros ou probas e téntao de novo.
3. Envía ao teu repositorio remoto ou rama remota.
4. Crea unha solicitude de extracción. Discuta os cambios, engade máis compromisos mentres continúa a discusión. Fai pasar as probas na rama de funcións.
5. Commits de combinación/rebase do mestre. Fai que as probas pasen o resultado da fusión.
6. Implantar desde a rama de funcións ata a produción.
7. Se todo está ben na produción durante algún período de tempo, combina os cambios para master.

️ Preparación

Asegúrate de ter o software axeitado

Para realizar este curso necesitarás Nodo.js и Cliente Git.

Podes usar calquera cliente de Git, pero só proporcionarei comandos para a liña de comandos.

Asegúrate de ter instalado un cliente Git que admita a liña de comandos

Se aínda non tes un cliente Git que admita a liña de comandos, podes atopar instrucións de instalación aquí.

Prepara o repositorio

Terás que crear unha copia persoal (fork) repositorio de modelos con código para o curso en GitHub. Aceptemos chamar a esta copia persoal repositorio de cursos.

Feito? Se non cambiaches a configuración predeterminada, o teu repositorio do curso probablemente se chame continuous-integration-team-scenarios-students, está situado na túa conta de GitHub e o URL ten este aspecto

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

Simplemente chamarei a este enderezo <URL репозитория>.

Soportes angulares como <тут> significará que debe substituír tal expresión polo valor axeitado.

Asegúrate de que Accións de GitHub incluído para este repositorio do curso. Se non están habilitados, habilítaos facendo clic no botón grande do medio da páxina, ao que podes acceder facendo clic en Accións na interface de GitHub.

Non poderás completar o curso seguindo as miñas instrucións se as accións de GitHub non están activadas.

Sempre podes usar a capacidade de GitHub para renderizar Markdown para ver o estado actual da lista que estamos compoñendo aquí

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

Sobre as respostas

Aínda que a mellor forma de completar este curso é facelo vostede mesmo, pode ter algunhas dificultades.

Se cres que non entendes que facer e non podes continuar, podes consultar o fío solution, que está no seu repositorio de inicio.
Por favor, non fusiones solution в master durante o curso. Podes usar esta rama para descubrir que facer ou comparar o teu código co do autor, utilizando todas as capacidades que nos ofrece Git. Se estás completamente perdido, podes substituír completamente a túa sucursal master nunha rama solution e despois restablece o teu directorio de traballo ao paso do curso que necesitas.

Use isto só se realmente o necesita

Compromete o teu código

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

Estes comandos

• renomear master в master-backup;
• renomear solution в master;
• pagar a unha nova sucursal master e reescribir o contido do directorio de traballo;
• Crea unha rama de "solución" a partir de "mestre" (que adoitaba ser "solución") no caso de que necesites unha rama de "solución" no futuro.

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

Despois destes pasos podes usar git log master para descubrir que compromiso necesitas.
Podes restablecer o teu directorio de traballo a este compromiso deste xeito:

git reset --hard <the SHA you need>

Se estás satisfeito co resultado, nalgún momento terás que publicar a túa versión do repositorio nun repositorio remoto. Non esquezas especificar explícitamente a rama remota cando fagas isto.

git push --force origin master

Teña en conta que usamos git push --force. É pouco probable que queiras facelo con moita frecuencia, pero aquí temos un escenario moi específico cun usuario do repositorio que, ademais, entende o que está a facer.

Comeza a traballar

Comecemos a compilar a nosa lista de pasos de CI. Normalmente, comezaría este paso consultando a versión máis recente do código do repositorio remoto, pero aínda non temos un repositorio local, polo que clonámolo desde o remoto.

️ Tarefa: actualizar o repositorio local, crear unha rama dende master, comeza a traballar

1. Clonar o repositorio do curso desde <URL репозитория>.
2. Corre npm install no directorio do repositorio do curso; Necesitamos para instalar Jest, que utilizamos para realizar probas.
3. Crea unha rama e ponlle un nome feature. Cambia a este fío.

4. Engadir código de proba a ci.test.js entre comentarios que me piden que faga isto.

   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. Engade texto cos 4 primeiros pasos ao ficheiro 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.  

   Comandos

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

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

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

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

Crea commits nunha nova rama, constrúe e proba localmente

Imos configurar as probas para que se executen antes de confirmar e, a continuación, confirmaremos o código.

Escenarios típicos cando as probas se executan automaticamente

• Localmente:
  • Continuamente ou en resposta aos cambios de código axeitados;
  • Ao gardar (para linguaxes interpretadas ou compiladas en JIT);
  • Durante a montaxe (cando é necesaria a compilación);
  • En commit;
  • Ao publicar nun repositorio compartido.

• No servidor de compilación ou no entorno de compilación:
  • Cando o código se publica nunha sucursal/repositorio persoal.
  • O código deste fío está a ser probado.
  • Probáse o resultado potencial da fusión (normalmente con master).
  • Como etapa de integración continua / canalización de entrega continua

Normalmente, canto máis rápido se execute un conxunto de probas, máis veces podes permitirte o luxo de executalo. Unha distribución escénica típica pode verse así.

• Probas unitarias rápidas: durante a compilación, en pipeline CI
• Probas unitarias lentas, probas rápidas de compoñentes e integración - en commit, en proceso de CI
• Probas de compoñentes e integración lentas - en proceso de CI
• Probas de seguridade, probas de carga e outras probas caras ou que levan moito tempo: en canalizacións CI/CD, pero só en determinados modos/etapas/cancelacións da compilación, por exemplo, cando se prepara un candidato para a versión ou cando se executa manualmente.

️Tarefa

Suxiro executar as probas manualmente primeiro usando o comando npm test. Despois diso, engademos un gancho git para executar as nosas probas en commit. Hai un problema: os ganchos de Git non se consideran parte do repositorio e, polo tanto, non se poden clonar desde GitHub xunto co resto dos materiais do curso. Para instalar o gancho, cómpre executar install_hook.sh ou copia o ficheiro repo/hooks/pre-commit ao directorio local .git/hooks/.
Cando te comprometas, verás que se executan probas e comproban se determinadas palabras clave están presentes na lista.

1. Executa as probas manualmente executando o comando npm test no cartafol do repositorio do curso. Comprobar que se realizaron as probas.
2. Establece un gancho de commit (gancho de pre-commit) executando install_hook.sh.
3. Envía os teus cambios ao teu repositorio local.
4. Asegúrate de realizar as probas antes de comprometerte.

O teu repositorio debería verse así despois de seguir estes pasos.

Comandos

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

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

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

Publicar código nun repositorio remoto ou rama remota

Unha vez que rematan de traballar localmente, os desenvolvedores normalmente fan que o seu código estea dispoñible públicamente para que poida integrarse co público. Con GitHub, isto conséguese normalmente publicando o traballo nunha copia persoal do repositorio (fork persoal) ou nunha rama persoal.

• Con forks, un programador clona un repositorio compartido remoto, creando unha copia remota persoal del, tamén coñecida como fork. Despois clona este repositorio persoal para traballar localmente. Cando o traballo está completo e os commits están feitos, empúxaos no seu garfo, onde están dispoñibles para os demais e poden integrarse no repositorio común. Este enfoque úsase habitualmente en proxectos de código aberto en GitHub. Tamén se usa no meu curso avanzado [Traballo en equipo e CI con Git] (http://devops.redpill.solutions/).
• Outro enfoque é usar só un repositorio remoto e contar só a rama master repositorio compartido "protexido". Neste escenario, os desenvolvedores individuais publican o seu código en ramas dun repositorio remoto para que outros poidan ver este código, se todo está en orde, combínao con master repositorio compartido.

Neste curso en particular, usaremos un fluxo de traballo que usa ramas.

Imos publicar o noso código.

️Tarefa

• Publica os cambios nunha rama remota co mesmo nome que a túa rama de traballo

Comandos

git push --set-upstream origin feature

Crea unha solicitude de extracción

Crea unha solicitude de extracción cun título Revisión de pasos... Instalar feature como "ramo de cabeza" e master como "rama base".

Asegúrese de ter instalado master no seu fork o repositorio Como "rama base", non responderei ás solicitudes de cambios no repositorio de materiais do curso.

Na xerga de GitHub, a "rama base" é a rama na que baseas o teu traballo e a "rama principal" é a rama que contén os cambios propostos.

Discuta os cambios, engade novos compromisos mentres continúa a discusión

Solicitude de extracción (PR)

Solicitude de extracción (PR) é unha forma de discutir e documentar o código, así como de realizar a revisión do código. As solicitudes de extracción reciben o nome da forma xeral de integrar os cambios individuais no código global. Normalmente, unha persoa clona o repositorio oficial remoto do proxecto e traballa no código localmente. Despois diso, coloca o código no seu repositorio remoto persoal e pídelles aos responsables do repositorio oficial que o recollan (tirar) o seu código nos seus repositorios locais, onde revisen e posiblemente integren (fundir) seu. Este concepto tamén é coñecido por outros nomes, por exemplo, solicitude de fusión.

En realidade, non tes que usar a función de solicitude de extracción de GitHub ou plataformas similares. Os equipos de desenvolvemento poden utilizar outros métodos de comunicación, como a comunicación cara a cara, as chamadas de voz ou o correo electrónico, pero aínda hai unha serie de razóns para utilizar solicitudes de extracción ao estilo de foro. Aquí están algúns deles:

• debates organizados relacionados con cambios específicos de código;
• como un lugar para ver comentarios sobre o traballo en curso tanto de autotesters como de compañeiros;
• formalización de revisións de código;
• para que despois poidas descubrir as razóns e as consideracións que hai detrás deste ou aquel fragmento de código.

Normalmente creas unha solicitude de extracción cando necesitas discutir algo ou obter comentarios. Por exemplo, se está a traballar nunha función que se pode implementar de máis dunha forma, pode crear unha solicitude de extracción antes de escribir a primeira liña de código para compartir as súas ideas e discutir os seus plans cos seus colaboradores. Se o traballo é máis sinxelo, ábrese unha solicitude de extracción cando xa se fixo algo, se comprometeu e se pode discutir. Nalgúns escenarios, pode querer abrir un PR só por motivos de control de calidade: para realizar probas automatizadas ou iniciar revisións de código. Decidas o que decidas, non esquezas @mencionar ás persoas cuxa aprobación queres na túa solicitude de extracción.

Normalmente, ao crear un PR, fai o seguinte.

• Indica o que propóns cambiar e onde.
• Escribe unha descrición explicando o propósito dos cambios. Pode querer:
  • engadir calquera cousa importante que non sexa obvia no código, ou algo útil para comprender o contexto, como # erros relevantes e números de commit;
  • @menciona a quen queiras comezar a traballar, ou podes @mencionalos nos comentarios máis tarde;
  • pedirlle aos compañeiros que axuden con algo ou comproben algo específico.

Unha vez que abre o PR, execútanse as probas configuradas para executarse nestes casos. No noso caso, este será o mesmo conxunto de probas que realizamos localmente, pero nun proxecto real pode haber probas e comprobacións adicionais.

Agarde mentres se completan as probas. Podes ver o estado das probas na parte inferior da discusión de PR na interface de GitHub. Continúa cando rematen as probas.

️ Engade unha nota sobre a aleatoriedade da lista de pasos CI

A lista utilizada neste curso é arbitraria e subxectiva, deberíamos engadir unha nota ao respecto.

️ Tarefa: crea unha solicitude de extracción para este comentario

1. Cambiar á sucursal master.
2. Crea unha rama chamada bugfix.
3. Engade texto de nota ao final do ficheiro 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. Comprometer os cambios.
5. Publicar o fío bugfix a un repositorio remoto.
6. Crea unha solicitude de extracción co nome Engadindo unha observación cunha rama de cabeza bugfix e a rama basemaster.

Asegúrese de ter instalado master no seu fork o repositorio Como "rama base", non responderei ás solicitudes de cambios no repositorio de materiais do curso.

Así debería ser o teu repositorio.

Comandos

# Переключитесь на ветку 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 как описано выше

Aprobar a solicitude de extracción "Engadir un comentario"

️Tarefa

1. Crea unha solicitude de extracción.
2. Fai clic en "Merge pull request".
3. Fai clic en "Confirmar combinación".
4. Fai clic en "Eliminar rama", xa non o necesitamos.

Este é un diagrama de commits despois dunha combinación.

️ Segue traballando e sumando probas

Colaborar nunha solicitude de extracción adoita producir traballo adicional. Normalmente, isto é o resultado dunha revisión do código ou dunha discusión, pero no noso curso imos modelar isto engadindo novos elementos á nosa lista de pasos de CI.

A integración continua normalmente implica algunha cobertura de proba. Os requisitos de cobertura das probas varían e adoitan atoparse nun documento chamado "directrices de contribución". Manterémolo sinxelo e engadiremos unha proba para cada liña da nosa lista de verificación.

Ao executar tarefas, proba primeiro a realizar as probas. Se instalou correctamente pre-commit enganche antes, a proba recentemente engadida executarase, fallará e non se comprometerá nada. Teña en conta que así é como sabemos que as nosas probas están probando algo. Curiosamente, se comezamos co código antes das probas, pasar as probas podería significar que o código funcionou como se esperaba ou que as probas non estaban probando nada. Ademais, se non tivésemos escrito as probas en primeiro lugar, quizais esquecémolas por completo, xa que nada nolo recordaría.

Desenvolvemento impulsado por probas (TDD)

TDD recomenda escribir probas antes do código. Un fluxo de traballo típico que usa TDD é así.

1. Engade unha proba.
2. Executa todas as probas e asegúrate de que a nova proba falla.
3. Escribe o código.
4. Realiza as probas, asegúrate de que todas as probas pasen.
5. Refactoriza o teu código.
6. Repetir.

Debido a que os resultados das probas que fallan adoitan mostrarse en vermello, e os que pasaron normalmente móstranse en verde, o ciclo tamén se coñece como un refactor vermello-verde.

️Tarefa

Primeiro, proba a confirmar as probas e deixalas fallar, despois engade e engade o texto da propia lista de pasos CI. Verás que as probas están superando ("verde").
A continuación, publique o novo código no repositorio remoto e observe como se executan as probas na interface de GitHub na parte inferior da discusión da solicitude de extracción e da actualización do estado de PR.

1. Cambiar á sucursal feature.

2. Engade estas probas a ci.test.js despois da última chamada 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. Proba a realizar as probas. Se pre-commit o gancho está instalado, o intento de confirmación fallará.
4. Despois engade este texto a 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. Fai e comete cambios localmente.
6. Publicar cambios na sucursal feature.

Agora deberías ter algo así

Comandos

# Переключительна ветку 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

Conflito de fusión

Vaia a Solicitude de cambio Revisión de pasos.

Aínda que non fixemos nada mal e as probas para o noso código pasaron, aínda non podemos combinar a rama feature и master. É porque o outro fío bugfix fusionouse con master mentres traballabamos neste PR.
Isto crea unha situación na que a rama remota master ten unha versión máis nova que a que baseamos a rama feature. Por iso non podemos simplemente rebobinar HEAD master ata o final do fío feature. Nesta situación, necesitamos combinar ou aplicar commits feature rebase master. GitHub realmente pode realizar fusións automáticas se non hai conflitos. Por desgraza, na nosa situación, ambas as dúas ramas presentan modificacións competitivas no expediente ci.md. Esta situación coñécese como conflito de fusión e temos que resolvelo manualmente.

Combina ou rebase

Fundir

• Crea un compromiso de combinación adicional e garda o historial de traballo.
  • Conserva os commits orixinais das ramas coas súas marcas de tempo e autores orixinais.
  • Garda o SHA dos commits e as ligazóns nas discusións sobre solicitudes de cambio.
• Require unha única resolución de conflitos.
• Fai a historia non lineal.
  • A historia pode ser difícil de ler debido á gran cantidade de ramas (que lembra a un cable IDE).
  • Dificulta a depuración automática, p. ex. git bisect menos útil: só atopará a confirmación de fusión.

rebase

• Reproduce as confirmacións da rama actual encima da rama base unha tras outra.
  • Xéranse novos commits con novos SHA, o que fai que os commits en GitHub coincidan coas solicitudes de extracción orixinais, pero non cos comentarios correspondentes.
  • Os commits pódense recombinar e modificar no proceso, ou mesmo fusionarse nun só.
• Pode ser necesario resolver varios conflitos.
• Permite manter unha historia lineal.
  • A historia pode ser máis fácil de ler sempre que non sexa demasiado longa sen razón razoable.
  • A depuración automática e a resolución de problemas é un pouco máis fácil: faino posible git bisect, pode facer que as recuperacións automáticas sexan máis claras e previsibles.
• Require publicar unha rama con commits migrados cunha marca --force cando se usa con solicitudes de extracción.

Normalmente, os equipos aceptan utilizar sempre a mesma estratexia cando precisan combinar cambios. Pode ser unha combinación "pura" ou unha confirmación "pura" encima, ou algo intermedio, como facer unha confirmación enriba de forma interactiva (git rebase -i) localmente para ramas non publicadas no repositorio público, pero fusionarse para ramas "públicas".

Aquí usaremos merge.

️Tarefa

1. Asegúrate de que o código estea nunha sucursal local master actualizado desde un repositorio remoto.
2. Cambiar á sucursal feature.
3. Iniciar unha fusión cunha rama master. Un conflito de fusión debido a cambios en competencia no ci.md.
4. Resolve o conflito para que tanto a nosa lista de pasos de CI como unha nota ao respecto permanezan no texto.
5. Publicar unha confirmación de combinación nunha rama remota feature.
6. Comprobe o estado da solicitude de extracción na IU de GitHub e agarde ata que se resolva a combinación.

Comandos

# Убедитесь, что код в локальное ветке `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, дождитесь пока слияние не будет разрешено.

Gran traballo!

Remataches a lista e agora tes que aprobar a solicitude de extracción master.

️ Tarefa: aprobar a solicitude de extracción "Revisión de pasos"

1. Abre unha solicitude de extracción.
2. Fai clic en "Merge pull request".
3. Fai clic en "Confirmar combinación".
4. Fai clic en "Eliminar rama" xa que xa non a necesitamos.

Este é o teu repositorio neste momento

Erro do produto

Dise que "as probas poden usarse para mostrar a presenza de erros, pero nunca para mostrar a súa ausencia". Aínda que tivemos probas e non nos mostraron erros, entrou na produción un erro insidioso.

Nun escenario como este, debemos coidar de:

• o que se desprega na produción;
• código no fío master cun erro, a partir do cal os desenvolvedores poden comezar un novo traballo.

Debo retroceder ou solucionalo na seguinte versión?

Revertir é o proceso de despregar unha versión anterior boa coñecida na produción e revertir as confirmacións que conteñen o erro. "Fixing forward" é a adición dunha corrección ao master e despregando a nova versión canto antes. Dado que as API e os esquemas de bases de datos cambian a medida que o código se desprega na produción, cunha entrega continua e unha boa cobertura de probas, a recuperación adoita ser moito máis difícil e arriscada que solucionalo na seguinte versión.

Dado que facer retroceder non supón ningún risco no noso caso, seguiremos esta vía, porque nolo permite

• corrixir o erro no produto o antes posible;
• facer o código master inmediatamente adecuado para comezar un novo traballo.

️Tarefa

1. Cambiar á sucursal master localmente.
2. Actualiza o repositorio local desde o repositorio remoto.
3. Reverte o compromiso de combinación de PR Revisión de pasos в master.
4. Publicar cambios nun repositorio remoto.

Este é o historial dun repositorio cunha confirmación de combinación revertida

Comandos

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

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

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

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

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

️ Autotest

Asegúrese de que ci.md xa non contén o texto "error furtivo" despois de reverter unha confirmación de combinación.

Corrixe a lista de pasos CI e devólvea ao mestre

Revertimos por completo o compromiso de fusión da rama. feature. A boa noticia é que agora non temos ningún erro master. A mala noticia é que a nosa preciosa lista de pasos de integración continua tamén desapareceu. Polo tanto, o ideal é aplicar a corrección aos commits de feature e devolvelos master xunto coa corrección.

Podemos abordar o problema de diferentes xeitos:

• reverter unha confirmación que desfai unha combinación feature с master;
• mover comete do primeiro feature.

Os diferentes equipos de desenvolvemento usan enfoques diferentes neste caso, pero moveremos commits útiles a unha rama separada e crearemos unha solicitude de extracción separada para esta nova rama.

️Tarefa

1. Crea un fío chamado feature-fix e cambia a el.

2. Migra todos os compromisos da antiga rama feature a un novo fío. Resolve os conflitos de combinación que se produciron durante a migración.

   

3. Engadir unha proba de regresión a ci.test.js:

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

4. Realiza as probas localmente para asegurarte de que non fallan.
5. Elimina o texto "cun erro furtivo" en ci.md.
6. Engade os cambios de proba e de lista de pasos ao índice e comprométeos.
7. Publica a rama nun repositorio remoto.

Deberías acabar con algo parecido a isto:

Comandos

# Создайте ветку под названием 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

Crea unha solicitude de extracción.

Crea unha solicitude de extracción cun título Corrixindo a función... Instalar feature-fix como "ramo de cabeza" e master como "rama base".
Agarde mentres se completan as probas. Podes ver o estado das probas na parte inferior da discusión de PR.

Asegúrese de ter instalado master no seu fork o repositorio Como "rama base", non responderei ás solicitudes de cambios no repositorio de materiais do curso.

Aprobar a solicitude de extracción "Correxindo a función"

Grazas pola corrección! Aproba os cambios en master dende a solicitude de extracción.

️Tarefa

1. Fai clic en "Merge pull request".
2. Fai clic en "Confirmar combinación".
3. Fai clic en "Eliminar rama" xa que xa non a necesitamos.

Isto é o que deberías ter neste momento.

Parabéns!

Completaches todos os pasos que adoitan realizar as persoas durante a integración continua.

Se notas algún problema co curso ou sabes como melloralo, crea un problema en repositorios con materiais do curso. Este curso tamén ten versión interactiva usando GitHub Learning Lab como plataforma.

Fonte: www.habr.com