El artículo anterior hablaba sobre la práctica de administración de sucursales de Git, tanto la fusión en línea como la fusión local. Después de todo: solo decir que ninguna práctica es falsa. Pero practicar y no organizar, solo puede ser estúpido. ¿Cómo se gestiona la gestión de sucursales?
Comencemos con un diagrama clásico en GitLab. Como descripción general, también es conveniente comprender la gestión y la tendencia de las sucursales:
Presets de escena
Ahora suponga que la compañía tiene un proyecto de desarrollo llamado Hogwarts_Online2, que incluye el maestro de sucursal en línea, el desarrollo de la rama de desarrollo, el lanzamiento de la rama de prueba y la rama de características de desarrollo personal <rama de características>
Presentar sucursal y desarrollar sucursal
1.1) Establezca una conexión con el almacén remoto, cree su propia sucursal localmente y extraiga los archivos de la sucursal de desarrollo:
1.2) Cree un nuevo archivo gitflowDemo.txt en la rama actual, ingrese el contenido "study git", luego agregue, confirme
1.3) Compruebe si la rama de desarrollo remoto entra en conflicto con la rama actual a través del comando git pull:
Nota: Primero extraiga el código remoto antes de presionar para evitar que otros actualicen la versión remota durante el proceso de desarrollo. Si hay un conflicto de código, los dos negocian una resolución de conflicto. Cuando se desarrollan varias personas, el conflicto es inevitable.
1.4) git push empujará la modificación al origen de rama de característica remota gitflowDemo:
1.5) Realice una solicitud de fusión en GitLab y fusione en la rama de desarrollo:
Si desea retirar esta fusión, puede usar `git merge --abort`
crear solicitud de fusión:
Seleccione la rama de desarrollo:
No hay conflicto, puede fusionar directamente:
Al final podemos ver la fusión exitosa en la rama de desarrollo:
También podemos ver la dirección de la rama en el gráfico:
De esta forma, se completa la extracción y fusión del código de la rama de características y la rama de desarrollo.
Además, la rama de desarrollo puede estar más abierta en el trabajo, permitiendo el empuje. En este momento, podemos modificar directamente la fusión localmente y luego empujar al desarrollo remoto
Modifique el archivo gitflowDemo.txt a
agregar, comprometer, empujar
Cambie a la rama de desarrollo local, extraiga el código más reciente, combine el código de rama de gitflowDemo local e ingrese a la rama de desarrollo remoto
Esto es para verificar la actualización en GitLab:
rama de liberación
La rama de desarrollo cambia con frecuencia, y la rama maestra pertenece a la versión de límite superior, por lo que se requiere una versión de rama para pruebas internas. Esta es la rama de lanzamiento.
La operación de envío específica se basa en el alcance del permiso, que es el mismo que la operación de desarrollo en 1.
revisiones
A veces hay errores muy urgentes que deben modificarse de inmediato, y es demasiado tarde para realizar una prueba de fusión en cada rama; esto es usar el modo de revisiones para crear una rama de corrección de errores, omitir otras ramas directamente y modificar los cambios en el maestro.
Nota: Es peligroso conectarse en línea sin realizar pruebas. Lo he encontrado; cuando trabajaba en Huawei antes, un colega de desarrollo del grupo modificó una o dos líneas de código y consideró que no habría problemas. Omitimos nuestra prueba y la publicamos directamente a través de otros. En ese momento, el grupo en el que estaba era el grupo GNSS; como resultado, la función de posicionamiento de más de 10 millones de teléfonos móviles estaba directamente en riesgo de falla, y recibió muchas quejas y tuvo un gran impacto; finalmente relacionado Se detuvo urgentemente a los desarrolladores de tomar vacaciones, y nuestro equipo de prueba también agregó siete días de trabajo en once, y pagó muchas consecuencias por este pequeño cambio ~
3.1) Establezca una rama de corrección de errores y modifique el archivo para enviarlo a la rama remota:
3.2) Verifique GitLab en este momento y encontrará una rama adicional para modificar el bug02 extraído de la rama maestra:
3.3) Finalmente, el último dueño de la autoridad maestra se fusionará.
3.4) Después de modificar el error y conectarse directamente al maestro, es muy probable que la modificación de la rama maestra haya sido anterior a otras ramas; en este momento, es necesario actualizar otras ramas y fusionar la rama maestra; al mismo tiempo, elimine la rama de corrección de errores e intente mantener la rama limpia y ordenada. Grados
Suplemento
4. Suplemento
registro de git
rebase
Rebase, puede cambiar la línea de base de la dirección de la rama después de fusionar las ramas. Cuando hay muchas ramas, puede simplificar la visualización de la rama. La fusión de la dirección de la rama hace que el proceso parezca más simple.
En comparación con la tendencia de la rama después de la fusión:
Además, el rebase también puede modificar el historial del envío (no se usa ni se recomienda comúnmente)
Nota: Reglas de uso de Rebase
1. No ejecute rebase en ramas públicas
2. Las ramas principales están protegidas
git diff
Herramientas diff comunes:
- diff-solo muestra el aumento (+) o disminución (-) de una determinada línea
- vimdiff-más directo que diff mira
- Herramienta potente IDE, pantalla clara, fácil de usar
[Este artículo es de Hogwarts School of Testing]