¿Has aprendido los comandos de Git pero quieres imaginar cómo funciona la integración continua (CI) en la realidad? ¿O tal vez quieres optimizar tus actividades diarias? Este curso le brindará habilidades prácticas en integración continua utilizando un repositorio de GitHub. Este curso no pretende ser un asistente en el que simplemente puedas hacer clic; por el contrario, realizarás las mismas acciones que las personas realmente hacen en el trabajo, de la misma manera que lo hacen. Explicaré la teoría a medida que sigas los pasos involucrados.

qué hacemos?

A medida que avancemos, crearemos gradualmente una lista de pasos típicos de CI, que es una excelente manera de recordar esta lista. En otras palabras, crearemos una lista de acciones que los desarrolladores realizan mientras realizan una integración continua, haciendo una integración continua. También utilizaremos un conjunto simple de pruebas para acercar nuestro proceso de CI al real.

Este GIF muestra esquemáticamente las confirmaciones en su repositorio a medida que avanza en el curso. Como ves, aquí no hay nada complicado y solo lo más necesario.

Pasará por los siguientes escenarios de CI estándar:

• Trabajar en una característica;
• Aplicación de pruebas automatizadas para asegurar la calidad;
• Implementación de la tarea prioritaria;
• Resolución de conflictos al fusionar sucursales (conflicto de fusión);
• Se produce un error en un entorno de producción.

¿Que aprenderás?

Podrás responder las siguientes preguntas:

• ¿Qué es la integración continua (CI)?
• ¿Qué tipos de pruebas automatizadas se utilizan en CI y en respuesta a qué acciones se activan?
• ¿Qué son las solicitudes de extracción y cuándo se necesitan?
• ¿Qué es el desarrollo basado en pruebas (TDD) y cómo se relaciona con la CI?
• ¿Debo fusionar o cambiar la base de los cambios?
• ¿Revertir o arreglar en la próxima versión?

Al principio traduje cosas como “solicitudes de extracción” en todas partes, pero como resultado decidí devolver frases en inglés en algunos lugares para reducir el grado de locura en el texto. A veces uso "programador surzhik" como el maravilloso verbo "comprometerse" cuando la gente realmente lo usa en el trabajo.

¿Qué es la integración continua?

Integración continua, o CI, es una práctica técnica en la que cada miembro del equipo integra su código en un repositorio común al menos una vez al día, y el código resultante debe al menos compilarse sin errores.

Hay desacuerdos sobre este término.

El punto de discordia es la frecuencia de la integración. Algunos argumentan que fusionar código sólo una vez al día no es suficiente para una integración continua. Se da un ejemplo de un equipo donde todos toman código nuevo por la mañana y lo integran una vez por la noche. Si bien esta es una objeción razonable, en general se cree que la definición de una vez al día es razonablemente práctica, específica y adecuada para equipos de diferentes tamaños.

Otra objeción es que C++ ya no es el único lenguaje utilizado en el desarrollo, y simplemente exigir un ensamblaje sin errores como forma de validación es débil. Algún conjunto de pruebas (por ejemplo, pruebas unitarias ejecutadas localmente) también deben completarse correctamente. Por el momento, la comunidad está avanzando hacia hacer de esto un requisito, y en el futuro "compilar + pruebas unitarias" probablemente se convertirá en una práctica común, si no lo ha hecho ya.

Integración continua diferente de entrega continua (Entrega continua, CD) en el sentido de que no requiere una versión candidata después de cada ciclo de integración.

Lista de pasos que utilizaremos a lo largo del curso.

1. Introduzca el código más reciente. Crear una rama desde master. Empezar a trabajar.
2. Crea confirmaciones en tu nueva rama. Construya y pruebe localmente. ¿Aprobar? Vaya al siguiente paso. ¿Fallar? Corrija errores o pruebas y vuelva a intentarlo.
3. Envíe a su repositorio remoto o sucursal remota.
4. Crea una solicitud de extracción. Discuta los cambios, agregue más confirmaciones a medida que continúa la discusión. Haga que las pruebas pasen en la rama de características.
5. Fusionar/reorganizar confirmaciones desde el maestro. Haga que las pruebas pasen según el resultado de la fusión.
6. Implementar desde la rama de funciones a producción.
7. Si todo va bien en producción durante un período de tiempo, combine los cambios en master.

️ Preparación

Asegúrate de tener el software adecuado

Para realizar este curso necesitarás Node.js и cliente git.

Puede utilizar cualquier cliente Git, pero solo proporcionaré comandos para la línea de comandos.

Asegúrese de tener instalado un cliente Git que admita la línea de comando

Si aún no tiene un cliente Git que admita la línea de comandos, puede encontrar instrucciones de instalación aquí.

Preparar el repositorio

Necesitará crear una copia personal (fork) repositorio de plantillas con código para el curso en GitHub. Acordemos llamar a esta copia personal. repositorio de cursos.

¿Hecho? Si no ha cambiado la configuración predeterminada, lo más probable es que su repositorio de cursos se llame continuous-integration-team-scenarios-students, se encuentra en su cuenta de GitHub y la URL se ve así

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

Simplemente llamaré a esta dirección. <URL репозитория>.

Corchetes angulares como <тут> significará que deberá reemplazar dicha expresión con el valor apropiado.

Asegúrate de eso Acciones de GitHub incluido para este repositorio de cursos. Si no están habilitados, habilítelos haciendo clic en el botón grande en el medio de la página, al que puede acceder haciendo clic en Acciones en la interfaz de GitHub.

No podrás completar el curso siguiendo mis instrucciones si las GitHub Actions no están habilitadas.

Siempre puedes usar la capacidad de GitHub para representar Markdown y ver el estado actual de la lista que estamos componiendo aquí.

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

Sobre las respuestas

Si bien la mejor manera de completar este curso es hacerlo usted mismo, es posible que tenga algunas dificultades.

Si sientes que no entiendes qué hacer y no puedes continuar, puedes consultar el hilo. solution, que está en su repositorio de inicio.
Por favor no fusiones solution в master durante el curso. Puedes usar esta rama para saber qué hacer o para comparar tu código con el del autor, usando todas las capacidades que nos brinda Git. Si estás completamente perdido, puedes reemplazar completamente tu sucursal master en una rama solution y luego restablezca su directorio de trabajo al paso del curso que necesita.

Úsalo sólo si realmente lo necesitas

Confirma tu código

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

Estos comandos

• rebautizar master в master-backup;
• rebautizar solution в master;
• pagar en una nueva sucursal master y reescribir el contenido del directorio de trabajo;
• Cree una rama de "solución" desde "maestro" (que solía ser "solución") en caso de que necesite una rama de "solución" en el futuro.

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

Después de estos pasos puedes usar git log master para determinar qué compromiso necesita.
Puede restablecer su directorio de trabajo a esta confirmación de esta manera:

git reset --hard <the SHA you need>

Si está satisfecho con el resultado, en algún momento deberá publicar su versión del repositorio en un repositorio remoto. No olvide especificar explícitamente la rama remota cuando haga esto.

git push --force origin master

Tenga en cuenta que utilizamos git push --force. Es poco probable que quieras hacer esto muy a menudo, pero aquí tenemos un escenario muy específico con un usuario del repositorio que, además, entiende lo que está haciendo.

Empezando a trabajar

Comencemos a compilar nuestra lista de pasos de CI. Normalmente, comenzarías este paso verificando la última versión del código del repositorio remoto, pero aún no tenemos un repositorio local, por lo que lo clonamos desde el remoto.

️ Tarea: actualizar el repositorio local, crear una rama desde master, empezar a trabajar

1. Clonar el repositorio del curso desde <URL репозитория>.
2. Correr npm install en el directorio del repositorio de cursos; Lo necesitamos para instalar Jest, que usamos para ejecutar pruebas.
3. Crea una rama y nómbrala feature. Cambia a este hilo.

4. Agregar código de prueba a ci.test.js entre comentarios pidiéndome que haga esto.

   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. Agregue texto con los primeros 4 pasos al archivo 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.  

   Equipos

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

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

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

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

Cree confirmaciones en una nueva rama, construya y pruebe localmente

Configuraremos las pruebas para que se ejecuten antes de confirmar y luego confirmaremos el código.

Escenarios típicos cuando las pruebas se ejecutan automáticamente

• En la zona:
  • Continuamente o en respuesta a cambios de código apropiados;
  • Al guardar (para lenguajes interpretados o compilados JIT);
  • Durante el ensamblaje (cuando se requiere compilación);
  • Al comprometerse;
  • Al publicar en un repositorio compartido.

• En el servidor de compilación o el entorno de compilación:
  • Cuando el código se publica en una sucursal/repositorio personal.
  • El código de este hilo se está probando.
  • Se prueba el posible resultado de la fusión (generalmente con master).
  • Como etapa de integración continua/canal de entrega continua

Normalmente, cuanto más rápido se ejecute un conjunto de pruebas, con más frecuencia podrá ejecutarlo. Una distribución de escenario típica podría verse así.

• Pruebas unitarias rápidas: durante la compilación, en el proceso de CI
• Pruebas unitarias lentas, pruebas rápidas de integración y componentes: en el momento del compromiso, en el proceso de CI
• Pruebas lentas de integración y componentes: en el proceso de CI
• Pruebas de seguridad, pruebas de carga y otras pruebas costosas o que requieren mucho tiempo: en canalizaciones de CI/CD, pero solo en ciertos modos/etapas/canalizaciones de la compilación, por ejemplo, al preparar una versión candidata o cuando se ejecuta manualmente.

️Tarea

Sugiero ejecutar las pruebas manualmente primero usando el comando npm test. Después de eso, agreguemos un gancho git para ejecutar nuestras pruebas al confirmar. Hay un inconveniente: los ganchos de Git no se consideran parte del repositorio y, por lo tanto, no se pueden clonar desde GitHub junto con el resto de los materiales del curso. Para instalar el gancho necesitas ejecutar install_hook.sh o copiar el archivo repo/hooks/pre-commit al directorio local .git/hooks/.
Cuando se comprometa, verá que se ejecutan pruebas y verifican si ciertas palabras clave están presentes en la lista.

1. Ejecute las pruebas manualmente ejecutando el comando npm test en la carpeta del repositorio de su curso. Verifique que se hayan completado las pruebas.
2. Establezca un gancho de confirmación (gancho de confirmación previa) ejecutando install_hook.sh.
3. Confirme sus cambios en su repositorio local.
4. Asegúrese de ejecutar las pruebas antes de confirmar.

Su repositorio debería verse así después de seguir estos pasos.

Equipos

# Установите 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 en un repositorio remoto o sucursal remota

Una vez que terminan de trabajar localmente, los desarrolladores generalmente ponen su código a disposición del público para que eventualmente pueda integrarse con el público. Con GitHub, esto normalmente se logra publicando el trabajo en una copia personal del repositorio (bifurcación personal) o en una rama personal.

• Con las bifurcaciones, un desarrollador clona un repositorio compartido remoto y crea una copia remota personal del mismo, también conocida como bifurcación. Luego clona este repositorio personal para trabajar con él localmente. Cuando se completa el trabajo y se realizan las confirmaciones, las inserta en su bifurcación, donde están disponibles para otros y pueden integrarse en el repositorio común. Este enfoque se usa comúnmente en proyectos de código abierto en GitHub. También lo uso en mi curso avanzado [Trabajo en equipo y CI con Git] (http://devops.redpill.solutions/).
• Otro enfoque es utilizar solo un repositorio remoto y contar solo la rama. master repositorio compartido "protegido". En este escenario, los desarrolladores individuales publican su código en ramas de un repositorio remoto para que otros puedan ver este código; si todo está en orden, fusionarlo con master repositorio compartido.

En este curso en particular, usaremos un flujo de trabajo que utiliza ramas.

Publiquemos nuestro código.

️Tarea

• Publicar cambios en una rama remota con el mismo nombre que su rama de trabajo

Equipos

git push --set-upstream origin feature

Crear una solicitud de extracción

Crea una solicitud de extracción con un título Revisión de pasos... Instalar en pc feature como "rama principal" y master como "rama base".

Asegúrate de haber instalado master antes bifurcar el repositorio Como "rama base", no responderé a solicitudes de cambios en el repositorio de materiales del curso.

En la jerga de GitHub, la "rama base" es la rama en la que basas tu trabajo, y la "rama principal" es la rama que contiene los cambios propuestos.

Discuta los cambios, agregue nuevas confirmaciones a medida que continúa la discusión.

Solicitud de extracción (PR)

Solicitud de extracción (PR) es una forma de discutir y documentar el código, así como de realizar una revisión del código. Las solicitudes de extracción reciben el nombre de la forma general de integrar cambios individuales en el código general. Normalmente, una persona clona el repositorio oficial remoto del proyecto y trabaja en el código localmente. Luego de esto, coloca el código en su repositorio remoto personal y pide a los responsables del repositorio oficial que lo recojan( recogida ) su código en sus repositorios locales, donde lo revisan y posiblemente lo integran(unir) su. Este concepto también se conoce con otros nombres, por ejemplo, solicitud de fusión.

En realidad, no es necesario utilizar la función de solicitud de extracción de GitHub o plataformas similares. Los equipos de desarrollo pueden utilizar otros métodos de comunicación, incluida la comunicación cara a cara, llamadas de voz o correo electrónico, pero todavía existen varias razones para utilizar solicitudes de extracción estilo foro. Éstos son algunos de ellos:

• discusiones organizadas relacionadas con cambios de código específicos;
• como un lugar para ver comentarios sobre el trabajo en progreso tanto de los autotesters como de sus pares;
• formalización de revisiones de código;
• para que luego puedas conocer las razones y consideraciones detrás de tal o cual fragmento de código.

Por lo general, crea una solicitud de extracción cuando necesita discutir algo u obtener comentarios. Por ejemplo, si está trabajando en una función que podría implementarse de más de una manera, puede crear una solicitud de extracción antes de escribir la primera línea de código para compartir sus ideas y discutir sus planes con sus colaboradores. Si el trabajo es más sencillo, se abre una solicitud de extracción cuando algo ya está hecho, comprometido y se puede discutir. En algunos escenarios, es posible que desee abrir un PR solo por motivos de control de calidad: para ejecutar pruebas automatizadas o iniciar revisiones de código. Decidas lo que decidas, no olvides @mencionar a las personas cuya aprobación deseas en tu solicitud de extracción.

Normalmente, al crear un PR, se hace lo siguiente.

• Indique qué propone cambiar y dónde.
• Escriba una descripción que explique el propósito de los cambios. Quizás quieras:
  • agregue cualquier cosa importante que no sea obvia en el código, o algo útil para comprender el contexto, como #bugs relevantes y números de confirmación;
  • @menciona a cualquier persona con la que quieras empezar a trabajar, o puedes @mencionarla en los comentarios más tarde;
  • pida a sus colegas que le ayuden con algo o verifiquen algo específico.

Una vez que abre el PR, se ejecutan las pruebas configuradas para ejecutarse en tales casos. En nuestro caso, será el mismo conjunto de pruebas que ejecutamos localmente, pero en un proyecto real puede haber pruebas y comprobaciones adicionales.

Espere mientras se completan las pruebas. Puede ver el estado de las pruebas en la parte inferior de la discusión de relaciones públicas en la interfaz de GitHub. Continúe cuando se completen las pruebas.

️ Agregue una nota sobre la aleatoriedad de la lista de pasos de CI

La lista utilizada en este curso es arbitraria y subjetiva, habría que añadir una nota al respecto.

️ Tarea: crear una solicitud de extracción para este comentario

1. Cambiar a sucursal master.
2. Crea una rama llamada bugfix.
3. Agregar texto de nota al final del archivo 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. Confirme los cambios.
5. Publicar el hilo bugfix a un repositorio remoto.
6. Crea una solicitud de extracción llamada Agregar un comentario con una rama principal bugfix y la rama basemaster.

Asegúrate de haber instalado master antes bifurcar el repositorio Como "rama base", no responderé a solicitudes de cambios en el repositorio de materiales del curso.

Así es como debería verse su repositorio.

Equipos

# Переключитесь на ветку 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 solicitud de extracción "Agregar un comentario"

️Tarea

1. Crea una solicitud de extracción.
2. Haga clic en "Fusionar solicitud de extracción".
3. Haga clic en "Confirmar fusión".
4. Haga clic en "Eliminar rama", ya no la necesitamos.

Este es un diagrama de confirmaciones después de una fusión.

️ Sigue trabajando y agregando pruebas.

Colaborar en una solicitud de extracción a menudo resulta en trabajo adicional. Esto suele ser el resultado de una revisión o discusión de código, pero en nuestro curso modelaremos esto agregando nuevos elementos a nuestra lista de pasos de CI.

La integración continua normalmente implica cierta cobertura de prueba. Los requisitos de cobertura de la prueba varían y generalmente se encuentran en un documento llamado algo así como "pautas de contribución". Lo mantendremos simple y agregaremos una prueba para cada línea en nuestra lista de verificación.

Cuando ejecute tareas, intente realizar las pruebas primero. Si lo instaló correctamente pre-commit gancho anteriormente, la prueba recién agregada se ejecutará, fallará y no se confirmará nada. Tenga en cuenta que así es como sabemos que nuestras pruebas realmente están probando algo. Curiosamente, si comenzamos con el código antes de las pruebas, pasar las pruebas podría significar que el código funcionó como se esperaba o que las pruebas en realidad no estaban probando nada. Además, si no hubiéramos escrito las pruebas en primer lugar, es posible que nos hubiésemos olvidado de ellas por completo, ya que nada nos lo habría recordado.

Desarrollo basado en pruebas (TDD)

TDD recomienda escribir pruebas antes que el código. Un flujo de trabajo típico que utiliza TDD se ve así.

1. Añade una prueba.
2. Ejecute todas las pruebas y asegúrese de que la nueva prueba falle.
3. Escribe el código.
4. Ejecute las pruebas, asegúrese de que todas pasen.
5. Refactoriza tu código.
6. Repetir.

Debido a que los resultados de las pruebas que fallan generalmente se muestran en rojo y las que pasaron generalmente se muestran en verde, el ciclo también se conoce como refactor rojo-verde.

️Tarea

Primero, intente confirmar las pruebas y dejar que fallen, luego agregue y confirme el texto de la lista de pasos de CI. Verás que las pruebas van pasando ("verde").
Luego publique el nuevo código en el repositorio remoto y observe las pruebas ejecutadas en la interfaz de GitHub en la parte inferior de la discusión de la solicitud de extracción y la actualización del estado de PR.

1. Cambiar a sucursal feature.

2. Agregue estas pruebas a ci.test.js después de la última llamada 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. Intente realizar las pruebas. Si pre-commit El gancho está instalado, el intento de confirmación fallará.
4. Luego agregue 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. Realice y confirme cambios localmente.
6. Publicar cambios en la sucursal feature.

Ahora deberías tener algo como esto.

Equipos

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

Fusionar conflicto

Ir a solicitud de cambio Revisión de pasos.

Aunque no hicimos nada malo y las pruebas de nuestro código pasaron, todavía no podemos fusionar la rama. feature и master. Es porque el otro hilo bugfix se fusionó con master mientras trabajábamos en este PR.
Esto crea una situación en la que la sucursal remota master tiene una versión más nueva que en la que basamos la rama feature. Debido a esto no podemos simplemente rebobinar HEAD master hasta el final del hilo feature. En esta situación, necesitamos fusionar o aplicar confirmaciones. feature rebase master. De hecho, GitHub puede realizar fusiones automáticas si no hay conflictos. Desgraciadamente, en nuestra situación, ambas ramas tienen cambios competitivos en el expediente. ci.md. Esta situación se conoce como conflicto de fusión y debemos resolverlo manualmente.

Fusionar o cambiar de base

ir

• Crea una confirmación de fusión adicional y guarda el historial de trabajo.
  • Conserva las confirmaciones originales de las ramas con sus marcas de tiempo y autores originales.
  • Guarda el SHA de las confirmaciones y los vincula en las discusiones de solicitudes de cambio.
• Requiere resolución de conflictos por única vez.
• Hace que la historia no sea lineal.
  • La historia puede resultar difícil de leer debido a la gran cantidad de ramas (que recuerdan a un cable IDE).
  • Hace que la depuración automática sea más difícil, p. git bisect menos útil: solo encontrará la confirmación de fusión.

rebase

• Reproduce las confirmaciones de la rama actual encima de la rama base una tras otra.
  • Se generan nuevas confirmaciones con nuevos SHA, lo que hace que las confirmaciones en GitHub coincidan con las solicitudes de extracción originales, pero no con los comentarios correspondientes.
  • Las confirmaciones se pueden recombinar y modificar en el proceso, o incluso fusionarse en una sola.
• Es posible que sea necesario resolver múltiples conflictos.
• Le permite mantener una historia lineal.
  • La historia puede ser más fácil de leer siempre que no sea demasiado larga sin ningún motivo razonable.
  • La depuración y resolución de problemas automáticas es un poco más sencilla: lo hace posible git bisect, puede hacer que las reversiones automáticas sean más claras y predecibles.
• Requiere publicar una rama con confirmaciones migradas con una bandera --force cuando se usa con solicitudes de extracción.

Normalmente, los equipos acuerdan utilizar siempre la misma estrategia cuando necesitan fusionar cambios. Esto podría ser una fusión "pura" o una confirmación "pura" en la parte superior, o algo intermedio, como hacer una confirmación en la parte superior de forma interactiva (git rebase -i) localmente para ramas no publicadas en el repositorio público, pero se fusionan para ramas "públicas".

Aquí usaremos fusionar.

️Tarea

1. Asegúrate de que el código esté en una sucursal local. master actualizado desde un repositorio remoto.
2. Cambiar a sucursal feature.
3. Iniciar una fusión con una rama master. Un conflicto de fusión debido a cambios competitivos en el ci.md.
4. Resuelva el conflicto para que tanto nuestra lista de pasos de CI como una nota al respecto permanezcan en el texto.
5. Publicar una confirmación de fusión en una rama remota feature.
6. Verifique el estado de la solicitud de extracción en la interfaz de usuario de GitHub y espere hasta que se resuelva la combinación.

Equipos

# Убедитесь, что код в локальное ветке `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 trabajo!

Ya terminó con la lista y ahora necesita aprobar la solicitud de extracción en master.

️ Tarea: Aprobar solicitud de extracción "Revisión de pasos"

1. Abra una solicitud de extracción.
2. Haga clic en "Fusionar solicitud de extracción".
3. Haga clic en "Confirmar fusión".
4. Haga clic en "Eliminar rama" ya que ya no la necesitamos.

Este es tu repositorio en este momento.

Error de producto

Se dice que “las pruebas pueden usarse para mostrar la presencia de errores, pero nunca para mostrar su ausencia”. Aunque hicimos pruebas y no nos mostraron errores, un error insidioso entró en producción.

En un escenario como este, debemos ocuparnos de:

• qué se despliega en producción;
• código en el hilo master con un error, desde el cual los desarrolladores pueden comenzar un nuevo trabajo.

¿Debo revertirlo o arreglarlo en la próxima versión?

Revertir es el proceso de implementar una versión anterior en buen estado en producción y revertir las confirmaciones que contienen el error. "Reparación anticipada" es la adición de una solución al master e implementar la nueva versión lo antes posible. Debido a que las API y los esquemas de bases de datos cambian a medida que el código se implementa en producción, con entrega continua y buena cobertura de pruebas, revertirlo suele ser mucho más difícil y arriesgado que arreglarlo en la siguiente versión.

Dado que retroceder no conlleva ningún riesgo en nuestro caso, seguiremos este camino, porque nos permite

• corregir el error del producto lo antes posible;
• hacer código en master Inmediatamente apto para comenzar un nuevo trabajo.

️Tarea

1. Cambiar a sucursal master en la zona.
2. Actualice el repositorio local desde el repositorio remoto.
3. Revertir la confirmación de fusión de relaciones públicas Revisión de pasos в master.
4. Publicar cambios en un repositorio remoto.

Este es el historial de un repositorio con una confirmación de fusión revertida

Equipos

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

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

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

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

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

️ Autoprueba

Asegúrate de eso ci.md ya no contiene el texto "error furtivo" después de revertir una confirmación de fusión.

Corrija la lista de pasos de CI y devuélvala al maestro

Hemos revertido por completo la confirmación de fusión de la rama. feature. La buena noticia es que ahora no tenemos ningún error en master. La mala noticia es que nuestra preciosa lista de pasos de integración continua también desapareció. Entonces, idealmente, necesitamos aplicar la solución a las confirmaciones de feature y devolverlos a master junto con la solución.

Podemos abordar el problema de diferentes maneras:

• revertir una confirmación que deshace una fusión feature с master;
• mover compromisos del primero feature.

Diferentes equipos de desarrollo utilizan diferentes enfoques en este caso, pero trasladaremos confirmaciones útiles a una rama separada y crearemos una solicitud de extracción separada para esta nueva rama.

️Tarea

1. Crea un hilo llamado feature-fix y cambiar a él.

2. Migrar todas las confirmaciones de la rama anterior feature a un hilo nuevo. Resolver conflictos de fusión que ocurrieron durante la migración.

   

3. Agregar una prueba de regresión a ci.test.js:

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

4. Ejecute las pruebas localmente para asegurarse de que no fallen.
5. Eliminar el texto "con un error furtivo" en ci.md.
6. Agregue cambios de prueba y cambios de lista de pasos al índice y confírelos.
7. Publique la rama en un repositorio remoto.

Deberías terminar con algo similar a esto:

Equipos

# Создайте ветку под названием 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 una solicitud de extracción.

Crea una solicitud de extracción con un título Arreglando la característica... Instalar en pc feature-fix como "rama principal" y master como "rama base".
Espere mientras se completan las pruebas. Puede ver el estado de las pruebas en la parte inferior de la discusión de relaciones públicas.

Asegúrate de haber instalado master antes bifurcar el repositorio Como "rama base", no responderé a solicitudes de cambios en el repositorio de materiales del curso.

Aprobar solicitud de extracción "Arreglando la característica"

¡Gracias por la corrección! Por favor apruebe los cambios en master de la solicitud de extracción.

️Tarea

1. Haga clic en "Fusionar solicitud de extracción".
2. Haga clic en "Confirmar fusión".
3. Haga clic en "Eliminar rama" ya que ya no la necesitamos.

Esto es lo que deberías tener en este momento.

¡Enhorabuena!

Ha completado todos los pasos que las personas suelen seguir durante la integración continua.

Si nota algún problema con el curso o sabe cómo mejorarlo, cree un problema en repositorios con materiales del curso. Este curso también tiene versión interactiva utilizando GitHub Learning Lab como plataforma.

Fuente: habr.com