Menu
My team uses github and sourcetree to manage our workflow. We've recently started trying out github's squash merge feature. We really like how it keeps our work history tidy, and essentially has a single commit per PR.
One of the unexpected downsides of using squash commits is that it's difficult to tell when a local branch can be deleted. My entire team seems to manage their local branches based on being able to visually see in the commit graph that it's been merged, and every few days we'll go through our local branches one by one seeing if they've been merged, and then remove it locally if it has. Enabling squash merging removes this visualization and makes it difficult for us to tell if the branch has been merged.
We'd really like to use the squash commit feature, but we need a reliable way to determine if a branch has been merged and is safe to be deleted locally. Are there any good ways that we haven't thought of to achieve this?
864
You can use the git merge-base command to find the latest common commit between the two branches. If that commit is the same as your branch head, then the branch has been completely merged.
The short answer is that there's no general yet reliable way to tell. The contents—as in, the associated snapshot—of commit IJK exactly match the contents (snapshot) of your commit K , and the log message of commit IJK is something that tells you that they squash-merged feature/yours .
A squash merge is a merge option in Git that will produce a merge commit with only one parent. The files are merged exactly as they would be in a normal merge, but the commit metadata is changed to show only one of the parent commits.
Squash merges, as it's proponents argue, are more valuable than merge commits because entire new features or bug fixes can be compressed into a single commit and therefore easier to code review and read at some point in the future.
My entire team seems to manage their local branches based on being able to visually see in the commit graph that it's been merged,
This seems to be the actual problem right here. If you're already using a GitHub pull-request workflow, the status of the pull request should be the authoritative answer to this question. Has the PR been accepted? Good! Branch is merged, move on with your life.
One option you may want to consider is adopting (and possibly enforcing) a workflow in which you only accept single-commit pull requests. Let people do whatever the heck they want in their local repositories, but when submitting a pull request they squash the appropriate commits together before submitting (and make liberal use of a rebase workflow locally to update the pull request if they need to make changes).
This has the advantage that the "visual inspection" method will continue to work, since you will no longer be synthesizing commits on GitHub.
Update
I've put together a small tool that uses the GitHub API to determine if pull requests associated with a given commit sha have been closed. Drop the git-is-merged script into your $PATH somewhere, and then you can do this:
$ git checkout my-feature-branch
$ git is-merged
All pull requests for 219e0f04a44053633abc947ce2b9d700156de978 are closed.
Or:
$ git is-merged my-feature-branch
All pull requests for 219e0f04a44053633abc947ce2b9d700156de978 are closed.
The script returns status text and exit codes for:
For squashed commits, you can use any of the commit shas that were part of the original pull request or the commit sha of the squashed commit.
As written this tool will only work with public repositories, but it's using the PyGithub module which does support authentication.
102
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
