Uno, flujo de trabajo de Git
1. Proceso de desarrollo
En la rama principal o la rama de desarrollo funcional, elimine la regla de nomenclatura recomendada para la rama de desarrollo personal: [Nombre del desarrollador Jianpin] / [Tipo] - [nombre], el
nombre del desarrollador puede entrar en conflicto con el sufijo. Los
tipos incluyen: fix/fixbug、feat/featureetc. .,
naming Se puede personalizar, se recomienda
usar jira jira-[JIRA_ID]
con confluencia, usar confluence-[confluence_pageId]
otra lógica con la misma
función, enviar y empujar la rama personal a remota después del desarrollo,
cambiar localmente a la rama dev y actualizar git checkout dev && git pull, fusionar la rama de desarrollo remoto personal. Nota: En cuanto a si usar git pull o git featch, consulte esta imagen
Después de resolver el conflicto, envíe a la rama de desarrollo remota git push origin dev.
Si la configuración de gitlab-CI es correcta, enviar la rama de desarrollo / cualquier rama para crear una etiqueta específica (test-xxxxx) activará automáticamente el proceso de CI, CD
entorno de prueba después de aprobarlo, desarrolle su propia rama localmente rama maestra de fusión de rama Después de
resolver el conflicto, envíe el código a su rama de desarrollo remota
Envíe una solicitud de fusión en gitlab, la rama de destino es maestra, @personal relacionado revisa el código, después de confirmar que es correcta, la persona
a cargo fusiona MR y crea una etiqueta en la rama maestra en Gitlab (release-xxxx), activa CI para construir un paquete de entorno formal
Envíe una aplicación de implementación en http://web.xxxx.com/, y se implementará automáticamente en el entorno de producción después de que se apruebe la aplicación
En todo el proceso de I + D, la
implementación del entorno de prueba se puede completar con un clic, es decir, empujar a la rama de prueba específica remota o cualquier rama para crear una etiqueta específica y enviarla a la remota.
Implementar el entorno de producción para agregar revisión Pasos de código y pasos de revisión de implementación
para habilitar CI / CD en el proyecto Más tarde, mientras se usaban de manera efectiva las funciones de Gitlab, se aseguró la solidez del proyecto y se redujo el tedioso proceso de ejecución.
2. Asuntos que requieren atención
El conflicto de fusión solo se puede ejecutar en la máquina local, y solo la rama remota puede fusionarse en su propia rama de desarrollo. ¡
Todo el código que se ha fusionado en la rama "maestra" debe ser correcto! Sus códigos deben verificarse y confirmarse. Esto también significa que el trabajo de desarrollo no debe realizarse directamente en la rama "maestra", que también es la regla más básica.
El ciclo de vida de la rama de desarrollo funcional solo se mantiene hasta el final del tema de desarrollo (por ejemplo, cuando se corrige el error, se completa la nueva función ...), los cambios de esta rama se fusionarán en el maestro de el proyecto, y esta rama también será Eliminarlo.
Rebase reescribirá el historial, por lo que solo debe usar rebase para procesar su sucursal local y nunca hacer esto en confirmaciones que ya se han publicado.
Utilice el comando "git commit" y adjunte el parámetro "–amend" para modificar fácilmente su último envío, incluida la modificación de la información del envío y la adición de nuevos envíos. Nota: Este método requiere que la confirmación no se haya enviado al almacén remoto
3. Conéctese urgentemente
código de detección de rama maestra git checkout master && git checkout -b hotfix/XXXXX
para solucionar el problema desarrollo incorporado en la prueba
la prueba se completa en Gitlab el MR enviado, revisado y luego combinado con la línea maestra
4. Especificación del formato de información de envío de Git
El mensaje de envío consta de un encabezado, cuerpo y pie de página. El
encabezado incluye:
Tipo (tipo), alcance (opcional), asunto (asunto)
[()]:
[LÍNEA EN BLANCO]
[cuerpo]
[LÍNEA EN BLANCO]
[cambios importantes]
[LÍNEA EN BLANCO]
[pie de página]
El encabezado es el único envío obligatorio. La
primera línea (tipo + asunto) está limitada a 50 caracteres (obligatorio) y las
otras partes deben estar limitadas a 72 caracteres (incluidos los
saltos de línea). Esto facilita el envío de información en Gitlab y varias herramientas de git en lectura.
Valores opcionales para tipo:
hazaña: nuevas características (función)
corrección: corrección de errores
docs:
estilo de documentación : cambios en el formato de archivo (por ejemplo, cambios después de la ejecución de lint, etc., que no afectan los cambios en la operación del código)
refactorización: refactorización ( Esa no es una característica nueva, ni un cambio de código para modificar un error)
prueba: agregar
tarea de prueba : cambios en el proceso de compilación o herramientas auxiliares
ci: cambio en el
alcance del proceso de liberación de CI : alcance de influencia del envío
tema: descripción
del envío cuerpo: detalles del envío El
pie de página de descripción tiene dos funciones:
1. Cambios incompatibles: si el código actual no es compatible con la versión anterior, la parte del pie de página comienza con CAMBIO IMPORTANTE, seguida de una descripción del cambio, el motivo del cambio y el método de migración.
2. Cerrar problema: si la confirmación actual es para un problema determinado, puede cerrar el problema en la sección Pie de página. Consulte la descripción del problema relacionado con Gitlab a continuación para saber cómo cerrar
Ejemplo:
1. hazaña (aula): una nueva función
2. ci: agregar prueba
3. estilo: eliminar espacios adicionales
Dos, el principio de usar Gitlab
1. Prioridad aguas arriba
El principio más importante del flujo de Gitlab se llama "upsteam first", es decir, solo hay un master branch master, que es el "upstream" de todas las demás ramas. Solo los cambios de código adoptados por la rama maestra se pueden aplicar a otras ramas.
2. Lanzamiento continuo
Para proyectos de "lanzamiento continuo" (flujo de trabajo de rama de múltiples entornos), Gutlab recomienda establecer diferentes ramas de entorno además de la rama principal. Por ejemplo:
la rama de "entorno de desarrollo" es dev
"entorno de prelanzamiento" rama es pre
"entorno de producción" rama es rama principal
"entorno de producción" es "aguas arriba" de
rama de pre-lanzamiento , rama de pre-lanzamiento es rama de desarrollo "Río arriba".
Los cambios de código deben desarrollarse de "aguas arriba" a "aguas abajo". Por ejemplo, si hay un error en el entorno de producción, cree un nuevo ISSUE en Gitlab (asumiendo que el ID es 312), describa el problema y luego cree una rama de reparación fix / 312 desde el maestro. Una vez resuelto el problema, envíe el mensaje de confirmación como corrección ([alcance]): Arregle # 312, luego combínelo con dev, confirme que no hay ningún problema, y luego seleccione la configuración previa, no hay ningún problema en este paso, luego combínelo con el maestro , el proceso es: dev -> pre -> master.
Solo en casos de emergencia se permite saltar aguas arriba y fusionarse directamente con el ramal aguas abajo.
Tres, términos relacionados con Gitlab
1 、 Problema
El problema se utiliza para el seguimiento de errores y la gestión de requisitos. Se recomienda crear primero un nuevo problema y luego crear la rama de función correspondiente. La rama de funciones siempre es para resolver uno o más problemas.
El nombre de la rama de la función puede ser coherente con el nombre del problema, por ejemplo: 15-require-a-password-to-change-it Una vez
completado el desarrollo, en la descripción del envío, puedes escribir "arreglos # 14 "o" cierra # 67 ". Gitlab estipula que mientras los siguientes verbos + números o en el mensaje de confirmación, se cerrará el problema correspondiente.
Cerrar, Cierra, Cerrado, Cerrando, cerrar, cierra, cerrado, cerrando
Arreglar, Arreglar, Fijar, Arreglar, arreglar, arreglar, arreglar, arreglar
Resolver, Resolver, Resolver, Resolver, resolver, resuelve, resuelto, resolver
puede tener dos formas:
1. Todo en el mismo almacén:
Cierra # 333, # 444, # 555 y # 666
2. En diferentes bibliotecas:
Cierra # 333, # 444 y https://gitlab.com///issues/
2, rama protegida
La rama principal debe estar protegida. No todo el mundo puede modificar esta rama y tiene la autoridad para aprobar solicitudes de combinación.
3 、 Solicitud de fusión
La rama de funciones debe fusionarse con la rama principal / de funciones a través de la Solicitud de fusión. La solicitud de fusión es esencialmente un mecanismo de diálogo. Al enviar, puede @personal o equipo relacionado en los comentarios para atraer su atención.
4. Fusionar nodo
Hay dos tipos de fusión en Git: uno es "avance rápido", que no genera un nodo de fusión separado, el otro es "ninguno de avance rápido", que genera un solo nodo.
El primero no es propicio para mantener clara la información de confirmación, y no es propicio para futuras reversiones. Se recomienda usar siempre el segundo (es decir, usar el parámetro -no-ff). Siempre que se produzca una fusión, debe haber un único nodo de fusión.
5. Fusionar (Squash) varias confirmaciones
Para facilitar a otros la lectura de su envío y facilitar la selección o deshacer los cambios de código, debe combinar varias confirmaciones en una antes de iniciar una solicitud de combinación. (La premisa es que la rama la desarrolla usted solo y no se ha fusionado con el maestro).
También puede usar la operación de aplastamiento adjunta al comando rebase