List all branches from develop

Question

I need to find all the branches taken from develop, as apposed to master.

From a programming point of view, I could:

1. List all branches
2. For each branch, use merge-base to get the first ancestor of develop branch and master branch
3. Compare the ancestor commits for the newest, if it is develop, list in output

Not sure if master is needed. If master comes from develop or develop comes from master, does it matter?

So the end result is rebasing all branches taken from develop to master. Merge conflicts are likely.

Thanks for your help.

Answer 1

Branches don't come from other branches. There are no parent/child relationships between branches, either. This is all a bit difficult to describe properly, because the word branch in Git is poorly defined. It has at least two different (but related) meanings, and often even more than those two, depending on the speaker / writer.

The reason for all this confusion—which leads to a real problem with answering your question—is that a branch name, like master or develop, is just that: a name, of type "branch name", holding one commit hash ID. But "a branch" sometimes means a branch name, and sometimes means some set of commits ending at a specified commit—often the commit specified by a branch name, but sometimes the commit specified by something else (e.g., a remote-tracking name like origin/master).

So far, this isn't really a fatal blow to the idea of figuring out a "parent branch". But the thing is that these branch names move. In Git, what really matters is not the names, but rather the commit graph. While we can draw the commit graph in many different ways (see Pretty Git branch graphs), the graph nodes themselves, once created, are fixed forever. In other words, no part of any commit can be changed in any way. It's the commits themselves that contain the linkage to previous commits, and that part cannot be changed any more than any other part.

Let's take a simple example:

... <-F <-G <-H   <-- master

Here, the name master locates commit H, where H stands in for the actual hash ID of some commit. Commit H itself locates earlier commit G (internally, H's metadata contains G's hash ID). So H points back to G. Likewise, G points back to F, and so on. Following this chain of commits, reading out their snapshots, produces the history in the repository, because the commits are the history.

But now let's have two branch names. Initially, both point to existing commit H:

...--F--G--H   <-- master, develop

Now we create a third branch name for a feature, e.g., feature/short, pointing to commit H:

...--F--G--H   <-- master, develop, feature/short

We'll create even more names, such as feature/tall and feature/wide and feature/narrow. Eventually, we'll have some commit(s) on these branches, and then we'll *advance the name develop:

...--F--G--H   <-- master, feature/short
            \
             I--J   <-- feature/tall, develop

It's now "obvious" that feature/tall and develop are in sync, so we must have created feature/short from master and feature/tall from develop. But of course we didn't.

Using git reset, we can make any branch name point to any commit. So if we start with:

...--F--G--H   <-- master, develop

and create a branch from develop, but then force develop to move backwards to select commit G, we'll have:

...--F--G   <-- develop
         \
          H   <-- master, feature/tall

Once again, the obvious conclusion—that we created feature/tall from master rather than develop—is wrong. And these are just the simple cases!

What this means in the end is that the question you've asked does not have an answer. You must focus instead on what you intend to do with commits. It's the commits, not the branch names, that matter, in Git. The branch names—to the extent that there are any; none are required because there are other kinds of names—are just convenient ways for us (and Git) to find the commits.