Deleting a branch after a squash and merge on GitHub also deletes its commits #21689
-
Hi, I’ve accepted a pull request on GitHub through a squash and merge of the feature branch into the master branch: v master v master A -> A - - - - - - - E ^ feature ^ feature I then deleted the feature branch by clicking on the button that says so in the pull request, and was surprised to find out from the repository’s graph that the branch’s commits, not just the branch’s name, had been deleted. The repository’s graph, in Insights > Network on GitHub, now looks like that: v master A - E A branch, in Git, is a pointer to a commit, or so I’ve read countless times. I expected, and kinda wanted, to only delete this pointer, the branch’s name, leaving out the commits: v master A - - - - - - - E `- B - C - D Unreacheable commits, granted, but still present, and accessible through their hash. Is this behavior a bug or a feature of GitHub? If it is a feature, where else should I be cautious that the term “branch” is used to mean “the branch’s commits”? Or am I simply wrong in my understanding of what a branch means in Git? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
What history view do you mean by “My history”? Anyway, I think this is intended behaviour. By squashing you push all commits of that branch into a single commit, then apply that commit to the master branch. I also believe that with “Delete this branch” GitHub does mean “Delete this branch’s commits”. Actually, I’ve never considered a branch as just a pointer to a commit, but that might as well be true (I am not a Git wizard 😉 ).
I would be cautious everywhere about that! Again, at least from my experience, a “branch” mostly never is considered as a pointer but more as a “collection” of commits that originate from a certain point in another branch. Altough, again, that thought may be misplaced, I’d definitely be aware of the differing opinions about what a branch is. |
Beta Was this translation helpful? Give feedback.
-
I meant my repository’s network graph, shown in the Insights tab of the repository on GitHub. I’ve edited my post to clarify.
It appears so indeed. That is not the case on GitLab, which I was using previously. In my experience of GitLab, deleting a branch through the web interface deletes the branch in the Git sense, that is to say the branch pointer, not the commits.
Yes I’m pretty sure that is the case. I’ve read it countless times, and that seems to match how Git behaves: git branch -d branchname, for instance, simply deletes the branch pointer branchname which points to the commit at the tip of the branch, but that commit and its ancestors are still present in the repository, and accessible through their hash, e.g. git log hash-of-tip-commit.
I’ve just accepted a pull request, through the rebase and merge strategy this time. Then I clicked on “Delete this branch”, and found out that in this case too, the branch’s commits, not just the branch’s name, where deleted from the repository, according to the repository’s graph. So I will heed your advice! |
Beta Was this translation helpful? Give feedback.
What history view do you mean by “My history”?
Anyway, I think this is intended behaviour. By squashing you push all commits of that branch into a single commit, then apply that commit to the master branch. I also believe that with “Delete this branch” GitHub does mean “Delete this branch’s commits”. Actually, I’ve never considered a branch as just a pointer to a commit, but that might as well be true (I am not a Git wizard 😉 ).
I would be cautious everywhere about that! Again, at least from my experience, a “branch” mostly never is considered as a pointer but m…