What a flow adds on top of branches and merges

Every tool for this course, already in your hands

git checkout -b feature/x, git merge --no-ff, resolving a conflict, git rebase, opening a pull request, squashing on merge: "Git branching & checkout", "Git merging & conflicts" and "GitHub pull requests" already taught every one of those, and you ran them yourself. This course doesn't reteach any of them.

Those courses left one question open. Once you can create a branch and merge it, which branches should exist at all? What should each one be called? What rule decides where a piece of work starts and where it merges back? That rule, applied the same way across a whole team, is what "a flow" means. Gitflow is one named answer to it, and it means more than "using branches".

A concrete before-and-after

Without a flow, a team's branch list can end up like this, because nothing decided otherwise:

main
fix-login-bug
johns-branch
new-stuff
really-fix-login-this-time

Every one of those branches was created correctly, with commands the earlier courses taught. Their names don't say what kind of work they hold, when they're safe to delete, or where a hotfix should start under pressure. Gitflow replaces that list with five roles, covered in the next lesson, each with one job.

What this course covers

Lesson 2 covers Gitflow's five branch roles, from the model's original description. Lesson 3 shows the git-flow command-line tool, which runs the checkout and merge sequence you already know. Lesson 4 is about release and hotfix branches, including the one mistake that brings back a bug Gitflow was supposed to keep fixed. Lesson 5 covers GitHub Flow, the simpler alternative, and what Gitflow's own author says about when to prefer it. Lesson 6 checks this app's branch history to see which model it follows, and lesson 7 runs all of it through one closing scenario.

Where this leaves you

By the end, "which flow?" stops being a matter of taste and becomes a question you can answer from facts. Does this team ship continuously or on a schedule? Does production ever need an isolated emergency fix while a big feature is still in progress? Different answers point at different models.