Eliminé una sucursal en remoto, ¿cómo sincronizo en local?

Creé un repositorio en Github. Tengo dos entornos de desarrollo y accedo a Github con Github para Windows en ambos.

En uno de los dos entornos de desarrollo, eliminé una rama e hice clic en “sincronizar” en Github para Windows. La rama se eliminó apropiadamente en Github. Cuando sincronicé desde mi otro entorno de desarrollo, había una opción para “publicar” la rama que se eliminaría, pero ninguna para eliminarla.

¿Cómo puedo decirle a git o Github para Windows que realice una sincronización completa, incluida la eliminación de ramas obsoletas?

Sí y no, dependiendo de lo que realmente quiso decir con “eliminación de una sucursal local”.

una respuesta rapida

• No, es imposible que un repositorio remoto elimine una rama normal en su repositorio local.

• Sí, es posible pedirle a Git que elimine remoto sucursales en su repositorio local para las sucursales que se eliminaron en un determinado
  remoto con nombre (como “origen”).

  Este se logra ejecutando

    git remote prune origin
  

  o

    git fetch --prune
  

Explicaciones

Entienda primero que el modelo de Git para trabajar con repositorios remotos es asimétrico: el hecho de que una rama en su repositorio local tenga el nombre exactamente igual al de una rama en un repositorio remoto no tiene significado para Git.

La razón es doble:

• Git trata su repositorio local como completamente autónomo y no depende de ningún otro repositorio.
• Su repositorio local puede comunicarse con cualquier cantidad de repositorios remotos, y…
• …esos repositorios pueden no tener absolutamente ninguna relación “conceptual” con su repositorio local: por ejemplo, es posible obtener los datos de un repositorio que aloja el código fuente de Linux en un repositorio que contiene su proyecto de juguete de fin de semana.

En otras palabras, si, por ejemplo, tiene un repositorio privado alojado en Github y un clon local del mismo en su PC, eliminó una rama a través de la interfaz de usuario de Github y ahora quiere que esta rama desaparezca en su clon local, eso es de hecho comprensible ya que estos dos repositorios tienen una relación de 1 a 1. Ahora considere que tiene un repositorio que fue clonado por sus compañeros desarrolladores Gill, Joe y Alice, cada uno de ellos creó de manera simple una rama llamada “característica” para delevop diferente características, y luego ha obtenido de estos tres repositorios, terminando con tres sucursales remotas llamadas <remote>/featurecon ese <remote> el marcador de posición en cada caso es el nombre de un control remoto que le dio a estos tres repositorios de repositorios. Agregue a esto que puede tener su propia rama llamada “característica” que no tiene nada que ver con las ramas del mismo nombre de sus compañeros desarrolladores. Ahora considere que, digamos, Alice fusiona su rama de “característica” y luego se deshace de ella. ¿Significa esto que su propia rama “característica” también tiene que desaparecer automáticamente la próxima vez que obtenga del repositorio de Alice? Seguramente no.

Entonces, si bien Git tiene ciertos ayudantes para vincular de alguna manera las sucursales locales con sucursales remotas particulares, estos lazos son asimétricos. En particular, Git trata tu historial local como “sagrado”, y las operaciones destructivas requieren tus acciones explícitas.

Más información para frikis

La asimetría explicada anteriormente solo tiene lugar en repositorios Git “normales”, que se utilizan la mayor parte del tiempo. Cabe señalar que es posible crear un repositorio de Git que se comportará de manera diferente: por ejemplo, una llamada a git fetch origin en dicho repositorio se asegurará de que el estado de las ramas y etiquetas de <origin> se reflejará en el repositorio local, eliminando y creando cosas cuando sea necesario.