Única twig de trabajo con Git

Breve descripción breve

¿Hay una forma portátil de usar un único repository con múltiples cajas ? Como alternativa a tener clones múltiples donde hay demasiada sobrecarga (empujar / tirar / sincronizar …) y el riesgo de sobreescribir los enlaces duros de .git/objects (que ni siquiera funciona en Windows).


Nuevo en git y curioso de escuchar pensamientos de usuarios experimentados de git.

¿Hay alguna razón conceptual por la que git solo funcione con UNA twig a la vez? Parece absolutamente impráctico tener que volver atrás y avanzar entre las twigs, cuando la mayoría de las veces necesito trabajar en al less dos twigs diferentes al mismo time, por ejemplo, build, ejecutar en paralelo, etc.

Ok, entonces tal vez un desarrollador realmente no necesite trabajar en dos twigs exactamente al mismo time. Pero consultar otra sucursal no incluye automáticamente elementos ignorados, como files de salida de compilation. Entonces se requiere una nueva reconstrucción,

Hay este script git-new-workdir que se supone que permite múltiples twigs de trabajo, pero para git-new-workdir , no es parte de la versión de Git, aunque ha estado en circulación por 3 años, así que no confío en que guarde mis files consistente. Y en segundo lugar, no puedo encontrarlo como parte de la distribución de Windows, que es una de las máquinas que uso para el desarrollo.

Entonces, la única opción oficial es crear un nuevo "clon" para cada twig, lo que parece incorrecto, ya que cada clon es un repository completo. Ni siquiera sabría a qué llamar los directorys de clones: ¿uso el nombre del repository o el nombre de la twig o ambos? ¿Qué ocurre si creo otra twig fuera de esa twig?

Actualización de caso de uso real (sugerencia de @ Philip)

Por lo general, trabajo en dos lanzamientos principales / menores, con funciones en paralelo. También hay una twig de desarrollo ocasional, donde entran las características experimentales, antes de fusionarse con alguna versión futura.

Durante el desarrollo de características, a menudo el comportamiento se degrada y es más eficiente compararlo con el comportamiento anterior a los cambios. Revisar una twig / revisión anterior no es lo suficientemente bueno, porque muchas veces se trata de depurar uno al lado del otro, lo que significa que ambas revisiones deben revisarse simultáneamente en el disco duro.

Entonces, el enfoque más conveniente y natural sería mantener algunas de las llamadas twigs "activas" revisadas cada una en su propio directory, con sus propios binarys comstackdos. Esto también ahorraría time de compilation y configuration local ocasional (es decir, files de configuration que deben modificarse después de cada pago y envío para que el producto se ejecute).

Si quieres estar haciendo esto,

Recomendaría al 100% escribir una aplicación personalizada 1 que administre este process de manera infalible.

Un punto de partida podría ser

 GIT_WORK_TREE=/worktrees/stable git checkout -f origin/stable GIT_WORK_TREE=/worktrees/unstable git checkout -f origin/unstable 

etc.

Específicamente me aseguraré de que ninguna de tus copys en funcionamiento se vea (remotamente) como un repository habitual para que los commands normales de git no se apliquen.

Usar los commands git (sub) usuales es la receta para el desastre porque algún día se encontrará con un script que no usa GIT_DIR, GIT_WORK_TREE, GIT_INDEX de la forma que debería (o lo esperaba).


1 (tal vez basado en NGit, o enlaces Git similares para Python, Ruby – watever es portable en su universo)

Una twig cuando está desprotegida es solo un puntero a una confirmación ( dentro de un gráfico de confirmación ).
Como tal, Git no puede verificar dos confirmaciones de ese gráfico al mismo time .

En realidad, consulte " Varios directorys de trabajo con Git? ".
Con Git 2.5+ (Q2 2015), puede tener múltiples treees de trabajo para un repository de git, con el git checkout --to=<path> .

Eso le permite verificar una twig en un directory de trabajo separado en <path> . Un nuevo directory de trabajo está vinculado al repository actual.

Ese enlace es "portátil" (es decir, funciona incluso en Windows) ya que está registrado en el directory repo $GIT_DIR/worktrees .


Respuesta original (2011):

git ramas

(Fuente: Scott Chason, ProGIT Book, http://progit.org/book/ch3-1.html , CC-BY-NC-SA)

Si necesita trabajar en dos twigs diferentes al mismo time, simplemente clone su repository y select ( git checkout ) la otra twig en ese clon. Puede usar el nombre de la twig como el nombre del directory raíz para ese clon.
Y puedes crear twigs en cualquiera de esos repositorys.


Entonces, la pregunta es: ¿por qué Git no puede tener DOS pointers, uno para cada directory? –

Como se menciona en " Popularidad de Git / Mercurial / Bazaar versus el cual recomendar ", Git es en esencia su gestión de contenido . Cada confirmación representa una instantánea completa del repository.
No puede ver dos contenidos en el mismo contenedor (directory de trabajo), aunque puede mantener la reference de todos los pointers (twigs) que desee.

Operaciones locales de Git

Solo llenas el directory de trabajo con un contenido.

Si git clone con una ruta local, todo lo que se encuentra debajo de .git/objects (es decir, la mayoría de los commits y datos en su repository) está enlazado al repository anterior siempre que sea posible y ocupa espacio libre al lado del disco. Entonces, si quieres dos directorys de trabajo diferentes, no es muy costoso clonar tu repository localmente. Intentar gestionar dos directorys de trabajo diferentes desde un repository podría funcionar, pero no vale la pena.

Básicamente, ejecute git clone /path/to/old/repo new_repo y todo solo funcionará.

Lo que está buscando se llama alternos , lo que le permite a un repository depender de otro para sus objects. Su uso no es muy común porque el espacio en el disco es barato y debe tener cuidado de no eliminar accidentalmente los objects que necesita el repository dependiente.

En realidad, git-new-workdir fue hecho para exactamente este problema. Tengo el mismo problema y lo uso sin ningún problema. Sobre sus reservas:

Hay este script git-new-workdir que se supone que permite múltiples twigs de trabajo, pero para empezar, no es parte de la versión de Git, aunque ha estado en circulación por 3 años, así que no confío en que guarde mis files consistente.

Bueno, yo (y muchos otros) lo he usado durante años, y no he encontrado ningún error, ni he oído hablar de ningún problema real (aparte de algunas limitaciones menores, ver más abajo). Puede que no parezca mucho, pero incluso con git mismo (o cualquier proyecto libre de SW, para el caso), la única garantía real que obtienes es "nadie ha encontrado un problema todavía". No sé por qué git-new-workdir todavía está en contrib, pero no creo que eso te detenga.

Y en segundo lugar, no puedo encontrarlo como parte de la distribución de Windows, que es una de las máquinas que uso para el desarrollo.

Eso puede deberse a que su distribución optó por no include el contrib/ material.

Si usa git en Cygwin, puede simplemente download y usar el script original git-new-workdir . Funciona bien, lo uso yo mismo. Si usa msysGit, hay puertos disponibles: https://github.com/joero74/git-new-workdir/blob/master/git-new-workdir.cmd y https://github.com/dansmith65/git/ blob / master / contrib / workdir / git-new-workdir-win . Sin embargo, no sé sobre su calidad.

Limitaciones de git-new-workdir

Solo por completitud, estas son las limitaciones que conozco:

  • Si selecciona la misma twig en ambos directorys de trabajo y luego confirma algo en un directory de trabajo, el estado del otro se confundirá: git-new-workdir: Confirmar en el tree de trabajo A causa cambios falsos en el tree B
  • Aparentemente, no debe usar git-new-workdir para copyr un directory de trabajo ya creado por git-new-workdir . Simplemente copie el clon original. En realidad, creo que las versiones recientes del script detectarán esta situación y error.
  • git prune prune no respeta correctamente las inputs de reflog

¿Tal vez los submodules podrían ayudarte a tener directorys independientes?

Si lo entiendo correctamente, está buscando la capacidad de CopyOut una twig específica o comprometerse en una sucursal, en un directory independiente, con fines de investigación y comparación, mientras sigue teniendo su twig de desarrollo / CopyOut de CopyOut actual como su principal git 'reference'.

Espera que el directory independiente 'copydo' sea poco probable que se vuelva a comprometer directamente a git.

Un enfoque no probado sería usar el command base git con sus [--git-dir=<path>] [--work-tree=<path>] , y, a través de una secuencia de commands cuidadosa, ajustar / corregir su HEAD / Indice como lo hace con CopyOut y retroceda a su twig actual.

Las advertencias habituales se aplican ..

  1. Crear nuevo work_dir
  2. Comienza a señalar git a work_dir
  3. Guardar CABEZA actual
  4. Se requiere checkout branch / commit (debe entrar en work_dir)
  5. Establezca HEAD nuevamente en el valor guardado (¡Esto es un truco y puede no funcionar sin pasos para mantener el índice correcto!)
  6. cerrar git para 'olvidar' la configuration work_dir
  7. reinicie git en su antiguo directory y su twig asociada

Esto definitivamente requeriría testings cuidadosas, y probablemente necesite un ajuste alnetworkingedor de los pasos 3 y 5, de modo que el paso 6-7 sea cierto.

La opción git work-tree podría proporcionar un mecanismo para introducir cambios desde el directory de copydo si tuviera correcciones de errores que necesitaran confirmarse en la twig correspondiente.

ACTUALIZAR ——————————–
Las instrucciones de clunx se basan en la vista de un usuario de Windows.

 # this is run from your main work dir (that contains .git) Copy .git/HEAD MyBackup # HEAD will contain the line similar to "ref: refs/heads/master" mkdir <path> # the path should be 'somewhere else', not in your existing directory # If the path doesn't exist the following checkout will fail Git --work-tree=<path> checkout <branch> # this will extract the latest commit on that branch to the work tree path # or use a commit sha1 instead of <branch>, if you want an exact commit # Note: your index will be updated to reflect the checked out files, as will HEAD. Copy MyBackup .git/HEAD # set the HEAD back to where it was Git reset # reset the index appropriate for the previous Head. # note we dropped the --work-tree parameter 

Se puede utilizar una técnica similar para tomar cualquier revisión de la ruta extraída señalando --work-tree en el lugar correcto en el momento correcto y asegurándose de que el índice esté correctamente configurado. No olvide las advertencias habituales [copy de security, copy de security y copy de security].

Esto funcionó para mí en un informe de testing que tengo. Algunas de las acciones fueron en Windows.