una - git tags best practices
¿Tiene sentido crear una rama para cada desarrollador? (2)
He usado Git solo para proyectos exclusivos. Ahora quiero seguir trabajando en un proyecto con otros dos desarrolladores.
¿Causaría problemas si un desarrollador desea confirmar los cambios pero otro desarrollador ha creado otra confirmación? Por lo tanto, ¿tendría sentido crear una rama para cada uno de nosotros?
Git, como la mayoría de los sistemas de control de versiones, es muy adecuado para el uso de múltiples desarrolladores. De hecho, es uno de los puntos principales de un sistema de control de versiones.
No hay necesidad de crear una rama por usuario. Incluso me atrevería a decir que sería contraproducente. Si está trabajando en la misma función, probablemente querrá obtener los cambios de cada uno, al jalar y fusionar. Crear ramas por usuario es redundante y complicará las cosas innecesariamente.
La situación de compromiso que usted describe no es problemática. Si otro usuario ha creado una nueva confirmación en la misma rama que usted, será detenido si intenta push . En su lugar, primero tendrá que desplegar la confirmación del otro usuario y fusionar (o modificar) su trabajo con esos cambios. Este es el comportamiento estándar de git pull .
La práctica normal es crear ramas basadas principalmente en características. Si desea orientación sobre la ramificación, esta es una estrategia popular .
Solíamos hacerlo en un lugar donde trabajaba. Cada uno de nosotros tenía al menos una sucursal personal; en realidad, creé una sucursal para cada tarea que tenía que hacer.
Cuando hubiéramos terminado, haríamos solicitudes de extracción a la sucursal principal. Si alguien se ha fusionado con el código de la rama principal que está en conflicto con tus cambios, debes resolver el conflicto como lo harías con cualquier otra plataforma de control de origen (como Tortoise, Mercurial, etc.), pero no es gran cosa si tus desarrolladores saben que estan haciendo
En mi opinión, esta es la mejor manera de llevar a cabo el desarrollo en equipo. Siempre puede probar en su propio entorno personal, cambiando rápidamente el código de cada sucursal según sea necesario. El sistema de solicitud de extracción también hace que la revisión por pares sea mucho más sencilla, ya que todos pueden colaborar y escribir comentarios en las líneas relevantes directamente en las páginas de github diff.