git force checkout de una twig duplicada?

Si quiero crear una nueva twig, lo haría:

git checkout -b new-branch 

Sin embargo, a veces esta twig ya existe, por ejemplo:

 fatal: A branch named 'new-branch' already exists. 

¿hay alguna manera más fácil que hacer lo siguiente?

 git branch -D new-branch git checkout -b new-branch 

Intenté esto pero no funciona:

 git checkout -b new-branch --force 

Lo que quieres aquí es git checkout -B name . Si el name no nombra una twig existente, crea la nueva twig, apuntando a la confirmación actual, como si fuera una git checkout -b normal git checkout -b .

Si name nombra una twig existente, lo que ocurre en su lugar es que Git networkingirige a la fuerza el nombre de la twig a la confirmación actual. Esto es muy parecido a un git reset --soft . Un nombre de sucursal es realmente solo un nombre legible por humanos para alguna ID de hash Git, y un reinicio suave cambia la ID de hash adjunta al nombre de la twig, sin tocar el índice o tree de trabajo. De la misma manera, git checkout -B cambiará la ID adjunta a este nombre, sin tocar el índice o tree de trabajo.

(La respuesta principal termina aquí, el rest es solo un lado en todos los diferentes modos de éxito vs fracaso).

Hay una gran diferencia entre -B y --force

Hay un par importante de distinciones para hacer aquí.

La forma general de este tipo particular de pago es:

git checkout [-b | -B] name [ target-commit-specifier ]

como, por ejemplo, git checkout -b newbr a234567 .

La diferencia entre -b y -B en este punto es obvia: si la parte del name nombra una twig que ya existe, git checkout -b falla inmediatamente. Git no tiene que probar el pago: el nombre existe; error. Si el nombre no existe, o -B , hay más para probar.

Si omites el objective-especificador, como lo estamos haciendo arriba y en la pregunta original, toda una class de problemas desaparece. Este formulario, sin un compromiso de destino, significa: Deje el compromiso actual en su lugar. No toque el índice o tree de trabajo en absoluto. No hacer nada es fácil y nunca falla, así que esta parte nunca falla.

Sin embargo, cuando usas el git checkout -B name target-commit-specifier formulario git checkout -B name target-commit-specifier , el command intenta a234567 commit del objective a234567 . Este paso requiere actualizar el índice y / o el tree de trabajo, y esto puede fallar con, por ejemplo:

 error: The following ... files would be overwritten ... 

En este caso, se git checkout -b o git checkout -B y no se crea ni se restablece ninguna bifurcación. (Consulte también Buscar otra twig cuando hay cambios no confirmados en la twig actual .)

La opción --force le dice a Git que si este paso de la compra está a punto de fallar, Git debería seguir adelante y hacer el pago de todas forms, sobrescribiendo o eliminando files que no se guardan de manera segura en el repository. Esto puede hacer todo tipo de cambios en el índice y / o en el tree de trabajo, y cualquier file de datos que no se guarde permanentemente y de forma segura en una confirmación podría perderse aquí. Entonces, la --force sigue siendo peligrosa (en la medida en que puede perder datos de file), pero no está relacionada con -b vs -B : solo afecta este paso, al pasar de su compromiso actual, sea lo que sea, a este otro compromiso de destino.

Si Git llega tan lejos, la confirmación del objective ahora está instalada como la confirmación actual, con el índice y el tree de trabajo modificados; o el compromiso objective es el compromiso actual, por lo que el índice y el tree de trabajo se dejan en paz; en este punto, todo está destinado a tener éxito. Ya hemos comprobado si el nombre de la twig existe para -b . Todo lo que Git tiene que hacer ahora es escribir la identificación hash de la confirmación actual en el nombre de la sucursal (para que el name apunte a a234567 , por ejemplo) y escribir ref: refs/heads/ name en .git/HEAD , para que esté ahora en el name twig.