In our GitHub repository, a coworker removed a branch named release. But when I run git checkout release locally, I always get the removed branch release. Same, even when I checked out another branch, deleted the release branch with git branch -D release and ran again git checkout release.
Is there something to fix on the GitHub repository, or shall I fix something locally?
After deleting a branch on the remote side you may still see this formerly fetched remote branch locally, see:
$ git branch -a
[...]
release
remotes/origin/release
[...]
You only removed the "release" but not "remotes/origin/release". Delete it like this:
$ git branch -rd origin/release
Or remove all fetched branches which do not exist on the remote side anymore:
$ git remote prune origin
git branch -rd origin/release, what does -r mean? Does -d mean the same as -D? Can git branch -rd origin/release be replaced with git branch -d remotes/origin/release?
– Tim
May 18 '17 at 19:23
List or delete (if used with -d) the remote-tracking branches.; -D: Shortcut for --delete --force.
– looper
May 18 '17 at 20:00
git branch -rd origin/release be replaced with git branch -d remotes/origin/release?
– Tim
May 18 '17 at 20:06
-r refers to remote branches, it's needed. The local and remote branches are stored in different directories, compare ls -l .git/refs/heads and ls -l .git/refs/remotes. You could also have a local branch called remotes/origin/release which would be delete without -r. This might sound confusing but you could just play around, create branches with strange names and look how does it look in .git/.
– rudimeier
May 18 '17 at 21:15
When branches are deleted remotely, you need to prune your local repository — the easiest way to do this is with
git fetch -p
This will update your local repository with all the changes made to the remote repository, but without updating any of your local branches. After running this,
git branch --remote
will no longer show the deleted remote branch.
git repositories are complete, whether on your own system or on the server. So when you first clone a repository, you get a complete copy, and your local git “knows” about all the remote branches as well as your local branches. This information isn’t synced automatically, so when your colleague deleted the release branch on the server, your local git repository didn’t lose its notion of a remote release branch. Syncing with git fetch updates all the local information on remote branches so they match the state on the server (strictly speaking, remote repository, wherever that is), but without deleting any local information on remote branches. Pruning with git fetch -p (or git fetch --prune, or git remote prune) removes the local information on remote branches which have been deleted.
-p (--prune) forces that.
– Stephen Kitt
May 18 '17 at 15:31
release branch by git branch -D release before git checkout release make git checkout release stop getting the release branch?
– Tim
May 18 '17 at 17:05
git checkout release will automatically re-create a branch if there is a remote branch with that name.
– Stephen Kitt
May 18 '17 at 17:07
git branch -D release has already deleted the release branch in my local repository; If latter, a coworker has deleted the release branch on GitHub; So i am still not sure why "will automatically re-create a branch if there is a remote branch with that name"?
– Tim
May 18 '17 at 17:10
git branch -D release updates the local branches, your colleague updated the branches in the remote repository, but the middle set stayed the same (and still had release).
– Stephen Kitt
May 18 '17 at 17:12
git branch -D release already delete the release branch in my local repository, so there is no remote branch with that name release in my local repository, so git checkout release willnote automatically re-create a branch release? (2) Since both GitHub and my local rep already don't have a branch named release,from where can git checkout release recreate a branch release ?
– Tim
May 18 '17 at 17:17
git branch -D release deleted your local branch, it didn’t delete the remote branch that git knows about in your local repository. There is a remote branch with that name in your local repository. There are three sets of branches, you only updated two of them.
– Stephen Kitt
May 18 '17 at 17:18
Tim: Git is distributed VCS, so when you clone a repo from remote to your local it clones everything (history).
So when you cloned your repo, it had a branch called release. Since your colleague deleted release branch remotely, till you do a prune git fetch -p or delete that branch explicitly your local will have that branch.
Perhaps a bit tangential but the perspective of this site might help to understand the general topic of deleting branches:
There is overlap with some of what's already been discussed here but the focus is on housekeeping: deleting branches, remote and local, that are no longer needed in a collaborative environment. In particular the git branch --merged command identifies branches that are safe to delete due to being merged to your mainline (or whatever branch you care about). If you're collaborating, some fancier mini scripts like this one will present things in a nice, digestible format with dates and authors.
for branch in `comm -12 <(git branch --merged|awk '{print($1)}') <(git branch -r --merged|awk '{print($1)}'|awk -F \/ '{print($2)}')`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r
(Unfortunately "nice, digestible" doesn't apply to the formatting of the scripts themselves.)
git branch --remoteoutput, after runninggit fetch? You might need to prune withgit fetch -pto forget deleted remote branches. – Stephen Kitt May 18 '17 at 14:33git branch --remoteoutputorigin/release. Do you mean to rungit fetch -pwithout additional arguments, and will it prune all the deleted remote branches? – Tim May 18 '17 at 14:54git fetch -pwith no additional arguments will prune all the deleted remote branches. – Stephen Kitt May 18 '17 at 15:07git fetch -pandgit push origin :releasein rudimeier's reply both forget deleted remote branches, except the former prune all and the latter prune the specified branch? – Tim May 18 '17 at 15:11git push origin :releasewould do what your coworker probably already did.git fetch -pis similar togit remote prune originin my answer. – rudimeier May 18 '17 at 15:20git push origin :releasedelete thereleasebranch on GitHub, which I mentioned my coworker already deleted? Dogit fetch -pandgit remote prune originclean up the tracking info within my local repository forreleasebranch? – Tim May 18 '17 at 15:26git push origin :releasedeletes the remote branch. It’s not really a good idea in this case, since (a) your colleague has already done that (possibly via the GitHub UI), and (b) if anyone else adds a new branch with the same name on the server, you’ll delete that new branch... – Stephen Kitt May 18 '17 at 15:27