Estoy trabajando para implementar Gitlab en mi empresa con una estrategia de flujo de trabajo. Mi idea es que los desarrolladores tendrán acceso a los repositorios pero, cada vez que intenten comprometerse, su código debe ser revisado.
Sé que puedo hacer que creen una rama antes de comprometerse, y luego crear una Solicitud de fusión después de que se haya enviado al repositorio. Todavía no estoy claro acerca de ciertas cosas ... La idea de que dependamos de las personas para crear una sucursal y luego una solicitud de fusión parece defectuosa, ¿hay alguna solución que obligue a algún tipo de política de que la sucursal maestra pueda mantenerse limpia a menos que un " admin "aprueba el código que está a punto de fusionarse con él. He leído el "flujo de trabajo del equipo github", pero no parece ofrecer una solución viable. Cualquier consejo sobre el proceso o su propia mejor práctica es apreciado. ¡Gracias!
fuente
"The idea that we rely on people to create a branch and then a merge request seems faulty"Me parece que tiene un problema mayor que la falta de características en un sistema de control de versiones. Si solo es cuestión de pasar el tiempo extra creando una sucursal, eche un vistazo a Atlassian Stash y su integración con Jira.Respuestas:
Empecé a trabajar con gitlab, leer la sección AYUDA proporciona un diseño de flujo de trabajo. En este punto, esta parece ser la mejor solución para mi pregunta. Si alguien tiene experiencia con este flujo de trabajo o consejo, agregue cualquier información adicional.
Desde la sección de AYUDA:
Flujo de trabajo
git clone [email protected]:project-name.gitgit checkout -b $feature_namegit commit -am "My feature is ready"git push origin $feature_nameEn la sección de confirmaciones de su repositorio, puede proteger las ramas, lo que obliga a los desarrolladores a seguir el proceso anterior, crear una rama y enviar una solicitud de fusión.
fuente