remove - git tag best practices

Manejo de archivos renombrados en git (11)

Git reconocerá el archivo del contenido, en lugar de verlo como un nuevo archivo sin seguimiento

Ahí es donde te equivocaste.

Solo después de agregar el archivo, git lo reconocerá en el contenido.

Leí que al cambiar el nombre de los archivos en git , debes confirmar los cambios, realizar el cambio de nombre y luego configurar el archivo con el nuevo nombre. Git reconocerá el archivo a partir del contenido, en lugar de verlo como un nuevo archivo sin seguimiento, y conservará el historial de cambios.

Sin embargo, haciendo esto solo 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 #

Cambie el nombre de mi hoja de estilo en Finder 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í que git ahora piensa que he eliminado un archivo CSS y he agregado uno nuevo. No es lo que quiero, permite deshacer el cambio de nombre y dejar que git haga 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 #

Vamos a usar 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. Entonces, ¿por qué git no reconoció el cambio de nombre la primera vez que usé Finder?

Debe agregar los dos archivos modificados al índice antes de que git lo reconozca como un movimiento.

La única diferencia entre mv old new y git mv old new es que git mv también agrega los archivos al índice.

mv old new then git add -A también habría funcionado.

Ten en cuenta que no puedes usar git add . Porque eso no agrega eliminaciones al índice.

Consulte la diferencia entre "git add -A" y "git add".

En los casos en los que realmente tiene que cambiar el nombre de los archivos manualmente, por ejemplo. usando un script para cambiar el nombre de un grupo de archivos, luego usa git add -A . trabajó para mi.

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 -a muestra dos resultados diferentes donde git status muestra bbb.txt mientras se elimina un nuevo archivo / aaa.txt, y los comandos --dry-run muestran el nombre real.

~/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 sigue adelante y haz el check-in.

git commit -a -m "Rename"

Ahora puede ver que, de hecho, se ha cambiado el nombre del archivo y que lo que se muestra en el estado de git es incorrecto.

La moraleja de la historia: si no está seguro de si se cambió el nombre de su archivo, emita un "git commit --dry-run -a". Si se muestra que el nombre del archivo ha cambiado, está listo.

Para git mv la página de manual dice

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

Por lo tanto, al principio debe actualizar el índice por su cuenta (utilizando git add mobile.css ). sin embargo
git status seguirá mostrando 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 #

Puede obtener una salida diferente ejecutando git commit --dry-run -a que da como resultado lo que espera

Tanascius@H181 /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 #

No puedo decir exactamente por qué vemos estas diferencias entre el git status y
git commit --dry-run -a , pero aquí hay una pista de Linus

git realmente ni siquiera se preocupa por la "detección de cambio de nombre" en su totalidad, y cualquier confirmación que haya hecho con los nombres es totalmente independiente de las heurísticas que luego usamos para mostrar los nombres.

Una dry-run utiliza los mecanismos de cambio de nombre reales, mientras que un git status probablemente no lo hace.

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

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

No hubo necesidad de agregar git, ya que el archivo original (es decir, css / mobile.css) ya estaba en los archivos confirmados anteriormente.

Para usuarios de Xcode: si cambia el nombre de su archivo en Xcode, verá que el icono de la insignia cambia para anexar. Si realiza una confirmación con XCode, creará un nuevo archivo y perderá el historial.

Una solución es fácil, pero debe hacerlo antes de comenzar a utilizar Xcode:

Hacer un estado git en su carpeta. Debes ver que los cambios por etapas son correctos:

renombrado: Project / OldName.h -> Project / NewName.h renombrado: Project / OldName.m -> Project / NewName.m

cometer -m ''cambio de nombre''

Luego regresa a XCode y verás que la insignia cambia de A a M y se guarda para confirmar los cambios de furtur en el uso de xcode ahora.

Paso 1: renombrar el archivo de oldfile a newfile

git mv #oldfile #newfile

Step2: git commit y agregar comentarios

git commit -m "rename oldfile to newfile"

Paso 3: empujar este cambio a un servidor remoto

git push origin #localbranch:#remotebranch

Pensemos en tus archivos desde la perspectiva de git.

Tenga en cuenta que git no rastrea ningún metadato sobre sus archivos

Tu repositorio tiene (entre otros)

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

y está bajo control de git:

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

Prueba esto con:

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

Cuando tu lo hagas

$ mv iphone.css mobile.css

Desde la perspectiva de Git,

no hay iphone.css (se borra -gito advierte sobre eso-).
Hay un nuevo archivo mobile.css .
Esos archivos no tienen relación alguna.

Entonces, git informa sobre los archivos que ya conoce ( iphone.css ) y los nuevos archivos que detecta ( mobile.css ), pero solo cuando los archivos están en el índice o HEAD git comienza a revisar su contenido.

En este momento, ni "supresión de iphone.css" ni mobile.css están en el índice.

Añadir iphone.css eliminación al índice

$ git rm iphone.css

git le dice exactamente lo que ha sucedido: (se borra iphone.css . No sucedió nada más)

a continuación, agregue nuevo archivo mobile.css

$ git add mobile.css

Esta vez tanto la eliminación como el nuevo archivo están en el índice. Ahora git detecta que el contexto es el mismo y lo expone como un cambio de nombre. De hecho, si los archivos son similares en un 50%, detectará que, como cambio de nombre, le permite cambiar mobile.css mientras mantiene la operación como cambio de nombre.

Ver esto es reproducible en git diff . Ahora que tus archivos están en el índice debes usar --cached . Edite mobile.css un poco, agregue eso al índice y vea la diferencia entre:

$ git diff --cached

$ git diff --cached -M

-M es la opción "detectar renombrados" para git diff . -M significa -M50% (el 50% o más de similitud hará que git lo exprese como un cambio de nombre) pero puede reducirlo a -M20% (20%) si edita mucho mobile.css.

Usted no escaló los resultados del movimiento de su buscador. Creo que si lo hizo a través del Finder y luego git add css/mobile.css ; git rm css/iphone.css git add css/mobile.css ; git rm css/iphone.css , git computaría el hash del nuevo archivo y solo entonces se daría cuenta de que los hashes de los archivos coinciden (y por lo tanto es un cambio de nombre).

tienes que git add css/mobile.css el nuevo archivo y git rm css/iphone.css , por lo que git lo sabe. entonces mostrará la misma salida en git status

Puede verlo claramente en la salida de estado (el nuevo nombre del archivo):

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

y (el nombre antiguo):

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

Creo que detrás de escena git mv no es más que un script de envoltura que hace exactamente eso: elimine el archivo del índice y agréguelo con un nombre diferente