¿Por qué git deja archivos modificados por ahí? ¿Cómo puedo adaptar mi flujo de trabajo para mejorar?

Question

Esta será larga, pero espero que puedan soportarlo.

Estoy tratando de usar git para poner el código fuente de mi equipo bajo control de versión. Después de tratar de encontrar diferentes enfoques que funcionen para mí, finalmente decidí usar la función 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 producción espejos) servidor de ensayo que contiene todos los archivos aspx. Luego creé un gpo repo usando init-db dentro de mi carpeta raíz e hice un git add . para rastrear todos los archivos.

Para poder tener una copia local en mi computadora portátil, en realidad comprime la carpeta ".git" del servidor de transferencia y la transfiero por FTP a mi máquina local. Lo renombré a "staging.git" e hice un git clone staging.git webappfolder para hacer mi desarrollo en contra.

Después de hacer 2 confirmaciones para feature1 y feature2, es hora de volver a aplicar los cambios al servidor de transferencia. Hice un git format-patch -2 que da salida a los archivos 0001blah.patch y 0002blah.patch.

Estos 2 archivos de parche se envían al servidor de almacenamiento intermedio y yo hice un git am 0001blah.patch en el propio servidor de almacenamiento intermedio. Al hacer un git log, se muestra el compromiso. Pero cuando hago un git status, muestra Changed but not updated: modified: file1.aspx.

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

¿Hay algún problema con mi flujo de trabajo? Cualquier idea sobre la forma adecuada o la ayuda sería extremadamente útil. Una vez más, el modelo de parches sería el más viable para nosotros en este momento, ya que no vamos a configurar un servidor SSH pronto.

Answer 1

acabo intentado 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 terminar con un directorio de trabajo limpio en el clon 2 con la contenido correcto de file1. Por lo tanto, no parece haber ningún problema con su flujo de trabajo per se.

Git apply solo actualizará el árbol de trabajo, no realizará una confirmación.

Dicho esto, no utilizaría un repositorio de git para la puesta en escena. Mi flujo de trabajo probablemente haría una rama/bifurcación de lanzamiento del repositorio de desarrollo (o no), y simplemente implementaría copias limpias completas de eso.

Para actualizaciones incrementales del entorno de ensayo, simplemente use git tag staging en la rama de publicación, "git diff staging..HEAD> update.patch" para enviar por correo electrónico, y el parche estándar "parche -p1" para aplicarlo debería funcionar. Eso es a menos que realmente necesite tener el historial de cambios físicamente en el servidor intermedio.

Answer 2

¿Usted intentó un

git am -3 

? Desde el git-am doc,

-3 
--3way 

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

---

Nota: De Git Google Summer of Code 2009, hay un proyecto de "enseñar git-aplicar el 3 vías fusionar repliegue git-am sabe":

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

• teniendo el "índice ..." los datos del parche y
• la construcción de un árbol temporal,
• la aplicación de la parche para eso, luego
• fusionando el árbol temporal a la rama actual.

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