Soy muy nuevo en GIT / GitHub (tan nuevo como comenzar ayer). Me gustaría saber cuál es la mejor manera de administrar a varias personas que trabajan en el mismo proyecto con Github. Actualmente estoy gestionando un proyecto con cuatro desarrolladores.
¿Cómo hago para el flujo de trabajo y me aseguro de que todo esté sincronizado?
(Nota: todos los desarrolladores tendrán una cuenta universal).
¿Cada desarrollador necesita estar en una rama diferente?
¿Podré manejar a 2 personas que trabajan en el mismo archivo?
Por favor, publique una respuesta detallada, no soy un lector tímido. Necesito entender esto bien.
Respuestas:
Si todos los desarrolladores tienen acceso de confirmación al repositorio, no debería necesitar hacer nada especial. Sacarán los cambios del repositorio, harán sus propios cambios, se comprometerán localmente y luego volverán al repositorio público cuando tengan algo que funcione.
Si, por otro lado, tiene uno (o algunos) desarrolladores responsables de comprometerse con el repositorio, y los demás están proporcionando parches a estos. Haga que cada uno de ellos clone el repositorio en sus propias cuentas y que envíen solicitudes de extracción cuando tengan un cambio que deseen en el repositorio principal.
También es posible hacer clones específicos para trabajar en funciones específicas si lo desea. Usar el mismo flujo de trabajo con solicitudes de extracción para obtener cambios en el repositorio principal cuando se realiza la función.
Si por "Todos los desarrolladores tendrán una cuenta universal", quiere decir que todos los desarrolladores compartirán una cuenta de GitHub y aparecerán como el mismo confirmador en el repositorio, es una mala idea. Cree cuentas separadas y configúrelas como colaboradores si desea que todos tengan acceso de confirmación.
En cuanto a sus preguntas específicas:
No, use ramas para características, arreglos, etc. que requerirán más de una confirmación. Más de un desarrollador puede estar trabajando en la misma rama.
Sí, git maneja los conflictos realmente bien, por lo que no hay problemas para que las personas trabajen en el mismo archivo. Sin problemas, excepto que la resolución de conflictos no siempre es trivial si hay cambios fundamentales en un archivo que ha sido editado por más de un miembro. Sin embargo, esto no es nada que no se pueda superar hablando juntos. El control de versiones no reemplaza la comunicación.
¡Buena suerte!
fuente
git fetch upstreamseguidogit merge upstream/branchdebería sincronizarlo sin tener que volver a escribir su historial de confirmación local. Si eso no es un problema, simplementegit pull --rebasemoverá sus cambios locales no apresurados a la parte superior de la rama ascendente.Trabajamos con 2 desarrolladores y usamos este flujo de trabajo:
fuente
Aquí solo veo respuestas de texto, así que pensé en publicar una imagen de un buen flujo de información para empezar. Una imagen describe más de mil palabras:
fuente
Trabajo con otros 3 desarrolladores, y luchamos bastante con esto. Los desarrolladores a veces empujan los compromisos a la producción que realmente aún no están listos para el horario estelar porque atraen otros compromisos a sus cambios y luego empujan a la producción. Las ramas de la versión parecen funcionar bien para nosotros. Entonces, si la versión 1.0 es la versión estable actual, crearemos una rama para el desarrollo v1.1. Los desarrolladores harán cambios en esta rama. Nuestro servidor de prueba revisa esta rama y extrae los cambios según sea necesario. Cuando todas las características para v1.1 estén listas para funcionar y se realicen las pruebas, fusionaremos v1.1 con master y push. Con sucursales, el equipo de desarrolladores A puede trabajar en v1.1 y el equipo de desarrolladores B puede trabajar en v1.2. Ambos equipos pueden trabajar sin impactar entre sí. Si el equipo A desarrolla algo que B puede usar,
También usamos una rama de revisión que se usa para cambios inmediatos.
Aquí hay un enlace a una imagen de cómo se ve esto. http://nvie.com/img/[email protected]
fuente