It DOES NOT remove local branches which no longer track a remote. This git command actually removes local references to remote branches.
It’s often thought that git prune remote origin deletes all the local branches which no longer track a remote branch. Git prune remote origin – what does it do? It’s often considered that git prune is the answer, but it isn’t. You can see that there are 3 remote branches but there are 6 remote branches – and we want to delete the 3 local branches which no longer track a remote branch. Mouse over one of the merge commits: You'll see that it's called "Merge branch 'X' into Y", so you can see what the branch was named even if the black label is gone.This image shows the comparison between our local branches, shown in the Git bash window, and the remote branches, shown in the Github UI. Either way, the branch's commit history is preserved no story is lost. If you delete the branch, the black label disappears. If you don't delete the branch after merging, then the black label remains on the commit before the merge point. When you are "on a branch" and you make a commit, you add a dot to the commit history chain and move the relevant black label to your new dot.ĭiagonal arrows show where a branch is merged into another. "Creating a branch" means attaching a black label to a commit of your choice. "Deleting a branch" means removing a black label. The black-background labels are the "pointers" that represent active branches. The dots on the horizontal lines represent individual commits. The horizontal lines show the histories of parallel branches.
GIT REMOVE LOCAL BRANCH CODE
If the branch on the remote is deleted then I lose a bit of the story of how the code got to that state don't I?Īs said, no story is lost when deleting a branch because only the pointer/reference to a commit is deleted, not the data itself. I want to see the branches when I look in the past. There is a page which describes the general GitHub workflow: Understanding the GitHub flow
GIT REMOVE LOCAL BRANCH UPDATE
Notice also that this doesn't affect your local clone (you have to delete the branch manually). You can now update your fork on GitHub, pull from your fork, and finally delete the local branch (Git will warn you about deleting branches that have not been merged into master). Notice that the master branch on your fork is now behind master of the original project (because your branch got merged). Once merged, you can delete the branch from your fork, because the changes are now part of master in the original project (there is no reason to keep it). Then you can go to GitHub and open a pull request to ask the maintainer(s) of the original project to merge your changes (because you don't have write-access). When you add a branch, you can push it to your fork (because you have write-access). When you clone the fork, the fork becomes remote to your clone. On GitHub, when you fork a project, the original project becomes remote to your fork (you could even fork a fork if you wanted to.). Likewise, you can have as many branches of your own without having to push them to the remote (sometimes you can't because they are read-only). Git allows you to pull other branches if you want, but that is not mandatory. You'll notice that the clone - by default - only includes the master branch. You can even have multiple remote repositories if you wanted to. In Git, any repository can be remote. When you clone a Git repository, the source becomes remote to the clone. It doesn't matter if the remote is on your computer or on another server. This can indeed be confusing if you are used to centralized VCSs.
I still am not sure I 100% understand the concept of local and remotes having totally different branches either!
0 kommentar(er)
