Post History

> _I think a branch is a set of commits_

Well, technically **no**, it's not. But first things first.

---
# DAG (Directed Acyclic Graph)

Personally, Git became much more easier to understand after I've read things like [this](http://think-like-a-git.net/). The "*whoa*" moment was when it compares Git to a [DAG (Directed Acyclic Graph)](https://en.wikipedia.org/wiki/Directed_acyclic_graph). I'm not going into all the math theory, but just think of a Git repository as a series of nodes pointing to each other.

Each commit is a node in the graph, which points to other nodes: some are the data (folders/files), and some are the parent commits (the commits that "came before").

And a branch is just a pointer to one specific commit.

When you init a Git repository and create the first commit, Git by default creates the master branch and makes it point to that commit:

```none
+--------------+
| first commit |  <-- master
+--------------+
```

When you create another commit, Git creates another node for it, makes it point to the previous one and update the master branch to point to the newer commit:

```none
+--------------+     +---------------+
| first commit | <-- | second commit |  <-- master
+--------------+     +---------------+
```

When you create a new branch, Git simply creates another pointer, with a different name. Let's say my repo contains the two commits above and I do `git branch new_branch`. The result is:

```none
+--------------+     +---------------+
| first commit | <-- | second commit |  <-- master
+--------------+     +---------------+
                            ↑
                        new_branch
```

Git created the branch, by simply creating another pointer to the same commit. Now let's suppose I do `git checkout new_branch` (to actually "switch" to that branch) and create a new commit in it. The repo will be like this:

```none
+--------------+     +---------------+
| first commit | <-- | second commit |  <-- master
+--------------+     +---------------+
                            ↑
                     +---------------+
                     | new commit in | <-- new_branch
                     |   new_branch  |
                     +---------------+
```

---
And what if I create another branch from `new_branch`? It'll simply create another pointer to the same commit:

```none
+--------------+     +---------------+
| first commit | <-- | second commit |  <-- master
+--------------+     +---------------+
                            ↑
                     +---------------+
                     | new commit in | <-- new_branch
                     |   new_branch  | <-- another_branch
                     +---------------+
```

And adding a new commit to `another_branch` will be like:

```none
+--------------+     +---------------+
| first commit | <-- | second commit |  <-- master
+--------------+     +---------------+
                            ↑
                     +---------------+
                     | new commit in | <-- new_branch
                     |   new_branch  |
                     +---------------+
                            ↑
                     +----------------+
                     | new commit in  |
                     | another_branch | <-- another_branch
                     +----------------+
```

Now, if I want to merge all changes from both `new_branch` and `another_branch` to `master`, I just need to merge `another_branch`, because it already "contains" the changes from `new_branch`.

A merge basically finds the common ancestor between the 2 commits and apply all changes, starting from this common ancestor and ending in the target branch. In the example above, if I switch to `master` and do a `git merge another_branch`, it'll also apply the `new_branch` changes, because their commits are also part of the chain.

---
Based on the output provided in the comments:

```none
Fri Jul 23 10:42:47 2021 -0400 725d9d1c11 [ca99f826dc] (HEAD -> feature/ct-comparisons-VER-75425, origin/feature/ct-comparisons-VER-75425)
Thu Jul 22 16:27:48 2021 -0400 ca99f826dc [6498847a48]
Thu Jul 22 11:05:17 2021 -0400 6498847a48 [9b2ddff48d] (origin/feature/null-rows-VER-74021-VER-75002, feature/null-rows-VER-74021-VER-75002)
Thu Jul 22 11:02:59 2021 -0400 9b2ddff48d [37329f2ec7]
```

Your situation seems to be exactly the one described above. In general terms, it's something like this:

```none
A <- B <- C <-- master
          ↑
          D <- E <-- branch_A
               ↑
               F <- G <-- branch_B
```

Therefore, if you merge `branch_B` onto `master`, you'll end up merging `branch_A` as well (or, in other words, the commits from branch A will also be included in the merge).

If `master` has no other commits after `C`, the merge will be made using a simple fast-forward, and the repo will like this:

```none
A <- B <- C
          ↑
          D <- E <-- branch_A
               ↑
               F <- G <-- branch_B, master
```