Until now the GitHub flow seems relatively straightforward. But there wouldn't be a whole course about it when it wouldn't get a bit more complicated.

The problem starts when you use it in a team. That's because software development in a team is not a sequential process. In a team, you don't work on one feature until it's done and merged and only then continue with the next task.

Usually, several developers are working on different branches at the same time. But even a single developer is often working on multiple branches.

For example, this is a typical situation: You implement a feature on one branch. Once you're done you request a review. But it might take hours or even days until the code is reviewed. In the meantime, you have to continue working on something else and create another branch while the first one is still active.

This quickly gets complicated. Especially, if there are multiple open Pull Requests at the same time which might even depend on each other.

To summarize: When you work on a project alone this workflow is still easy. But when you're in a team a lot of the headache and confusion are related to keeping everything in sync.

Next: A Roadmap