¿Cómo debería un equipo impulsar sus cambios a git master?

Depende de si desea tener un repositorio central o no. Muchas organizaciones han estado usando y continúan usando un repositorio central cuando cambian a git. También depende del acceso, la confianza y cuántos desarrolladores sean. Si son solo unos pocos desarrolladores y todos confían en los demás, iría con un repositorio central desnudo al que todos empujan y extraen. Mantenlo simple.

Si tiene 100 desarrolladores y tal vez también desarrolladores externos en los que no confía usando su repositorio central y desea restringir el acceso por otras razones, entonces las solicitudes de extracción podrían ser la solución.

Lo importante es observar qué tipo de flujo de trabajo desea USTED y tener en cuenta que git no se interpondrá en su camino y le permitirá decidirlo por sí mismo.

La forma tradicional es fork-pull, es decir, Linus-fork del kernel de Linux es la línea oficial. La diferencia con su enfoque actual es la cantidad de control que tiene sobre los cambios. Si no necesita este control o si no puede verificar los cambios de todos modos porque no tiene tiempo para hacerlo, no hay ninguna ventaja en hacerlo manualmente. Git maneja reinicios/eliminaciones muy bien y siempre puedes volver atrás en el historial.

Bifurcar un repositorio git es un enfoque mucho mejor cuando se trabaja en equipo, ya que garantiza que su repositorio y código nunca lleguen a una etapa inconsistente. Sin embargo, esta práctica no es muy común en el mundo. La mayoría de los equipos han convertido en una tradición que todos trabajen en la misma rama al mismo tiempo, esto es un poco peligroso, pero se puede hacer eficiente agregando una funcionalidad de envío de alertas por correo electrónico en el enlace posterior a la recepción del repositorio para que el otro los compañeros de equipo pueden realizar los cambios tan pronto como reciban una alerta por correo electrónico.

Espero que esto ayude.

Yo diría que hay dos flujos de trabajo principales:

1. Como dijo Magnus, todos están empujando al repositorio desnudo "bendito", mientras trabajan en los clones locales del mismo.
2. Un flujo de trabajo más restringido puede sugerir un número limitado de personas que tienen acceso de inserción al bendito repositorio y todos los demás contribuyentes envían solicitudes de extracción o, si la extracción es técnicamente difícil, proporcionan parches. Pero están extrayendo del bendito repositorio para mantener sus repositorios sincronizados. Este flujo de trabajo implica la revisión del código por parte de "tenientes" antes de que el cambio vaya al bendito repositorio.