Git fusionando y probando

Estoy en una compañía muy pequeña y cuando comencé no tenían ningún control de fuente o problemas de seguimiento para hablar, así que configuré y estoy usando git. Soy el único desarrollador de software en este momento y, lamentablemente, tengo que hacer mi propia testing.

Soy bastante nuevo para git. Esperaba que alguien me dijera cómo hacer correctamente las testings de control de calidad con mi uso de git y mis fusiones con el maestro. No estoy seguro de cuándo debo volver a asignar mis nuevas funciones al maestro. Por el momento mi process es,

  1. Rama del máster (versión más reciente)
  2. Agregar mi nueva característica
  3. Prueba de banco solo la nueva característica
  4. Una vez que la function esté funcionando, haga una testing completa de todo el software, incluida la nueva function
  5. Una vez que la testing es exitosa, en la twig de características actualizo el número de versión y agrego un pequeño comentario al historial diciendo que ha sido completamente probado.
  6. Vuelva a fusionar con master y release como una actualización de software.

¿Es esta la forma correcta de hacerlo? Me siento un poco incómodo con la liberación del maestro cuando técnicamente no he llevado a cabo las testings en el maestro, sino en la twig de características. Probablemente estoy loco, pero como digo soy un poco nuevo y no estoy seguro de cuál es la mejor manera de hacerlo.

Me siento un poco incómodo con la liberación del maestro cuando técnicamente no he llevado a cabo las testings en el maestro, sino en la twig de características.

No hay problema si su fusión al máster ocurre como una fusión de avance rápido . En ese caso, el código antes y después de la fusión es idéntico. Incluso si usa git merge --no-ff y no hay cambios en la twig de destino ( master ), la fusión no toca el código. (Sin embargo, si realizó una fusión real, debe probar el código fusionado).

Debe probar cuándo cambia el código , no una reference de Git. Entonces, si git diff <tested-ref> genera alguna línea, testing el código nuevamente. Si la salida está vacía, no hay nada que rompa la funcionalidad, a less que haya files importantes no versionados.

Consulte https://git-scm.com/book/es/v2/Git-Branching-Basic-Branching-and-Merging para get más información sobre la fusión.