简体   繁体   中英

How can I know in git if a branch has been already rebased onto master?

This is very similar to How can I know in git if a branch has been already merged into master? but is about checking for rebased code. In the repository I am currently working on it seems that a few feature branches have been left hanging aground after their changes were rebased onto master. What is the best way for me to check that this has been done before I delete the branch?

Most of the suggestions on that branch suggest using the SHA id key of the last change on a branch to check for its presence in master. I can see that is the best way to be sure for merging but when you rebase this SHA is changed.

I have an answer that I will post too but I would like to know if people think there are better options.

In a case where the rebases are faithful to the original commit message @TafT's answer will work well. In addition, using

git log --oneline --cherry master...some-branch

will show = by every commit that has been copied exactly the same from some-branch to master.

If squashing and the like is taking place, commit messages are changed, or if your rebasing had conflicts neither solution will work. In this case I suggest the following (Checkout to detached HEAD so that we do not accidentally push this merge):

git checkout master~0
git merge some-branch

Unless your code has changed drastically, if the merge results in no change, then the branch has been rebased already. Otherwise, it obviously has not.

Searching by the last commit message of the feature branch within the master branch's log works quite well.

On the master branch do:

 git log -i --grep="<summary>"

Where is a segment of the comment from the last commit in your feature branch. This presents you with the commit SHA for the master branch copy, the Author and Date of the commit; the last two of which are preserved by a rebase. If your Author, Date and Comments are similar then you can be confident that the change was rebased onto the branch who's log you are inspecting.

This will not work if the rebase was used to squash all the feature branch commits into a single commit on master.

There are possibly other issues with this method, please do post them in the comments or suggest better answers where you can.

You can also rebase the feature branch onto the master branch. If it was already rebased, the feature branch will not have any more commits in front of master after the rebase, but point to the same commit as master. If the feature branch has master as upstream ( git branch --set-upstream-to=master ), you can then safely delete the branch with git branch -d feature-branch and git will make sure that there are no dangling commits.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM