imagen workflow

WORKFLOWS

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.

imagen workflow centralizado

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


Cómo trabaja


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.

repositorio central repositorio central

Ejemplo


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.


Alguien inicializa el repositorio central


repositorio

Todos clonan el repositorio central


Cada desarrollador crea una copia local del proyecto. Esto se realiza con el comando git clone.

work john

Juan trabaja sobre su feature


work john

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>

María trabaja sobre su feature


repositorio imagen

Mientras tanto, María está trabajando en su propio feature en su propio repositorio local utilizando el mismo proceso editar / etapa/ commit.


Juan publica su feature


publicación john

Juan termina su feature, publica sus commits locales al repositorio central para que los otros miembros del equipo pueden acceder a ellos.


María intenta publicar su feature


error maría imagen

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.