Múltiples sets de cambios simultáneos con Git

Mi compañía está evaluando mudarse a un nuevo sistema SCM, y git es uno de los contendientes finales que se están considerando. Antes de que empezáramos, se nos ocurrió una list de casos de uso que debía ser respaldada.

Un caso de uso para el que no tengo una respuesta sólida con git es trabajar simultáneamente en múltiples "sets de cambios" en un solo "proyecto".

En nuestro SCM actual, asocia un file con una "tarea" cuando lo "revisa". Siempre que sus cambios estén en files diferentes, puede tener tantas "tareas" activas como desee.

En mi experiencia con git, no asocias los cambios en un "set de cambios" (commit) hasta que los preparas para el commit. Sin embargo, solo hay un área de preparación, por lo que solo puede hacer esto para un "set de cambios" a la vez (y aún no puede asociar un resumen / descripción).

También hay "escondite", pero el uso típico de esto sería incorporar múltiples cambios lógicos en una compilation para ejecutar testings en contra, por lo que deben estar simultáneamente "activos".

A medida que escribo esta publicación, me viene a la mente un posible flujo de trabajo: hacer una confirmación por "set de cambios" al iniciarla, y confirmar + 'rebase -i' / squash en la confirmación correspondiente a medida que realizas más cambios. Sin embargo, eso parece demasiado complejo y probablemente no sea bien recibido.

¿Hay una mejor manera? ¿O una justificación convincente de por qué deberíamos dejar de usar este flujo de trabajo (tendría que ser muy convincente)?

¡Gracias por adelantado!

Cambiamos a Git hace más de un año como un gran grupo de desarrollo y nos ha servido muy bien.

Tienes razón, cuando usas git solo tienes un espacio de trabajo disponible a la vez.

git no rastrea realmente un file individual, como otros SCM. Incluso cuando hace un cambio de nombre, realmente se almacena como una eliminación y se agrega bajo el nuevo nombre. Por lo tanto, será necesario modificar el flujo de trabajo de agregar un file a una tarea.

En cambio, agregarías tu tarea como una sucursal. Las sucursales en git son extremadamente livianas y funcionan muy bien. Un ejemplo de flujo de trabajo sería que tiene su código de publicación en la twig principal (troncal) y, a medida que surjan nuevas tareas, creará una twig de maestro, realizará sus cambios allí, validará, probará, aprobará y se fusionará en maestro. Puede mantener la twig como reference o limpiarla.

Donde pueda tener múltiples versiones de un producto para admitir y parchear, la adopción de un sistema de sucursal de liberación puede funcionar mejor para usted. master está reservado para su próxima versión y, a medida que se envían las versiones, cree una versión / <version>. Eso le permite volver más tarde y reparar una versión y volver a comstackr confiando en que está utilizando la misma base de código que envió. También proporciona un buen lugar para hacer métricas sobre el trabajo realizado entre lanzamientos.

Stash, se usa realmente para preservar temporalmente los cambios a medida que cambias de twig. Por ejemplo, si comenzó a trabajar en una tarea y se da count después de varias ediciones que está en la twig incorrecta. Stash moverá esos cambios a un espacio de espera, permitiéndole verificar la twig correcta y mostrar sus cambios en su espacio de trabajo.

Si tiene varios desarrolladores trabajando al mismo time, es probable que desee alejarse de un método de rebase y utilizar una metodología de fusión. Debido a que el repository de git es una cadena de confirmaciones que incluye el hash de la confirmación principal, el rebasamiento hace que las confirmaciones se vuelvan a escribir y, como resultado, requiere que los desarrolladores se vuelvan a clonar desde el server que aloja su repository. El método de fusión simplemente requiere fusionar los cambios de otros que se enviaron al server antes de impulsar los cambios.

Espero que ayude.

Esto suena como una function de nivel de interfaz de usuario, en lugar de algo que debe ser fundamental para el SCM. Sé que (por ejemplo) Eclipse capas funcionalidad como esta en la parte superior de cualquier SCM que desea utilizar.

La dificultad de no tenerlo en el SCM en sí es recordar qué files van con qué cambio. Estoy de acuerdo con JasonM en que lo correcto aquí es utilizar las sucursales de forma local en lugar de mezclar los cambios entre sí. Considera por qué estás mezclando los cambios y qué haces cuando dos cambios en los que estás trabajando necesitan para tocar el mismo file Varios lugares en los que he trabajado tienen flujos de trabajo similares a los que describes, sobre todo para que las personas no estén atadas a una cosa a la vez y sobre todo al recordar qué files deberían ir a dónde (en lugar de usar herramientas). Todos ellos se habrían beneficiado al poder usar múltiples sucursales locales en lugar de mezclar los cambios juntos, aunque estoy seguro de que no todos lo habrían visto así, especialmente al principio.