This is the equivalent to git log master..my-cool-branch using Octokit - you want to see if there are any commits on your branch which are not in master:

var head = "my-cool-branch";
var baseBranch = "master";
var compareBaseToHead = await client.Repository.Commit.Compare(owner, repo, baseBranch, head);

if (compareBaseToHead.TotalCommits == 0)
{
    Console.WriteLine("Branch {0} has been merged into {1}", head, baseBranch);
}
else
{
    Console.WriteLine("Branch {0} has NOT been merged into {1}", head, baseBranch);
}

TL;DR

Don't use a REST API for this.¹ Git doesn't have one. Use git branch --merged. But be aware of what it actually does.

¹If you do use one, be aware that it almost certainly just uses git branch --merged, or an internal equivalent. Also, be aware that the REST API on hosting server A is different from the one on hosting server B, which is different from the one on hosting server C. Hosting server D doesn't have an API for it. But Git can do it natively, and this will work regardless of your hosting server.

Long

Branches, in Git, don't exist.

OK, that's obviously not true: they do exist. But in a very important way, they don't matter. Only commits really matter. Branch names mainly serve to find commits. Merging is done by merging commits, even if you use a branch name in the process. So the trick is to ask the question about commits first. Only later, after you have that answer, should you start wondering about branch names.

Because of this, it's in general impossible to say which branch was merged. But it is easy to tell if some particular commit is merged. And, a branch name, like master or develop, always identifies exactly one commit. It's just that the specific commit that master identifies changes over time. So does the specific commit that develop identifies, and so does the specific commit that feature2 identifies, and so on.

Pictorially, these things may look like this:

       I--J   <-- feature1
      /
...--H   <-- master
      \
       K--L   <-- feature2

Here, neither feature1 nor feature2 is merged to master. This is because the commit identified by the name feature1, i.e., commit J—J stands in for its actual hash ID, which is some big ugly string of letters and digits—is not an ancestor of commit H, which is the commit identified by the name master. However, master is merged into feature1, because commit H is an ancestor of commit J. Similarly, master is merged into feature2.

If we now use:

git checkout master
git merge --ff-only feature1
git merge --no-ff feature2

on the command line, and everything works, we get a new merge commit M, so that the name master now points to this merge commit:

       I--J   <-- feature1
      /    \
...--H      M   <-- master
      \    /
       K--L   <-- feature2

Note how all we did was add a commit to the drawing: new commit M points back to existing commits J and L. The branch name master now identifies commit M, rather than commit H.

Since J and L are both ancestors of M, but M is not an ancestor of either, branches feature1 and feature2 are now merged into master. Note that at this point, we can delete the name feature1:

       I--J
      /    \
...--H      M   <-- master
      \    /
       K--L   <-- feature2

Commit J is still an ancestor of commit M, so the commit is merged. But branch feature1 no longer exists. It doesn't matter for using Git, but now, the list of branch names that identify commits that are ancestors of M no longer includes feature1. We can do the same with feature2:

       I--J
      /    \
...--H      M   <-- master
      \    /
       K--L

We can now create a new branch name, such as feature/short, that points to commit J:

       I--J   <-- feature/short
      /    \
...--H      M   <-- master
      \    /
       K--L

Commit J is still an ancestor of commit M, so branch feature/short is merged to branch master.

Git itself—not GitHub and not GitLab, just plain old Git—can tell you which branch names point to commits that are ancestors of some other branch name:

git branch --merged master

first finds commit M, then loops through all branch names—in this case, feature/short is the only other branch name left—to see if the commit that those branch names identify is an ancestor of commit M. At the moment, that is true of feature/short, so git branch --merged will list feature/short.

If we git checkout feature/short and put a new commit on it, though, we get this:

       I--J---N   <-- feature/short
      /    \
...--H      M   <-- master
      \    /
       K--L

Commit N is not an ancestor of commit M, so branch feature/short is not merged to branch master. Running git branch --merged master will no longer list feature/short.

Remote-tracking names

To do this from your own Git repository, rather than from some hosting-service API, you will need a clone of the Git repository from the hosting-service. When you make such a clone, unless you use --mirror,² your Git will rename their branches. You will have, instead of branch names, a series of remote-tracking names, of the form origin/master, origin/develop, origin/feature1, and so on.

After copying their commits to your repository and renaming their branch names to your remote-tracking names, your own Git will create one branch name in your repository, pointing to one of the existing commits you got from them. By default, your Git will create your master pointing to the same commit as their origin/master. However, over time, their branch names will change: they will point to newer, better-to-use commits. You will need to run:

git fetch

or:

git fetch --prune

to get your Git to pick up their new commits and update your remote-tracking names. Using --prune will make sure that your Git removes old, stale remote-tracking names: for instance, after their Git has deleted their feature/short, your Git will continue to have origin/feature/short until you do a fetch with pruning turned on. Your Git will then notice that they don't have feature/short and remove your origin/feature/short.

What you'll want to do here is use:

git branch --merged -r origin/master

The -r option tells git branch to look at your remote-tracking names rather than your branch names. The origin/master tells your Git to use the commit that your origin/master—their master as of your last fetched update—identifies. So now you'll get a list like origin/feature1 and origin/master as remote-tracking names that point to commits that are ancestors of the commit to which your origin/master points.

²It's unlikely that you want to use --mirror.

I use the following script:

git log main --first-parent --merges \
        --pretty=format:"%h %<(10,trunc)%aN %C(white)%<(15)%ar%Creset %C(red bold)%<(15)%D%Creset %s"

Explaining each argument:

• main: the name of your main branch. Can be omitted, in which case the current branch will be used.
• --first-parent: skips commits from merged branches. This removes the entries where someone merged master into their branches.
• --merges: shows only "merge commits" (commits with more than 1 parent). Omit this argument if you want to see direct commits to your main branch.
• --pretty-format: applies the following formatting:
  • %h: the commit short hash;
  • %<(10,trunc)%aN: author name, truncated at 10 chars;
  • %<(15)%ar: the relative commit time, padded to 15 chars;
  • %<(15)%D: the tag names, also padded to 15 chars;
  • %s: first line of the commit message.

The result is pretty satisfying: