Okay.
So as we've seen the centralized workflow aka everyone works on one branch is not ideal.
Quite a few issues.
That brings us to our next workflow feature branches.
I don't really know what to call it, but that's the concept.
Work on feature branches don't work on master you silly goose.
That's the main idea.
If the centralized workflow is everyone works on master, the feature branch workflow is nobody works
on Master or Main.
You always work on a feature branch.
This is a very, very common pattern.
Rather than working directly on the master branch or the main branch or any centralized branch, all
development, whether it's something tiny or some massive new feature or a redesign or a bug fix, all
development should be done on separate branches.
So part of this means treating the master or main branch as the official project history.
The branch right?
Like the sacred branch that you're not going to work on.
Instead all work is done on these side feature branches and then merged back in to the master or main
branch when appropriate.
This allows multiple teammates to collaborate on the same feature without having to mess up the master
or main branch.
Like with what happened with the centralized approach to share broken code or incomplete code also meant
breaking the master branch.
So with this feature branch workflow, I could have a branch that never works.
It's always broken and I can collaborate on that with anybody else, any number of collaborators.
So my master or main branch should not contain any broken code unless somebody messes up and thinks
code is not broken and they merge it back in and it actually is broken.
So back to our diagrams.
Here's the same three characters Forest, David and Pamela.
They all clone the same GitHub repository.
It starts with two commits and a master branch or a main branch.
In this diagram, master is the default branch name.
So Forrest clones it, Pamela clones it and David claims it.
Everyone's at the same point.
So we work on feature branches.
David starts working on a new feature.
He's working on a branch called Add Dark Theme.
So he's hit a point where he's not totally done.
He's maybe 30% of the way there, but he wants to share his work with the rest of the team, and specifically
he wants some help from Pamela.
He wants her feedback, or maybe he wants her to write some code.
So he pushes his branch up, he pushes add dark theme up to GitHub.
So he didn't merge it into master, right?
It's not merged into anything.
He just pushes that feature branch up to GitHub.
So at the same time during this morning or afternoon or whatever it is, Pamela has been working on
her own new feature, Animated Scroll.
It's the name of the branch she is working on.
It's a totally separate branch.
It's in yellow here to make that clear.
She's not working on Master.
Nobody works directly on Master or Main, so she's working on her branch.
She's made good progress.
But then she gets a chat message from David.
David sends her a slack, saying, Hey, Pam, can you please take a look at the work that I did today
on the branch?
What was it called?
Add dark mode.
Is that what it was at Dark Theme?
Can you take a look at that branch, pull it down from GitHub and let me know what you think and add
some of your own work.
So that's what she does.
She pulls down that branch.
She didn't have to stop what she was doing and merge this into some other branch.
She can just leave her animated scroll branch where it was if she's not ready to share it and she just
pulls down his branch.
So we've seen how to do that and how we can switch to a remote branch we can fetch to see if there are
new branches that we don't have and then switch to them.
So she gets his feature branch down at Dark Theme and it doesn't pollute the master branch, it doesn't
pollute her animated scroll.
They can co-exist side by side.
So she takes a look.
She makes a couple of improvements.
She even adds her own commit on the same feature branch.
So it was three.
Now it's four commits.
So she pushes those up.
Add Dark Theme is now updated on GitHub.
She tells David, Hey, I added some new work.
Go ahead and pull down those changes.
And so he returns to work the next morning.
I guess this was late at night or evening and after some editing in the morning he decides, okay,
I guess I should get back to work.
But all that he has are these three commits on add dark theme.
All he needs to do is pull down, see if there's any new information he could fetch first to check,
but he gets the new work from that branch on GitHub that Pamela did, and now he can continue his work.
And then at some point, maybe he decides he's happy with the new feature and he can merge it into Master.
So that's what I'm illustrating here.
So that actual mechanic, your mechanism for merging into master.
Usually you don't just decide if you're at a big company, you don't decide.
All right, this goes in, master.
There are usually some controls.
I mean, at the very least, there's code review.
Somebody or a team of people need to look at what you've written, right?
Things need to pass tests.
So it's not a matter usually of just merging it in whenever you want.
And we'll talk about some of those mechanisms for code approval and rejection, but that doesn't really
matter for this workflow right now.
All that matters is that when a branch is done or when a feature is done, it can be merged into master.
So this would ideally and the way that this is supposed to work, this is a fully done feature.
It's not broken, it's ready to go.
Then we merge it into the main branch of the master branch.
We don't merge broken stuff in unlike the previous centralized workflow, so everyone works in a branch
on a given feature.
You can have multiple branches too.
It's not necessarily like Pamela's branch and David's branch, it's more one branch per feature or branch
per bug fix.
Branches are feature oriented, so this allows us to then share those branches, collaborate on branches,
and keep our master or main branch as the source of truth and our repository as the stable, always
working, functioning, non broken branch in our project.
And of course the last thing that would need to happen once David merges his new feature branch in is
he would push that up so that GitHub is updated and now everyone's master branch would include those
new commits, those new changes that he made on his feature branch originally.
So that's the main idea, master or main or whatever you want to call it.
You treat it as a branch that is not to be screwed with.
It's the official project history.
All work is done on separate branches and then those branches can be either abandoned or eventually
merged back in to the official project history.
Whether that's Master or Main, remember this slide from the centralized workflow?
These were all problems with working on one branch.
No one can work on anything without disturbing the main code base.
That's not a problem.
If you're working on a feature branch.
The only way to collaborate on a feature is to push incomplete code to master.
Nope, that's not a problem.
Now if everyone works on feature branches, way less time spent resolving conflicts and merging code
because now code only needs to be merged when something is ready to go into master.
Not any time anybody does literally any commits, which is what happened when everyone works on one
branch.
In conclusion, feature branches.
Much better approach.