Git delete branch after merging Pull Request

[Neil Pate]

So I am pretty new to GitHub and pull requests (I still am not sure I 100% understand the concept of local and remotes having totally different branches either!)

But what is this all about? I have done a bit of digging and it seems the current best practice is indeed to delete the branch when it is no longer needed. This is also a totally strange concept to me. I presume the branch they are talking about here is the remote branch?

 

Confused...

 

[LogMAN]

2 hours ago, Neil Pate said:

But what is this all about? I have done a bit of digging and it seems the current best practice is indeed to delete the branch when it is no longer needed. This is also a totally strange concept to me. I presume the branch they are talking about here is the remote branch?

You got it right. "Delete branch" will delete the branch on your fork. It does not affect the clone on your computer. The idea is that every pull request has its own branch, which, once merged into master, can safely be deleted.

2 hours ago, Neil Pate said:

I still am not sure I 100% understand the concept of local and remotes having totally different branches either!

This can indeed be confusing if you are used to centralized VCSs.

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. You can even have multiple remote repositories if you wanted to.

You'll notice that the clone - by default - only includes the master branch. Git allows you to pull other branches if you want, but that is not mandatory. 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).

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...). When you clone the fork, the fork becomes remote to your clone. When you add a branch, you can push it to your fork (because you have write-access). 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). 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).

Notice that the master branch on your fork is now behind master of the original project (because your branch got merged). 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).

There is a page which describes the general GitHub workflow: Understanding the GitHub flow · GitHub Guides

Hope that helps.

Edited January 18, 2021 by LogMAN
typos

[pawhan11]

Great book about git in general:

https://git-scm.com/book/en/v2

[Neil Pate]

23 hours ago, LogMAN said:

You got it right. "Delete branch" will delete the branch on your fork. It does not affect the clone on your computer. The idea is that every pull request has its own branch, which, once merged into master, can safely be deleted.

This can indeed be confusing if you are used to centralized VCSs.

I still don't really get this. I want to see the branches when I look in the past. 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?

[pawhan11]

Started transition from svn to git recently and I might be not 100% accurate there. Branch for git means just an link to a commit.

When branch is merged and later deleted no history will be lost, all commits from deleted branch will remain as they were.

If You delete branch that was not merged then commits in that branch will not be 'reachable' and eventually be garbage collected - never seen that one yet. 

[JKSH]

4 hours ago, Neil Pate said:

I still don't really get this. I want to see the branches when I look in the past. 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?

As @pawhan11 said, no story is lost when deleting a branch because only the pointer/reference to a commit is deleted, not the data itself.

See here for a visual example: https://github.com/ni/niveristand-fpga-addon-custom-device/network

• The horizontal lines show the histories of parallel branches.
• The dots on the horizontal lines represent individual commits.
• The black-background labels are the "pointers" that represent active branches.
  • "Deleting a branch" means removing a black label.
  • "Creating a branch" means attaching a black label to a commit of your choice.
  • 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.
• Diagonal arrows show where a branch is merged into another.
  • If you don't delete the branch after merging, then the black label remains on the commit before the merge point. If you delete the branch, the black label disappears. Either way, the branch's commit history is preserved; no story is lost.
  • 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.

Note: "master"/"main" is just another branch; there is no separate "trunk"

Edited January 20, 2021 by JKSH

[ned]

3 hours ago, Neil Pate said:

I still don't really get this. I want to see the branches when I look in the past. 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?

 

1 hour ago, pawhan11 said:

Branch for git means just an link to a commit.

This is exactly right. A branch points at a commit, and the commit to which it points changes as additional commits are added to the branch. You can reset a branch to point at any arbitrary commit, even one in what you might think of as a different branch, because again, it's just a reference to a commit. Deleting a branch removes the reference with no impact on the sequence of commits.

In case you want to make things more complicated, git supports an alternate mechanism to merging branches, where code is "rebased" rather than "merged" so the eventual history looks like a single continuous line rather than a tree.

[LogMAN]

13 hours ago, Neil Pate said:

I still don't really get this. I want to see the branches when I look in the past. 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?

The Network Graph mentioned by @JKSH does give you some visualization on GitHub. I personally prefer the visualization in Sourcetree and bash.

Here is an example for GitHub - microsoft/vscode: Visual Studio Code

The command I use is

git log --oneline --graph

You can see that branches still exist even after merging. Only the name of the branch, which is just a fast way to address a specific commit hash, is lost (although it is typically mentioned in the commit message).

That said, some branches can be merged without an explicit merge commit. This is called "fast-forward" - https://stackoverflow.com/a/29673993. Maintainers on GitHub can decide if they always want a merge commit, or not.

[Neil Pate]

OK, so deleting the branch on the remote only deletes it from being used in future, it still exists in the past and can be visualised? Sorry I misunderstood and thought that git did magic to actually remove the branch in the past (which would be a bad thing). I know about rebase but have never thought to use it.

[Neil Pate]

Tangentially, I use Plastic SCM at work (Unity/C# dev), it really hits the sweet spot of easy to use but powerful DVCS. I believe it is modelled on Git but designed to trivially handle many branches.

[LogMAN]

4 hours ago, Neil Pate said:

OK, so deleting the branch on the remote only deletes it from being used in future, it still exists in the past and can be visualised?

Only the name is deleted, commits are left untouched. It is actually possible to restore the branch name if you know the commit hash - https://stackoverflow.com/a/2816728

This can be useful if you deleted a branch before it was merged into master, or if you want to branch off a specific commit in the history that is currently unlabeled.

Here is some documentation from Atlassian, generally applicable to GitHub as well:

• Git Branch | Atlassian Git Tutorial
• Pull Requests | Atlassian Git Tutorial