I deleted a branch in remote, how do I synchronize in local?

Question

I created a repository on Github. I have two development environments, and I access Github with Github for Windows on both.

On one of the two development environments, I deleted a branch and clicked "synchronize" in Github for Windows. The branch appropriately got deleted in Github. When I synchronized from my other development environment, there was an option to "publish" the branch-to-be-deleted, but none to delete it.

How can I tell git or Github for Windows to make a full sync, including the deletion of obsolete branches?

Viridian

I don't believe you can "sync" them (e.g. the equivalent of git fetch --prune) but you can manually delete each of the branches in GitHub for Windows. – Training

this is old but, if someone comes here, then also refer to this answer stackoverflow.com/a/17029936 – Histamine

Answer 1

Yes and no — depending on what you really meant by "deletion of a local branch".

A quick answer

• No, it's impossible to have a remote repository delete a normal branch in your local repository.

• Yes, it's possible to ask Git to delete so-called remote branches in your local repository for the branches which were deleted on a particular named remote (such as "origin").

  This one is achieved by running

    git remote prune origin
  

  or

    git fetch --prune
  

Explanations

Please do understand first that Git's model for working with remote repositories is asymmetric: the fact a branch in your local repository has the name exactly matching that of a branch in a remote repository has no meaning to Git.

The reason is two-fold:

• Your local repository is treated by Git as completely self-containing and not depending on any other repositories.
• Your local repository is able to communicate with any number of remote repositories, and…
• …those repositories may have absolutely no "conceptual" relation to your local repository: for instance it's possible to fetch the data from a repository hosting the Linux source code into a repository containing your weekend toy project. (In other words, Git repositories do not contain any sort of UUID which could be used to check whether two communicating repositories manage "logically the same" data.)

In other words, if you, say, have a private repository hosted on Github, and a local clone of it on your PC, you deleted a branch via the Github's UI and now want this branch to go away in your local clone, that's indeed understandable as these two repositories have 1-to-1 relation. Now consider that you have a repository which was cloned by your fellow developers Gill, Joe and Alice, each of them simplemindedly created a branch named "feature" to delevop different features, and you have then fetched from all these three repositories — ending up with a three remote branches named <remote>/feature, with that <remote> placeholder in each case being the name of a remote you gave to these three remote repositories. Add to this that you can have your own branch named "feature" which has nothing to do with the same-named branches of your fellow developers. Now consider that, say, Alice merges her "feature" branch and then gets rid of it — does this mean your own branch "feature" has to go away automatically as well next time you fetch from the Alice's repo? Surely not.

So while Git has certain helpers to somewhat tie local branches to particular remote branches, these ties are asymmetric. In particular, Git treats your local history as being "sacred", and destructive operations on it require your explicit actions.

Further info for geeks

The asymmetry explained above only takes place in "normal" Git repositories—which are used most of the time. It should be noted that it's possible to create a Git repository that will behave in a different manner: say, a call to git fetch origin in such a repository will make sure the state of the branches and tags of <origin> will be mirrored in the local repository—deleting and creating stuff when necessary.

Solingen