¿Qué es este mensaje de advertencia de Git al enviar cambios a un repositorio remoto?
La descripción es un poco concisa. Simplemente agregué un archivo en mi rama maestra local y lo devolví a un repositorio remoto. ¿Alguna idea de por qué surge esto?
advertencia: actualizando la rama actual Advertencia: Actualizar la rama actualmente desprotegida puede causar confusión. Advertencia: ya que el índice y el árbol de trabajo no reflejan los cambios que hay en HEAD. Advertencia: como resultado, es posible que veas los cambios que acabas de introducir. Advertencia: se revierte cuando ejecuta 'git diff' allí, y es posible que desee Advertencia: ejecutar 'git reset --hard' antes de comenzar a trabajar para la recuperación. advertencia: Advertencia: puede establecer la variable de configuración 'receive.denyCurrentBranch' en Advertencia: 'rechazar' en el repositorio remoto prohibir la inserción en su Advertencia: rama actual. Advertencia: para permitir la inserción en la rama actual, puede configurarla para 'ignorar'; Advertencia: pero esto no se recomienda a menos que haya acordado actualizar su trabajo. Advertencia: árbol para que coincida con lo que empujaste de alguna otra manera. advertencia: Advertencia: Para silenciar este mensaje, puede configurarlo en "advertir". advertencia: Advertencia: tenga en cuenta que el valor predeterminado cambiará en una versión futura de git Advertencia: rechazar la actualización de la rama actual a menos que tenga la Advertencia: variable de configuración establecida en 'ignorar' o 'advertir'.
Con Git 2.3.0 (después de febrero de 2015)
Si nadie está trabajando en ese repositorio remoto no básico, entonces debería ser posible enviarlo a una rama desprotegida.
Pero para estar más seguro en esa operación, ahora puedes (con Git 2.3.0, febrero de 2015), hacer en ese repositorio remoto:
git config receive.denyCurrentBranch updateInstead
Es más seguro que la configuración receive.denyCurrentBranch=ignore: permitirá el envío solo si no está anulando la modificación en curso.
Ver el compromiso 1404bcb de Johannes Schindelin ( dscho) :
receive-pack: agregue otra opción parareceive.denyCurrentBranchAl sincronizar entre directorios de trabajo, puede resultar útil actualizar la rama actual a través de '
push' en lugar de 'pull', por ejemplo, cuando se envía una corrección desde dentro de una máquina virtual o cuando se envía una corrección realizada en la máquina de un usuario (donde el desarrollador no está en libertad para instalar un demonio ssh y mucho menos saber la contraseña del usuario).La solución común (insertar en una rama temporal y luego fusionarla en la otra máquina) ya no es necesaria con este parche.
La nueva opción es:
updateInsteadActualice el árbol de trabajo en consecuencia, pero rechace hacerlo si hay cambios no confirmados.
El compromiso 4d7a5ce agrega más pruebas y menciona:
El anterior prueba solo el caso en el que una ruta que se actualizará mediante push-to-implementar tiene un cambio incompatible en el árbol de trabajo del objetivo que ya se ha agregado al índice, pero la característica en sí quiere requerir que el árbol de trabajo sea Mucho más limpio que lo que se prueba.
Agregue algunas pruebas más para proteger la función de cambios futuros que por error (desde el punto de vista del inventor de la función) aflojen el requisito de limpieza, a saber:
- Un cambio sólo en el árbol de trabajo pero no en el índice sigue siendo un cambio que debe protegerse;
- Es necesario proteger un archivo sin seguimiento en el árbol de trabajo que se sobrescribiría mediante un envío de implementación;
- Un cambio que hace que un archivo sea idéntico al que se está enviando sigue siendo un cambio que debe protegerse (es decir, el requisito de limpieza de la función es más estricto que el de pago).
Además, pruebe que un cambio de solo estadísticas en el árbol de trabajo no sea un motivo para rechazar una implementación push-to-deploy.
Con Git < 2.3.0 (antes de febrero de 2015)
El enfoque más común es crear un repositorio simple a partir del repositorio no simple y hacer que los repositorios git remotos/locales no simples apunten al repositorio simple recién creado.
En realidad, significa más o menos exactamente lo que dice: alguien está trabajando en el repositorio al que estás enviando, y que alguien actualmente ha verificado exactamente la misma rama a la que estás enviando.
Esto es muy confuso, porque ahora piensan que han verificado la última versión de la rama, cuando, en realidad, acaba de actualizar la rama a una versión más nueva. Entonces, cuando ahora se ejecuten git commit, su confirmación esencialmente revertirá todas las confirmaciones que acaba de presionar. Y cuando corran git diffverán lo contrario de todo lo que acabas de presionar, aunque tal vez ni siquiera hayan cambiado nada.
Por esa razón, generalmente se considera una mala práctica enviar a un repositorio no básico; sólo deberías enviar a repositorios vacíos, es decir, repositorios que no tienen una copia de trabajo adjunta. Como mínimo, debe asegurarse de no ingresar a la rama actualmente desprotegida, pero en general no debe simplemente ingresar su código en el repositorio de otra persona, sino que debe pedirle que lo extraiga de usted.
En algunos casos especiales, como cuando está sirviendo un sitio web desde un repositorio Git y desea actualizar el sitio web enviándolo a él, en realidad tiene sentido enviarlo a la rama actualmente desprotegida, pero en ese caso debe asegurarse que tiene un gancho instalado que realmente actualiza la copia de trabajo extraída; de lo contrario, su sitio web nunca se actualizará.
Este es el mismo problema que esta pregunta , la solución es usar git init --bareo git clone --bare.
