¿Cómo trabajar simultáneamente en varias versiones diferentes de archivos con git?

Question

Actualmente estoy trabajando en mi propia caja de herramientas de neuroimágenes que se ejecuta bajo MATLAB/SPM8 y la mayoría de los archivos de programa en mi repositorio son archivos MATLAB *.m. Tengo diferentes ramas de características y una rama analysis, que utilizo para análisis continuos usando la versión actual. Al mismo tiempo estoy desarrollando el código en master y cuentan con ramas, que luego se combinan constantemente en la rama master.

Ahora el problema es que, los análisis que estoy corriendo en analysis rama toman mucho tiempo (incluso días), y durante ese tiempo no soy capaz de git checkout master o git checkout new-feature. Esto limita mi productividad en serio.

Así que, como no es posible mantener varias ramas abiertas al mismo tiempo simultáneamente, Estoy pensando en mover la rama analysis del repositorio de desarrollo a su propio repositorio. La cuestión es que si yo git init un nuevo repositorio basado en la rama actual analysis, hay alguna manera de git merge de alguna manera de la rama actual master (del repositorio de desarrollo) para poder usar el código recientemente desarrollado de mi desarrollo repositorio en el nuevo repositorio de análisis?

Answer 1

Si git clone su repositorio existente en un nuevo repositorio, puede entonces git push o git fetch de una a la otra para que coincida con los árbitros (ramas) que ha cambiado; no hay fusiones involucradas. El contenido del repositorio se vinculará automáticamente para ahorrar espacio en el disco.

Si se utiliza la opción --mirror a git clone y git push, se omite que tenga una sucursal de seguimiento a distancia y sólo tienen las mismas ramas tanto, lo que es más simple y más simétrica, pero menos de un uso convencional de git. Para la simplicidad máxima de "seguir los tutoriales", en su lugar organice un tercer repositorio "central" (que se debe crear --bare) del cual ambos depósitos de trabajo son clones.

No se requieren fusiones (que no sean "fusiones de avance rápido" que no son realmente fusiones, sino que reemplazan un antiguo encabezado con un descendiente más nuevo) porque está trabajando en las mismas ramas; solo tienes dos copias de ellos. Cuando su análisis esté completo y pueda actualizar la rama de análisis, solo git merge --ff-only master mientras está en analysis; puede hacer esto en el repositorio que sea conveniente, pero no olvide sincronizar los cambios con un git push other-repository.

---

Otra opción (ya que Git versión 2.5) es el comando git worktree, lo que permite que varios árboles de trabajo independientes en los que se puede git checkout, etc., de forma independiente. La diferencia entre esta y la opción anterior de crear un clon es que aquí solo hay un conjunto de ramas .

Sin embargo (a partir de la versión 2.8) esto todavía se considera una característica "experimental", y no lo he utilizado personalmente para comentar sobre su fiabilidad y utilidad.

Answer 2

Como alternativa a la clonación del repositorio tal como lo explica Kevin Reid, también puede usar git-new-workdir para crear una segunda copia de trabajo para su repositorio. De esta forma, ambas copias de trabajo siempre verán automáticamente las mismas ramas, porque comparten un git repo.

La ventaja sobre la clonación del repositorio es que no hay necesidad de ninguna sincronización/fusión manual. En el momento en que se compromete en workdir A, la confirmación será visible en workdir B (por ejemplo, git log).

Solo advertencia: cuando cambia el repositorio (confirmando, redefiniendo, restableciendo una rama, etc.), no debería tener la misma rama desprotegida en el otro directorio de trabajo; de lo contrario, se confundirá un poco (consulte git-new-workdir: Commit in working tree A causes bogus changes in tree B).

Ver: git working on two branches simultaneously