Codificador de colaboración de prácticas ejemplares con Git

Question

estoy teniendo en la comprensión de los principios de Git de trabajo en equipo con algunas dificultades.

Considere un equipo de dos programadores: A y B. Ellos están trabajando en un Project. Además, hay un servidor remoto con un acuerdo de recompra en él. A y B están colaborando de forma remota. Hay algo de código en el repositorio ya.

Tengo un favor que pedirle ayuda en la organización de su flujo de trabajo paso a paso sobre Git.
1. Tienes que crear sus propias ramas locales?
2. ¿Cómo se podría cargar el código de trabajo en un servidor de producción? rsync?

Se apreciará Cualquier ayuda.

Answer 1

No es necesario para los programadores para crear su propia rama de trabajo. En el caso más simple, los programadores se comprometerán a la rama "master" de su propio repositorio, entonces esos git push commit en el repositorio de aguas arriba.

Para desplegar en un servidor de producción, una forma de hacerlo es utilizar git clone en el servidor de producción para obtener un repositorio local. Entonces, para actualizar el servidor de producción, inicie sesión y git pull. se aplicarán los cambios que se han confirmado en el repositorio principal.

Los desarrolladores pueden crear sus propias ramas opcionalmente, ya sea para su propio uso (en su repositorio local solamente), o ramas para compartir con otros (empujando las ramas hasta el depósito compartido).

Answer 2

1. Cada desarrollador tendrá su propio clon del repositorio. Se puede crear ramas de trabajo tema como y cuando quieren. Su clon personal es su propio terreno, pueden hacer lo que quieran.

2. Cada desarrollador debe tener su propio repositorio público remoto, que pueden empujar / tirar hacia / desde. Por lo general, si se quiere liberar el código, habrá una persona que finalmente decide lo que se va a entrar en la liberación y lo que se recorta. repositorio remoto de esa persona debe tener una rama que representa versiones estables. Un ejemplo es el encargado de la liberación que quiere incorporar el trabajo de B en el lanzamiento. A continuación, esperará hasta que empuja B su trabajo a su propio repo remoto. A continuación, se tire de la obra de B a su clon locales, probar cosas, fusión, comprometerse, y empujar a su propio repo pública (de A) para su liberación.

En (2) que he descrito solamente uno de los muchos flujos de trabajo diferentes que están disponibles para uso con un SCM distribuido como git. Hay muchos otros. Este href="http://progit.org/book/ch5-1.html" rel="nofollow noreferrer"> página es especialmente agradable en la descripción de algunos otros.