A hierarchical workflow goes like this. Suppose I suspect there's a bug in the Linux kernel that affects our product. I clone the kernel source code to a local directory and start experimenting with the code. At some point, I enlist the help of a colleague, so I push my changes so far into a private repo on my github enterprise profile so he can pull them.
We eventually verify it's a bug, and we have a crude workaround/proof of concept, but we'd like to fix this bug in the official kernel, and it needs a significant amount of work to implement the fix to production quality. We create a repo on our company's private github enterprise to coordinate this work.
When the fix is ready to publish, we set up a public repo on our company's public github account, where our open source review board can approve any changes before they are made public.
We begin coordinating with the people in charge of the appropriate Linux subsystem, refining our changes until they approve it and pull it into their repo.
The subsystem owner coordinates with one of Linus Torvalds' lieutenants to get our change accepted together with other recent changes in the subsystem.
The lieutenant sends big groups of changes from multiple subsystems to Linus Torvalds for approval. He eventually pulls them into the mainline kernel.
All these repos have different owners, different visibility, and different rules for getting code included into them. Some are owned by completely separate companies. Without distributed version control, you would have to manually copy and paste code into new systems whenever you crossed those ownership boundaries, losing the history.