Here's how to look at branches: every commit is like a branch, and a branch is just a pointer to a specific commit (so a branch is basically a commit with a pointer to a commit)
main --- c --- c1
reed creates a commit with a pointer to c1, so we add a 'branch' which is just a commit (c2)
c1 <- c2 <--> r1 -- r2 --r3 --> reed makes a pull request
meanwhile darrell creates a (commit) or branch that points to c1 also, (c3)
c1 <- c3 <--> d1 -- d2 -- > darrell makes a pull request
Now git just has to merge the r's and the d's and if there's conflicts that's fine because they are separate and isolated,
so if reed wants to merge histories, and starting from c2: he added r1 -- r2 -- r3
and darrell wants to merge histories, and starting from c3, he added d1 -- d2
then the main state = c -- c1 -- c2 -- c3 /-- c6
c1 <- r1 -- r2 -- r3 -> m-- c4 \ /
c1 <- d1 -- d2 -> m -- c5
Here the main state looks confusing at first, but imagine the state without branches:
main state = c -- c1 -- c -- c1 -- c2 -- m -- c3 -- m -- c -- c1
In the above example it's harder to identify which c caused a problem if something breaks
The other may look more confusing, but when it comes time to identify where an error is and rollback, it's simpler
Imagine if I said there's an error in r1 we know automatically where it is and how to rollback
But here:
main state = c -- c1 -- c -- c1 -- c2 -- c3 -- c -- c1
If I said there's an error in c it's not clear how to find it, or how to rollback