El conjunto de posibles workflows puede ser difícil para saber por dónde empezar cuando se implemente Git en el lugar de trabajo. Ofrecemos un punto de partida mediante encuestas más comunes a los workflows de Git para los equipos de la empresa.
Los workflows están diseñados para ser guías en lugar de reglas concretas. Mostraremos lo que es posible, por lo que puede mezclar y combinar los aspectos de diferentes workflows para adaptarse a sus necesidades individuales.
La transición a un sistema de control de versiones distribuido puede parecer una tarea de gran proporción, pero no tienes que cambiar tu workflow existente para tomar ventaja de Git. Tu equipo puede desarrollar proyectos de la misma manera como lo hacen con Subversion.
Sin embargo, el uso de Git para alimentar el workflow de desarrollo presenta algunas ventajas sobre SVN. En primer lugar,da a todos los desarrolladores su propia copia local de todo el proyecto. Este entorno aislado permite a cada desarrollador trabajar independiente de todos los otros cambios en un proyecto -Ellos pueden añadir commits a su repositorio local y olvidar por completo acerca del desarrollo upstream hasta que sea conveniente para ellos.
En segundo lugar, le da acceso a la robusta ramificación y modelo de fusión de Git . A diferencia de SVN, en Git las ramas están diseñadas para ser un mecanismo de seguridad para la integración de código y el intercambio de modificaciones entre repositorios
Los desarrolladores comienzan clonando el repositorio central. En sus propias copias locales del proyecto, editan archivos y envian los cambios como lo harían con SVN; sin embargo, estas nuevas confirmaciones se almacenan localmente -son completamente aislada del repositorio central. Esto permite a los desarrolladores diferir la sincronización de upstream hasta que estén en un punto de ruptura conveniente.
Para publicar los cambios en el proyecto oficial, los desarrolladores realizan un "push" de la rama principal local en el repositorio central. Esto es el equivalente a svn commit, excepto que se añade a todos los commits locales que no están ya en la rama master central.
Vamos a mostrar la forma en que un equipo pequeño colaboraría usando este workflow. Veremos como dos desarrolladores, Juan y María, pueden trabajar en funciones separadas y compartir sus contribuciones a través de un repositorio centralizado.
Cada desarrollador crea una copia local del proyecto. Esto se realiza con el comando git clone.
En su repositorio local, Juan desarrolla sus features usando el proceso commit estándar: editar, etapa y commit.
git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file </some-file>
Mientras tanto, María está trabajando en su propio feature en su propio repositorio local utilizando el mismo proceso editar / etapa/ commit.
Juan termina su feature, publica sus commits locales al repositorio central para que los otros miembros del equipo pueden acceder a ellos.
Vamos a ver lo que sucede si María intenta subir su feature después de que Juan ha publicado con éxito sus cambios en el repositorio central. Ella utiliza el comando git push para subir su módulo. Pero, ya que su historia local se desvía del repositorio central, Git rechazará la solicitud con un mensaje de error en lugar detallado:
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
sincronizar/
Esto evita que María sobrescriba los commits oficiales. Ella tiene que extraer las actualizaciones del repositorio de Juan en su repositorio local e integrarlos con sus cambios locales y, a continuación, intentar subir su actualización de nuevo.