Yo había leído que cuando cambio de nombre de archivos en git, debe realizar los cambios, realizar su renombrar y, a continuación, la etapa de su archivo renombrado. Git reconocerá el archivo de los contenidos, en lugar de considerarlo como una nueva sin marcar archivo, y mantener el historial de cambios.

Sin embargo, precisamente esto esta noche terminé volviendo a git mv.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Cambiar el nombre de mi hoja de estilos en el Buscador de iphone.css a mobile.css

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    css/iphone.css
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   css/mobile.css

Así git piensa ahora he eliminado un archivo CSS, y se añade uno nuevo. No lo quiero, permite deshacer el cambio de nombre y dejar git hacer el trabajo.

> $ git reset HEAD .
Unstaged changes after reset:
M   css/iphone.css
M   index.html

De vuelta a donde empecé.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Permite el uso git mv lugar.

> $ git mv css/iphone.css css/mobile.css
> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    css/iphone.css -> css/mobile.css
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   index.html
#

Parece que estamos bien. Así que ¿por qué no git reconocer el cambio de nombre de la primera vez, cuando he usado el Buscador de?

  • Git pistas de contenido, no de los archivos, así que no importa cómo se obtiene el índice en el estado adecuado – add+rm o mv – produce el mismo resultado. Git, a continuación, utiliza su cambio de nombre/copia de detección para que sepa que fue un cambio de nombre. La fuente citada es inexacta, demasiado. Realmente no importa si usted modifique+cambiar el nombre en el mismo commit o no. Al hacer un diff entre modificar y cambiar el nombre, cambiar el nombre de la detección de lo verán como un cambio de nombre+modificación, o si la modificación es una reescritura total, lo voy a mostrar como añadir y eliminar – todavía no importa cómo lo realizó.
  • Si esto es cierto, ¿por qué no se detecta con mi renombrar usando el Finder?
  • git mv old new automáticamente actualiza el índice. Cuando cambie el nombre de fuera de Git, usted tendrá que hacer la git add new y git rm old a la etapa de los cambios en el índice. Una vez hecho esto git status va a funcionar como se espera.
  • Me acabo de mudar a un montón de archivos en un public_html dir, que se registran en git. Después de haber realizado git add . y git commit, todavía mostró un montón de ‘borrado’ de los archivos en git status. He realizado una git commit -a y las eliminaciones fueron comprometidos, pero ahora no tengo historia en los archivos de los que viven en public_html ahora. Este flujo de trabajo no es tan suave como me gustaría.
  • El enlace está muerto.
  • Enlace fijo. Realmente sólo reafirma lo que se vincula, que es sourceware.org/ml/frysk/2008-q1/msg00004.html

InformationsquelleAutor Greg K | 2010-04-14

11 Comentarios

  1. 327

    Para git mv la
    página de manual
    dice

    El índice se actualiza después de completar con éxito,
    [….]

    Así, en primer lugar, usted tiene que actualizar el índice de su propia
    (mediante el uso de git add mobile.css). Sin embargo

    git status
    aún aparecerán dos archivos diferentes

    $ git status
    # On branch master
    warning: LF will be replaced by CRLF in index.html
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       modified:   index.html
    #       new file:   mobile.css
    #
    # Changed but not updated:
    #   (use "git add/rm <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working directory)
    #
    #       deleted:    iphone.css
    #

    Usted puede obtener una salida diferente mediante la ejecución de
    git commit --dry-run -a que se traduce en lo que
    esperar

    [email protected] /d/temp/blo (master)
    $ git commit --dry-run -a
    # On branch master
    warning: LF will be replaced by CRLF in index.html
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       modified:   index.html
    #       renamed:    iphone.css -> mobile.css
    #

    Yo no te puedo decir exactamente por qué vemos estas diferencias
    entre git status y

    git commit --dry-run -a, pero
    aquí está una pista de
    Linus

    git realmente no atención sobre todo
    «cambiar el nombre de la detección de» internamente, y cualquier comete usted tiene
    hecho con renombra son totalmente independientes de la
    la heurística utilice para mostrar la cambia el nombre.

    Un dry-run utiliza el real cambio de nombre de los mecanismos, mientras que un
    git status probablemente no.

    • Usted no menciona el paso donde se hizo git add mobile.css. Sin git status -a sólo habría «visto» la eliminación de la anteriormente seguimiento iphone.css archivo, pero no hubiera tocado a la nueva, sin marcas de tránsito mobile.css archivo. También, git status -a no es válido con Git 1.7.0 y más tarde. «»git status» no es «git commit –dry-run» ya.» en kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt . Uso git commit --dry-run -a si desea que esta funcionalidad. Como otros han dicho, acabo de actualizar el índice y git status funcionará como el OP espera.
    • si vas a hacer una normal git commit no va a cometer el archivo renombrado y el árbol de trabajo sigue siendo el mismo. git commit -a derrotas casi cada aspecto de git flujo de trabajo/modelo de pensamiento—todo cambio es comprometido. ¿y si sólo desea cambiar el nombre del archivo, pero confirmar los cambios a index.html en otro commit?
    • sí, por supuesto, he añadido mobile.css que me han mencionado. Pero ese es el punto de mi respuesta: el hombre de la página dice que the index is updated cuando se utiliza git-mv. Gracias por la status -a aclaración, he usado git 1.6.4
    • Se me olvidó escribir que he añadido móvil.css antes de ejecutar git status (pero se puede decir que lo hice por la salida). He editado la respuesta y se debe mostrar mí punto mucho mejor, ahora
    • Acabo de expierienced un caso en el que ni siquiera git commit -a --dry-run identificados mi cambio de nombre. Sin embargo, después de commit git parece haber identificado correctamente. Ahora que usted sabe.
    • Gran respuesta! Yo estaba golpeando mi cabeza contra la pared tratando de averiguar por qué git status no era detectar el cambio de nombre. Ejecución de git commit -a --dry-run después de la adición de mi «nuevo» archivos mostró el cambia de nombre y, finalmente, me dio la confianza para cometer!
    • En git 1.9.1 git status ahora se comporta como git commit.
    • he Aquí un link actualizado para el Git 1.7.0 notas de la versión

  2. 72

    Tienes que añadir los dos archivos modificados al índice antes de git se reconocerá como un movimiento.

    La única diferencia entre mv old new y git mv old new es que el git mv también los archivos se añaden al índice.

    mv old new luego git add -A habría trabajado, también.

    Tenga en cuenta que usted no sólo puede utilizar git add . debido a que no aporta retiros para el índice.

    Ver Diferencia entre «git add -a» y «git add .»

    • Gracias por la git add -A enlace, muy útil, como yo estaba buscando de acceso directo!
    • Tenga en cuenta que con git 2, git add . no agregar retiros para el índice.
  3. 18

    Lo mejor es probarlo por ti mismo.

    mkdir test
    cd test
    git init
    touch aaa.txt
    git add .
    git commit -a -m "New file"
    mv aaa.txt bbb.txt
    git add .
    git status
    git commit --dry-run -a
    

    Ahora git status y git commit –dry-run -un muestra dos resultados diferentes, donde git status muestra bbb.txt como un nuevo archivo/aaa.txt se elimina, y el –dry-run comandos muestra el actual cambio de nombre.

    ~/test$ git status
    
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #   new file:   bbb.txt
    #
    # Changes not staged for commit:
    #   (use "git add/rm <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working directory)
    #
    #   deleted:    aaa.txt
    #
    
    
    /test$ git commit --dry-run -a
    
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #   renamed:    aaa.txt -> bbb.txt
    #
    

    Ahora seguir adelante y hacer el check-in.

    git commit -a -m "Rename"
    

    Ahora usted puede ver que el archivo está en el hecho de cambiar de nombre, y lo que se muestra en git status está mal.

    Moraleja de la historia: Si no está seguro de si su archivo consiguió cambiado de nombre, se emitirá un «git commit –dry-run». Si su muestra de que el archivo se ha cambiado el nombre, ya está bueno para ir.

    • Para lo que importa para Git, ambos son correctos. Este último se acerca más a usted, como commiter probablemente la vea, aunque. El los diferencia entre cambiar el nombre y borrar + crear es sólo en el sistema operativo y el sistema de archivos de nivel (por ejemplo, el mismo inodo# versus nuevo inodo#), que Git no le importa mucho acerca de.
    • Esta es la respuesta más clara para un noob como yo.
  4. 10

    tienes que git add css/mobile.css el nuevo archivo y git rm css/iphone.css, así git sabe acerca de ella. a continuación, se mostrará el mismo resultado en los git status

    que se puede ver claramente en el estado de la salida (el nuevo nombre del archivo):

    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    

    y (el antiguo nombre):

    # Changed but not updated:
    #   (use "git add/rm <file>..." to update what will be committed)
    

    creo que detrás de las escenas git mv no es nada más que un contenedor de secuencia de comandos que hace exactamente eso: borrar el archivo de índice y agregar bajo un nombre diferente

    • Yo no creo que tuve que git rm css/iphone.css porque pensé que esto iba a quitar la existente historia. Tal vez me estoy entendiendo el flujo de trabajo de git.
    • K: git rm no va a eliminar de la historia. Sólo elimina una entrada de índice para que el próximo commit no tienen la entrada. Sin embargo, aún existen en la ancestral se compromete. Lo que puede ser confundido acerca de es que (por ejemplo) git log -- new se detendrá en el punto donde se cometió git mv old new. Si quieres seguir cambia el nombre, el uso de git log --follow -- new.
  5. 10

    Para git 1.7.x los siguientes comandos trabajado para mí:

    git mv css/iphone.css css/mobile.css
    git commit -m 'Rename folder.' 
    

    No había necesidad de git add, ya que el archivo original (es decir, css/móvil.css) ya estaba en el compromiso de los archivos anteriormente.

    • Este. Todas las otras respuestas son ridículamente e innecesariamente complejo. De esta forma se mantiene el historial de archivos entre compromete de modo que se funde antes/después de cambiar el nombre de archivo no están rotos.
  6. 9

    Vamos a pensar acerca de los archivos de git perspectiva.

    Tenga en cuenta git no hace un seguimiento de los metadatos de tus archivos

    Su repositorio (entre otros)

    $ cd repo
    $ ls
    ...
    iphone.css
    ...
    

    y es en virtud de git de control:

    $ git ls-files --error-unmatch iphone.css &>/dev/null && echo file is tracked
    file is tracked
    

    Prueba con esto:

    $ touch newfile
    $ git ls-files --error-unmatch newfile &>/dev/null && echo file is tracked
    (no output, it is not tracked)
    $ rm newfile
    

    Al hacer

    $ mv iphone.css mobile.css
    

    De git perspectiva,

    • no hay iphone.css (eliminado -git advierte acerca de eso-).
    • hay un nuevo archivo móvil.css.
    • Esos archivos son totalmente ajenos.

    Así, git asesora acerca de los archivos que ya sabe (iphone.css) y los nuevos archivos se detecta (móvil.css), pero sólo cuando los archivos están en el índice o en la CABEZA git comienza a ver su contenido.

    En este momento, ni «el iphone.css eliminación» ni móvil.css están en el índice.

    Agregar iphone.css eliminación del índice de

    $ git rm iphone.css
    

    git le dice exactamente lo que ha pasado: (iphone.css se elimina. No ocurrió nada más)

    a continuación, agregar nuevo archivo móvil.css

    $ git add mobile.css
    

    Este momento, ambas de la eliminación y el nuevo archivo en el índice. Ahora git detecta el contexto es el mismo y exponerlo como un cambio de nombre. De hecho, si los archivos son del 50% similar se detecta como un cambio de nombre, que te permiten cambiar de móvil.css un poco, manteniendo la operación como un cambio de nombre.

    Ver este es reproducible en git diff. Ahora que los archivos están en el índice debe utilizar --cached. Editar móvil.css un poco, añadir que para el índice y ver la diferencia entre:

    $ git diff --cached 
    

    y

    $ git diff --cached -M
    

    -M es el «detectar cambia el nombre de» opción para git diff. -M significa -M50% (50% o más similitud hará git, se expresa en un cambio de nombre), pero usted puede reducir esto a -M20% (20%) si edita móvil.css mucho.

  7. 7

    Git reconocerá el archivo de los contenidos, en lugar de considerarlo como una nueva sin marcar archivo

    Que es de donde salió mal.

    Es sólo después de de agregar el archivo, que git se reconocerá de contenido.

    • Exactamente. Cuando protagonizaron git mostrará el cambio de nombre correctamente.
  8. 7

    Paso 1: cambie el nombre del archivo de viejoarchivo a newfile

    git mv #oldfile #newfile
    

    Paso 2: git commit y agregar comentarios

    git commit -m "rename oldfile to newfile"
    

    Paso 3: presione este cambio de servidor remoto

    git push origin #localbranch:#remotebranch
    
    • Por favor agregar algunos comentarios por lo que es útil para OP
    • El paso 2 es innecesario. Después de git mv, el nuevo archivo ya está en el índice.
    • seguro, voy a modificarlo. gracias
  9. 3

    No de la etapa de los resultados de su buscador de mover. Yo creo que si lo hizo el movimiento a través del Finder y, a continuación, hizo git add css/mobile.css ; git rm css/iphone.css, git sería calcular el hash del archivo nuevo y sólo entonces se dan cuenta de que los hashes de los archivos partido (y por lo tanto es un cambio de nombre).

  10. 2

    En los casos donde realmente tienes que cambiar el nombre de los archivos manualmente, por ejemplo. mediante una secuencia de comandos por lotes de cambiar el nombre de un montón de archivos, a continuación, utilizando git add -A . trabajó para mí.

  11. 2

    Para Xcode los usuarios: Si el cambiar el nombre de tu archivo en Xcode puede ver el icono de notificación de cambio para anexar. Si haces un commit con XCode usted realmente va a crear un archivo nuevo y se pierde el historial.

    Una solución es fácil, pero tienes que hacerlo antes de comprometerse con Xcode:

    1. Hacer un git Status en su carpeta. Usted debe ver que la protagonizaron los cambios son correctos:

    cambiado de nombre: Proyecto/OldName.h -> Proyecto/NewName.h
    el nuevo nombre: Proyecto/OldName.m -> Proyecto/NewName.m

    1. hacer commit-m ‘cambio de nombre de’

    A continuación, volver a XCode y podrás ver la insignia cambiado desde la a a la M y es guarde a cometer furtur cambios en el uso de xcode ahora.

Dejar respuesta

Please enter your comment!
Please enter your name here