Welcome back.
Let's continue from our previous video to talk about a more advanced workflow and get and GitHub.
Now, up to this point, both Marcy and I have just been working on over here, branch master.
What does that mean?
Well, it says branches, but I only see master here.
And you might have noticed one issue with the way that we were doing things.
That is, if it's my first day on the job and I just changed the title.
But maybe we didn't even want that change.
Maybe that breaks our branding or breaks our app.
But I was able to do it so easily to change it into Master.
Maybe Marcy didn't even know that.
I've added that change.
And that's a big problem, right?
You don't want to put things into what we call production, into what the user sees.
If it's going to break our website, if you're a big company like Facebook, that could mean millions
of dollars in lost revenue, even if you have a bug that lasts a few hours.
So I'm going to show you a more realistic workflow that you'll have, and that is with branching.
Let me show you what I mean.
I have over here a visual of what Jed is really, really good at.
Up until now, we've been working on what we call master.
That is the master branch.
Think of the master branch as the authority.
This is the right way that our app or our website should look.
And up until now, when I added the cool background title, well, I went from background generator
to cool generator.
And then when Marcy changed it to capitalized letters, then we went to here and we just went in a linear
fashion from one end to the other to the other to the other.
But like I said, that is a bit of a problem.
So a better thing to do is what we call branching.
If I wanted to change the title, I will create a branch and just call it little feature, for example.
And I just work on that branch on my own without affecting the master branch.
What the user sees.
And.
Only when it's finished, when Marcy has reviewed it, when we have tested it and everybody on the team
is okay, then we bring it back into Master.
And you can see over here with the big feature, you can keep going for a long time on your own branch
and only when you're done.
Do what we call merge into master.
I'm going to show you how that works today.
I'm going to close this and remember our example.
We have Marcy's computer here with all the files, and we have my computer here with all the files.
We both have our workstation set up.
And now you see what master in my terminal means when I'll show you in the notes afterwards how you
can have this set up so it tells you what branch you're on.
But we can see that we're both on Master.
That's my computer.
And Marcy's computer is also on Master.
We want to make sure that we're both up to date with the latest GitHub.
So Marcy's going to do get pull and I'm also going to do get pull.
And let's say that I'm now working on a new feature, and because it's a better workflow not to work
on master and this is a good tip generally don't work on master always branch off.
If I do get Branch, they'll show me that.
Well, I only have one branch and that is master.
But we can add to it.
We can say get branch new or little feature.
And now if I do get branch.
I see that I have little feature, but master is highlighted because I'm currently a master.
So the way I would go to the little feature branch, I'll say Get check out.
Little feature.
And there you go switch to branch little feature and now I'm on Little Feature Branch.
So what I've done is I've branched off of Master and now created little feature.
Let's create a bit of a change.
I'm going to say in the little feature, we're going to change the current CSS background title to say
this is the background.
I'm going to safe here.
And again, I do my simple workflow that we did in the last video get status.
I see that.
Yeah, we have the index.html change.
It's going to clear so we can see.
So now that we've made this change, let's do get add.
And again, just get status to make sure everything went through.
Yeah.
We're ready to commit index.html so we'll do get commit commit message will be changing text.
Perfect.
Let's clear that.
And now, again, in order to let GitHub know of the changes we need to do, get push.
So we'll do get push.
All right.
Let's go to GitHub and see what happened.
We see that now we have this yellow bar that just showed up and says, you recently pushed branches.
So if I click on the screen button here, compare, pull, request.
It shows me what changes I have, which is I've changed the title and here I can let Marcy know saying,
Marcy, I've changed the text.
What do you think?
And I click on Create Pull Request.
And now I have my PR and you see here how it says merge pull requests.
Well if we go back to our diagram, I've created this little feature and now I'm saying, Hey Marcy,
I've just done this new change.
What do you think?
Is it okay for me to merge it into Master?
And what will happen here most likely is Marcy will come see this pull request.
You can see that we're on the pull request tabs.
So she'll be able to see them and seeing, Oh, Andre just did this change.
She'll look through the changes.
And she'll say, Hmm, well, if she likes this, she could be like, Looks good.
She can click on start a review.
And you know what?
She likes this or she's just going to approve.
Now, Marci or myself.
Usually you don't want to merge your own pool requests.
Somebody on the team does it.
Can now just say merge.
Pull.
Request, confirm.
Merge.
And there you go.
Some teams like deleting the branch afterwards, so you can just click delete here.
If I go back to the code.
Well, I don't have the branches anymore because I just deleted it.
But in my master if I go to index.html I see this is the background.
So now Marci can go to her project and say, Get pull.
And again.
She has the latest update.
Now let's talk about some conflicts that can arise.
Now, let's say Marcy wants to change something, and I also change the same thing and we get a merge
conflict.
Let's see what happens.
So let's say Marcy wants to change, create a new feature saying we'll call this one big feature.
And she'll say get check out or get branch.
Big feature.
She'll say, get check out big.
Feature.
And if I do get branch, we see that there's a new branch here.
Let's clear that.
And she'll say here that she wants to change this back to a background color or a background generator,
because all the users are complaining that the title changed and they like the old title.
So she changed that.
She has done the get add.
Get commit.
Reverting back to old title.
Perfect.
And then she's going to do get push.
Oh, let's clear that first, actually.
And we do get push.
A first time you get this, you might get this error saying that there's no upstream.
You just copy the code that they give you here.
Perfect.
Now, if I go back.
Back on generator.
I see the big feature pull request over here.
And just to show you that you can have multiple commits, let's say Marcy decides to, oh, this is
me.
Marcy decides to add an exclamation point here.
She can just say again, she saves this.
That's clear.
She'll say get add.
Get commit.
You do this a lot so you will get really, really good at get after working in a company for a while
and she'll say Added X exclamation.
Oops.
So what I want to do, get commit.
Commit.
Added exclamation.
And she'll do get push again.
And let's go back to get help.
If we look at the poor request, they'll actually have both of these reverting back to old title and
add it exclamation.
And we see over here both of the changes create the pull request needs changes.
Andre.
So while this poll request is out there.
I decided to start a new branch called Let's just call it conflict for now.
And I'll get check out conflict.
And now in the conflict branch.
I decide to change.
This to just completely remove the cool generator.
I save that?
Again.
I check my status and index.html file has been changed.
So while this is happening, I get marci to merge to pull request.
So she's entered it into master.
Her pull request is in.
And now if I go back to my conflict and I do get status.
And we have to add these.
So get add, then get commit.
I'll just do a short message here.
Just check.
And now if I go back to Master.
Oh, I have to do.
Get checkout out, master again.
Before I push my changes, I want to make sure that I have the latest version of a master.
So I'm not changing anything.
I won't have any conflicts.
So I'll do get pull to get the latest.
And now I go to get check out.
Conflict branch.
And I can do this command get.
Merge master.
So I'm saying merge whatever is a master into conflict.
Marci has been working on the big feature and she's merged it.
So now Master has the big feature branch.
I've also created another branch and I've been working on my own on the conflict branch.
And the conflict branch doesn't know anything about master.
So I'm saying, hey, whatever is in Master right now, which includes the big feature that Marci worked
on, pull it in and make sure that there's no conflict.
So I do that.
And oh I get conflict merge conflict and index.html file.
Now if I actually click on sublime text, let me open this up so you can see it better.
Oh, boy.
I get this weird little syntax.
It's overwhelming at first, but it's easy to see what happening.
Head is where my branch is at and it shows me that here to the end I don't have the H one anymore.
But in the master branch we have background generator.
Now I can talk to Marcy and say, Hey, Marcy, do you want to keep the background generator title?
And she'll say, Yes, that was the right thing to do.
Don't change the background.
Well, in that case, I just remove these lines.
And remove this.
And save.
Now, if I do get.
Status now.
Okay.
We have the modified status here.
Let me just make this smaller again so you can see.
So let me clear this.
What we do now is we have to do get add again because we've made those changes and we have to do get
commit fixing, merge issue.
And I forgot the.
Let's try that again.
And.
Conflict fixing merge issue.
Let's clear here and do get status.
Nothing to commit, working to clean.
And if I do get push, well, again, I get this error.
But I want to show you this time around, if I do get push origin conflict.
It now works.
Let's go back to GitHub.
See what sort of things we have.
We have the conflict branch and if we look at the conflict branch now, well, there's nothing changed
because well, I just reverted all my changes.
So it's completely empty.
There's no changes now.
So Marcy would be like, Hey, did you mean to, to make this PR, it's empty.
So I'll see this message on my PR and I can keep going.
And that's pretty much the workflow that you'll see in GET.
I'll leave the commands for you after this.
But you see, it's very, very nice to work with you, learn a few commands and as long as you have
this visual model of every time you're working on something, you always create a branch.
You title it with whatever feature you're working on.
And every once in a while, you want to pull master and merge master into your branch to make sure that
you're not missing out on any updates that other developers or teammates have done.
Once you're done with your feature, you make a pull request by doing get push and that pull request
you'll add comments and people will review your file changes.
And if they want you to make a few changes, then you can do again, get, add, get commit.
Finally make your changes and then you can merge, pull, request.
And once that's done then everybody else on the team, there's now a new master.
So everybody else on the team should do get pull as well.
It does take a bit of time to get used to, but is a really, really nice workflow to make sure that
everybody on the team works on the same files, the same projects, without causing any errors and making
sure that everybody collaborates well.
And that's it.
I hope you found this useful.
I'll see you in the next one.
Bye bye.