Is there any way to check what branches have been rebased against master

So I have a project with 44 branches, not critical, but not clean as well.

Hence my question, how to check what branches have been rebased against master. So I can go and delete branches one by one.

  • TeamCity The repository X has a submodule in the commit 'X' at a path 'X', but has no entry for this path in .gitmodules configuratio
  • GitLab: how can I tell what acess level I have on a project?
  • Tracking file permissions in Git. Error running git-cache-meta: “find: you have too many ')'”
  • How to merge between two local repositories
  • Git don't push a symfony bundle into Github
  • Openstack devstack installation stalls with git call failure
  • Latest version of Git in Bash?
  • Merge difference code changes from one repository branch to another repository branch
  • How to split every commit by file?
  • Git branching model for two target environments
  • Why do I need to modify <master> if I want to merge it into my public <feature1> branch according to Atlassian Stash?
  • Possible to merge wear and mobile Git repositories
  • One Solution collect form web for “Is there any way to check what branches have been rebased against master”

    I think perhaps you mean merged instead of rebased? Because if what you really want to check is that some branch are rebased against the latest of the master branch, then you just run gitk --all and you will clearly see all branches that are based on the latest commit on master. But then it does not make sense to delete those branches.

    So, assuming that you want to check what branches contain changes that already exists in the master branch and thus provides no additional value and can be deleted, this is how I approach that problem. Let’s say that one of the branches is named bugfix42. Then I would run

    git branch bugfix42.test bugfix42
    git rebase master bugfix42.test
    git diff master bugfix42.test
    

    If this applies cleanly and there is no diff, then clearly the contents of the bugfix42 branch is already present on master and bugfix42 can be deleted. Pick the low hanging fruits first, so if you get a merge conflict just skip it for the time being with git rebase --abort and move on to the next branch. When all the trivial branches are done, then you can run again with the remaining branches and resolve the conflicts that occurs (depending on how much effort you want to put in). At the end (or before if you want) delete all the *.test branches.

    Git Baby is a git and github fan, let's start git clone.