So the first of these collaborative workflows I'm calling the centralized workflow, it's not really
an official name or anything, but I'm telling you now it is the weakest it's the worst of these workflows
for collaborating.
And the reason I'm showing it to you is that the shortcomings of the centralized workflow are addressed
by the other workflows that we're going to discuss.
So we're kind of motivating the more complicated workflows, but we're starting with the simplest.
So I'm calling it the centralized workflow, a.k.a everyone works on the master branch or everyone works
on the main branch, or everyone works on some single branch.
So that's why it's super easy.
It's centralized because all the work is done on a single branch, whatever that branch is.
Historically, that would just be the master branch, a default, but it could be any branch.
So it's straightforward, right?
We don't have to worry about pushing up a whole bunch of different branches and pulling them down and
merging different branches.
We just work with one branch, so I have some diagrams that I'm going to be using throughout this section.
They all kind of follow the same pattern.
Up top, we have three different collaborators, Pamela, David and Forest, and I'm highlighting one
of them to indicate whose repository we're looking at on their local machine versus up top and the right
corner.
This is the GitHub repository that all three are using.
So this is the same repo on GitHub for everyone.
But then we have three different local repositories, but they're all connected to that same GitHub
repo.
And I have similar diagrams for the other workflows, the same characters, the same format.
So with this centralized workflow, everybody clones the same repository.
So this is our starting point, just one commit.
So Pamela clones it down, right?
There's the master branch or the main branch or whatever we want to name it.
It's the same branch.
So David clones that he gets that default branch master forrest clones the same GitHub repo and he has
it so now they get to work forest this guy here at the mustache spends his day adding and committing.
He's working on some new feature.
He has two new commits, so this is what he started with here.
He has two new commits worth of work on the master branch.
So he wants to share that with everyone, right?
He pushes that up so you can see those new commits.
There's now three total commits on GitHub during this same period where Forest was working and he pushed
his code up.
Pamela has also been hard at work on her own feature all day, so that yellow commit is Pamela's new
work.
OC So as she's been working, Forest already pushed some code up.
Pamela now wants to share her code with everyone, so she wants to push it up so she tries it get push
origin master, but she's not allowed to y well she gets this message failed to push updates were rejected
because the tip of your current branch is behind its remote counterpart merge the remote changes get
pull before pushing again so git is telling her I can't do that.
There are changes that you don't have on GitHub.
You need to get those changes and merge yours with those changes and then you can push back up.
So already we hit a roadblock, right?
Just for Pamela to push her code up, she has to pull down everything that her other collaborators have
pushed up.
They're all working on the same branch.
So if she does that, she pulls down, she gets the changes that forest had pushed from on the master
branch from GitHub.
Then she merges her work in and hopefully that goes smoothly.
There might be a bunch of conflicts, maybe not, but she has to do it and then she can push back up.
So now there are four commits up on GitHub or more, but a minimum of four.
Although I didn't really include there would be a merge commit here.
So let's say five.
But whatever it is, she pushes up her new commits and she's good to go.
Right?
That's her part done for the day.
Now, during all of this, poor David has been working on a new feature, but he's been having some
doubts.
It's not working.
He's really like halfway done.
He's deleted a bunch of important files.
He's commented out some code, things are broken.
So he wants to get some input, some advice from his collaborators.
He wants to start a discussion and he wants them to see the code.
They're not working in an office together.
So he has this work and he has some commits indicated by this face this I guess I would call it a math
face or a neutral face.
I don't know.
Anyway, he's not happy with it, but he makes it commit and if we're using this centralized workflow
one branch, so he's just working on the master branch.
So in order for him to share this, he can't just push it up because as we saw Pamela earlier tried
and Git said, no way, you can't do that.
You've got to pull down, get the changes, then merge and then you can push.
So that's what he does before he can even share this mediocre, unfinished, broken code, he has to
first.
All down, get all the new changes and merge his broken stuff in his incomplete feature.
He has to merge that in with the rest of the work everyone else has done on the master branch.
Then he can push that up and now everyone can go and pull his work down.
And he broke the code base probably if this is incomplete.
Everybody now has that incomplete code and that's really frustrating and problematic.
All he wanted to do is get some input and have some of his collaborators take a look at his work.
But to do that with this workflow, he had to wreck the master branch, the one and only branch.
So hopefully the problem is clear with those diagrams.
It's simple.
You don't have to think about where you're working if you're only working on one branch.
But there are some serious issues, some shortcomings, first of all.
Every person has to spend a ton of time resolving conflicts, or at least merging code, especially
as team size scales up.
Imagine you're working with, let's say, ten developers, and at the end of the day, everybody makes
a bunch of commits, they push them up well for each one of those developers to make those commits and
push them up, they first have to pull down everyone else's work just to merge their stuff in.
So it's a lot of merging and potential conflicts, even if work is not entirely finished.
So that brings me to the next piece.
No one can work on anything without disturbing the main code base.
How do you try some radical experiment?
How do you try removing files and commenting things out, trying to fix some crazy difficult bug?
If you have to work on the master branch, how do you experiment?
And that brings us to the last piece.
There's no way to really collaborate on anything unless you push in complete code up to master.
And now all your other teammates have incomplete or broken code, which is what happened here in our
final scenario.
David wanted is this David?
Yes.
David wanted some help.
He wanted to collaborate with, let's say, Pamela.
For her to get that code, he had to add stuff onto master that's broken.
Push that up.
And now the whole code base is broken, at least at the tip of the master branch.
Everyone else comes to work.
The next morning, they get the most recent changes.
Oh, things are broken for everyone.
So not a good workflow.
It can be manageable if you're a very tiny team and you're not doing anything experimental.
Even then, I wouldn't really recommend it, but it is an option.
So that really serves to highlight the problems with working in one branch, which now motivates us
to talk about workflows that involve multiple branches.
That's coming up in the next video.
I want to demonstrate some of these problems for real using a GitHub repo.