Mueva el puntero de la rama a una confirmación diferente sin pagar

10 minutos de lectura

Mueva el puntero de la rama a una confirmacion diferente
Agudeza

Para mover el puntero de rama de una rama desprotegida, se puede usar el git reset --hard mando. Pero, ¿cómo mover el puntero de la rama de una rama no verificada para que apunte a una confirmación diferente (manteniendo todas las demás cosas como la rama remota rastreada)?

  • Parece que todo lo que quería hacer es una rama de una confirmación diferente a la que se creó a partir de ahora. Si mi comprensión es correcta, ¿por qué no simplemente crea una nueva rama desde el compromiso que desea crear usando git branch <branch-name> <SHA-1-of-the-commit> y volcar la rama vieja?

    – yasouser

    29 de marzo de 2011 a las 20:31

  • @yasouser: no estoy seguro de que la rama “maestra” de volcado sea una buena idea.

    – Bulwersator

    24 de marzo de 2013 a las 11:49

1646761152 576 Mueva el puntero de la rama a una confirmacion diferente
chris johnsen

git branch --force <branch-name> [<new-tip-commit>]

Si new-tip-commit se omite, por defecto es la confirmación actual.

new-tip-commit puede ser un nombre de rama (por ejemplo, maestro, origen/maestro).

  • O para referencias arbitrarias, git update-ref -m "reset: Reset <branch> to <new commit>" <branch> <commit>. (Puede criticar el mensaje de reflog si lo desea; creo que el branch -f uno es diferente del reset --hard uno, y este no es exactamente ninguno de ellos).

    – Cascabel

    29 de marzo de 2011 a las 14:18

  • Jefromi, escriba una respuesta separada para que pueda obtener votos. 🙂

    – Motor

    29 de marzo de 2011 a las 17:09

  • Esta es una mejor respuesta ya que maneja el caso del 99% y en realidad se ajusta a la documentación. git help branch dice “-f, –force Restablecer a si ya existe. Sin -f, git branch se niega a cambiar una rama existente”.

    – AlexChaffee

    5 de diciembre de 2012 a las 18:22

  • estoy haciendo git branch -f master <hash> y me esta diciendo fatal: Cannot force update the current branch. Ummmm, ¿qué tengo que hacer ahora, revisar alguna otra rama aleatoria antes de que se me permita usar este comando?

    – Qwertie

    10 de agosto de 2014 a las 22:52

  • Esto no funcionará si la rama que intenta mover es su rama actual (HEAD lo señala).

    – Vladimir Panteleev

    30 de abril de 2015 a las 1:02

Puedes hacerlo para referencias arbitrarias. Así es como mover un puntero de rama:

git update-ref -m "reset: Reset <branch> to <new commit>" refs/heads/<branch> <commit>

donde -m agrega un mensaje al reflog para la rama.

La forma general es

git update-ref -m "reset: Reset <branch> to <new commit>" <ref> <commit>

Puede criticar el mensaje de reflog si lo desea; creo que el branch -f uno es diferente del reset --hard uno, y este no es exactamente ninguno de ellos.

  • ¿Para dónde es bueno el mensaje? ¿Dónde se almacena y cómo leerlo más tarde?

    – Motor

    21 de marzo de 2012 a las 12:05

  • NOTA: Esto no funciona en repositorios desnudos. En los repositorios básicos, debe usar ‘git branch -f master ‘ para actualizar la rama (consulte la respuesta a continuación).

    – Junio ​​Rodas

    30 de septiembre de 2012 a las 10:13

  • Si, como yo, accidentalmente usa en lugar de refs/heads/, terminará con un nuevo archivo en su directorio .git en .git/, y recibirá mensajes como “refname ‘master’ es ambiguo” cuando intenta trabajar con él. Puede eliminar el archivo de su directorio .git para corregirlo.

    – David Menor

    6 de junio de 2013 a las 18:02

  • No se ha explicado a satisfacción por qué esto es mejor que git branch -f. Para ser específicos, este método parece ser: (A) más difícil de usar (B) más difícil de recordar y (C) más peligroso

    – Steven Lu

    18 de febrero de 2015 a las 10:17

  • “qué se entiende exactamente por referencias arbitrarias”: las ramas no son el único tipo de referencia que apunta a una confirmación. Hay etiquetas, y también puede crear referencias arbitrarias de estilo refs/whatevs/myref que no son ramas ni etiquetas. Creo que eso también responde a la pregunta de Steven Lu sobre qué podría ser “mejor”. Estoy de acuerdo branch -f es más simple si está trabajando con sucursales.

    – Adán A.

    02/04/2015 a las 12:25

también puedes pasar git reset --hard una referencia de confirmación.

Por ejemplo:

git checkout branch-name
git reset --hard new-tip-commit

Encuentro que hago algo como esto con poca frecuencia:

Asumiendo esta historia

$ git log --decorate --oneline --graph
* 3daed46 (HEAD, master) New thing I shouldn't have committed to master
* a0d9687 This is the commit that I actually want to be master

# Backup my latest commit to a wip branch
$ git branch wip_doing_stuff

# Ditch that commit on this branch
$ git reset --hard HEAD^

# Now my changes are in a new branch
$ git log --decorate --oneline --graph
* 3daed46 (wip_doing_stuff) New thing I shouldn't have committed to master
* a0d9687 (HEAD, master) This is the commit that I actually want to be master

  • Esto está bien si su árbol de trabajo está limpio. Si tiene muchos cambios preparados o sin preparar, probablemente sea mejor hacerlo git update-ref como se discutió anteriormente.

    – un nerd pagado

    8 de abril de 2014 a las 4:35

  • ¿Notó que su “respuesta” no agrega nada que ya no sea parte de la pregunta? – OP dijo: si está desprotegido… puedes usar git reset --hard ... ¡No es necesario repetirlo aquí! 🙁

    – Roberto Siemer

    20 de abril de 2015 a las 11:11

  • @Robert: No estoy de acuerdo. la pregunta no dijo cómo para usarlo y esto lo hace. Fue agradable no tener que ir a buscar eso.

    – Wilson F.

    11/08/2015 a las 18:57

  • @WilsonF, tal vez fue bueno para usted encontrar esto aquí, pero no responde la pregunta en absoluto. Tal vez sea la respuesta de alguna otra pregunta, pero aquí está incorrecto.

    – Roberto Siemer

    12 de agosto de 2015 a las 7:52

  • Creo que esto debería haber sido un comentario sobre la pregunta, no una respuesta. (¿O tal vez estaba respondiendo una versión anterior de la pregunta?)

    –Keith Russell

    7 mayo 2020 a las 15:21

Solo para enriquecer la discusión, si quieres moverte myBranch ramifica a tu Actual commit, simplemente omita el segundo argumento después -f

Ejemplo:

git branch -f myBranch


Generalmente hago esto cuando rebase mientras está en un estado de cabeza separada 🙂

1646761153 246 Mueva el puntero de la rama a una confirmacion diferente
pedro cordes

En gitk --all:

  • haga clic derecho en el compromiso que desea
  • -> crear nueva sucursal
  • ingrese el nombre de una sucursal existente
  • presione regresar en el diálogo que confirma la sustitución de la antigua rama de ese nombre.

Tenga en cuenta que volver a crear en lugar de modificar la rama existente perderá la información de la sucursal de seguimiento. (Esto generalmente no es un problema para casos de uso simples donde solo hay un control remoto y su sucursal local tiene el mismo nombre que la sucursal correspondiente en el control remoto. Consulte los comentarios para obtener más detalles, gracias @mbdevpl por señalar este inconveniente).

Sería genial si gitk tenía una función en la que el cuadro de diálogo tenía 3 opciones: sobrescribir, modificar existente o cancelar.


Incluso si normalmente eres un adicto a la línea de comandos como yo, git gui y gitk están bastante bien diseñados para el subconjunto de uso de git que permiten. Recomiendo encarecidamente usarlos para lo que son buenos (es decir, organizar selectivamente fragmentos dentro/fuera del índice en git gui, y también simplemente confirmar. (ctrl-s para agregar una línea cerrada:, ctrl-enter para confirmar .)

gitk es excelente para realizar un seguimiento de algunas ramas mientras clasifica sus cambios en una buena serie de parches para enviar aguas arriba, o cualquier otra cosa en la que necesite realizar un seguimiento de lo que está en el medio con múltiples ramas.

Ni siquiera tengo abierto un explorador de archivos gráficos, pero me encanta gitk/git gui.

  • ¡Tan fácil! Es posible que acabo de convertir de gitg a gitk.

    –Michael Cole

    3 de junio de 2016 a las 19:58

  • De esta forma, sin embargo, se pierde la información de la sucursal de seguimiento.

    – mbdevpl

    14 de junio de 2017 a las 8:23

  • @mbdevpl: no soy realmente un experto en git. Creo que entiendo lo que quieres decir, pero no las implicaciones. Lo he usado con bastante frecuencia, y todavía he podido enviar esas ramas a ramas del mismo nombre en un control remoto. ¿Qué hace por usted la asociación entre una sucursal y su sucursal de seguimiento remoto?

    – Peter Cordes

    14 de junio de 2017 a las 16:41

  • @mbdevpl: ¿eso en su mayoría solo importa? cuando su sucursal local tiene un nombre diferente al de la sucursal remota que está rastreando?

    – Peter Cordes

    14/06/2017 a las 16:50

  • @PeterCordes Necesito, cuando los nombres de las sucursales no coinciden, importa. También cuando hay más de un mando a distancia. Además, cuando usa el indicador de git para mostrar el estado de la rama, mostrará la distancia de confirmación a su rama de seguimiento (si está configurada). También, git status la salida se ve afectada. Además, en algunos casos git fetch y git push no funcionará sin especificar remoto explícitamente si no configura la rama de seguimiento. No conozco todos los casos, pero para mí la regla general es que, por comodidad y rapidez de trabajo, es mejor tener las ramas de seguimiento en orden.

    – mbdevpl

    15 de junio de 2017 a las 10:53


1646761153 921 Mueva el puntero de la rama a una confirmacion diferente
Comunidad

La solución recomendada git branch -f branch-pointer-to-move new-pointer en TortoiseGit:

  • “Git Mostrar registro”
  • Marque “Todas las sucursales”
  • En la línea a la que desea que se mueva el puntero de bifurcación (puntero nuevo):
    • Haga clic derecho, “Crear sucursal en esta versión”
    • Al lado de “Sucursal”, ingrese el nombre de la sucursal a mover (branch-pointer-to-move)
    • En “Base On”, verifique que el nuevo puntero sea correcto
    • Marque “Fuerza”
    • OK

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

  • ¡Tan fácil! Es posible que acabo de convertir de gitg a gitk.

    –Michael Cole

    3 de junio de 2016 a las 19:58

  • De esta forma, sin embargo, se pierde la información de la sucursal de seguimiento.

    – mbdevpl

    14 de junio de 2017 a las 8:23

  • @mbdevpl: no soy realmente un experto en git. Creo que entiendo lo que quieres decir, pero no las implicaciones. Lo he usado con bastante frecuencia, y todavía he podido enviar esas ramas a ramas del mismo nombre en un control remoto. ¿Qué hace por usted la asociación entre una sucursal y su sucursal de seguimiento remoto?

    – Peter Cordes

    14 de junio de 2017 a las 16:41

  • @mbdevpl: ¿eso en su mayoría solo importa? cuando su sucursal local tiene un nombre diferente al de la sucursal remota que está rastreando?

    – Peter Cordes

    14/06/2017 a las 16:50

  • @PeterCordes Necesito, cuando los nombres de las sucursales no coinciden, importa. También cuando hay más de un mando a distancia. Además, cuando usa el indicador de git para mostrar el estado de la rama, mostrará la distancia de confirmación a su rama de seguimiento (si está configurada). También, git status la salida se ve afectada. Además, en algunos casos git fetch y git push no funcionará sin especificar remoto explícitamente si no configura la rama de seguimiento. No conozco todos los casos, pero para mí la regla general es que, por comodidad y rapidez de trabajo, es mejor tener las ramas de seguimiento en orden.

    – mbdevpl

    15 de junio de 2017 a las 10:53


1646761154 158 Mueva el puntero de la rama a una confirmacion diferente
Adrián

Honestamente, me sorprende cómo nadie pensó en el git push mando:

git push -f . <destination>:<branch>

El punto ( . ) hace referencia al repositorio local y es posible que necesite la opción -f porque el destino podría ser “detrás de su contraparte remota”.

Aunque este comando se usa para guardar sus cambios en su servidor, el resultado es exactamente el mismo que si moviera la rama remota (<branch>) a la misma confirmación que la rama local (<destination>)

  • También puede hacerlo sin -f para evitar golpear cualquier cosa local; por ejemplo, git fetch origin && git push . origin/develop:develop es una versión a prueba de fallas que no necesita pago de git checkout develop && git pull --ff-only

    – ciudad b

    8 de marzo de 2020 a las 19:59


¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad