¿Por qué los archivos modificados git am Salida por ahí? ¿Cómo puedo adaptar mi flujo de trabajo para hacerlo mejor?

Question

Esto será muy larga, pero espero que usted podría tener paciencia conmigo.

Estoy tratando de usar git para poner el código fuente de mi equipo bajo control de versiones. Después de intentar encontrar diferentes enfoques que trabajarían para mí, finalmente me decidí a utilizar la función de git format-patch. Fwiw, el producto es una aplicación Web ASP.NET que se ejecuta en Windows y actualmente estoy usando msysgit .

Antecedentes:
Tengo un servidor de ensayo (espejos servidor de producción) que contiene todos los archivos aspx. Entonces creé un repositorio git utilizando init-db dentro de mi carpeta raíz y realizó un git add . el seguimiento de todos los archivos.

Con el fin para mí tener una copia local en mi ordenador portátil, de hecho me subió la cremallera de la carpeta ".git" desde el servidor de ensayo y FTP'ed a mi máquina local. Le cambió el nombre a "staging.git" e hizo un git clone staging.git webappfolder hacer mi desarrollo en contra.

Después de hacer 2 confirmaciones para feature1 y característica2, es el momento de aplicar los cambios de vuelta al servidor de ensayo. Hice un git format-patch -2 que da salida a los archivos y 0001blah.patch 0002blah.patch.

Estos 2 archivos de revisión se envían al servidor de puesta en escena y yo hicimos una git am 0001blah.patch en el propio servidor de ensayo. Haciendo un git log le muestra la atravesó. Pero cuando hago una git status, muestra Changed but not updated: modified: file1.aspx.

¿Qué significa eso exactamente? También he intentado hacer un git apply 0001blah.patch pero todo lo que tengo es un error" patch failed: file1.aspx: patch does not apply.

¿Hay un problema con mi flujo de trabajo? Cualquier penetración en cuanto a la manera apropiada o ayuda sería de gran ayuda. Una vez más, el modelo de aplicación de parches sería la más viable para nosotros en este momento, ya que no será la creación de un servidor SSH en el corto plazo.

Answer 1

Acabo de intentar esto:

rm -rf clone?

# clone 1 is the working copy
mkdir clone1
(
    cd clone1
    git init
    echo foo >> file1
    git add file1
    git commit -m "Initial state"
)

# clone 2 is the staging repo
git clone clone1 clone2

# create patches
(
    cd clone1
    git tag staging # tag to track what's in staging

    echo feature1 >> file1
    git add file1
    git commit -m "Feature 1"

    echo feature2 >> file1
    git add file1
    git commit -m "Feature 2"

    rm *.patch
    git format-patch staging
)

# apply patches
(
    cd clone2
    git am ../clone1/*.patch
    # Cygwin/msysgit line ending weirdness when patching. Aborting and
    # reapplying clears it up.
    git am --abort 
    git am ../clone1/*.patch
    git log
    git status
)

tiene el problema menor con los parches de no aplicar claramente sin hacer el am dos veces, pero termino con un directorio de trabajo limpio en el clon 2 con el contenido correcto de archivo1. Por lo tanto, no parece haber nada malo en su flujo de trabajo per se.

Git se aplican sólo se actualizará el árbol de trabajo, no realiza una confirmación.

Una vez dicho esto, yo no usaría un repositorio git para la puesta en escena. Mi flujo de trabajo probablemente haría un comunicado de la rama / tenedor del repositorio de desarrollo (o no), y acaba de desplegar copias limpias completos de eso.

Para las actualizaciones incrementales en el entorno de ensayo, sólo tiene que utilizar git tag staging en la rama de lanzamiento, "git diff staging..HEAD> update.patch" al correo electrónico, y el estándar de Unix "P1 parche" para aplicar debería funcionar. Es decir, a menos que realmente necesita tener el historial de cambios físicos en el servidor intermedio.

Answer 2

¿Usted intentó un

git am -3 

? Desde el git-doc am ,

-3
--3way

When the patch does not apply cleanly, fall back on 3-way merge

---

Nota: De Git Google Summer of Code 2009 , hay una proyecto para "Teach-git aplicar la combinación de 3 vías de repliegue git-am sabe":

  

Cuando el archivo de parches git-apply (s) los archivos no pueden parchear limpiamente. En un caso tal git-apply actualmente rechaza el parche.
  Si se llama desde entonces git-am una combinación de 3 vías se intenta por:

     

  
• tomar el "índice ..." los datos del parche y
  
• la construcción de un árbol temporal,
  
• aplicar el parche para que, a continuación,
  
• fusionar el árbol temporal a la rama actual.
  

     

Por diversas razones, sería bueno que hacer toda la danza árbol temporal directamente en el interior de Git a aplicar, ya que puede beneficiar a decir la de git-secuencia de "aplicar" de comandos, acelerar el procesamiento de git-am al bifurcar menos, etc