Welcome back.
Let's continue from our previous video to talk about a more advanced workflow and git 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 git 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 Web site should look.
And up until now when I added the cool background title Well I went from a background generator to
cool generator and then when Marcy changed 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 that little feature for example.
And I just work on that branch on my own without affecting the master branch what the user sees.
Only when it's finished when Marcy has reviewed it when we have tested it and everybody on the team
is OK.
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 gonna 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 workstations set up and now you see what master in my terminal means and 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 in Master.
We want to make sure that we're both up to date with the latest github.
So Marcy's going to do git pull and I'm also going to do git 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 git 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 git branch new or little feature and now if I do git branch I see that I have little
feature but Master is highlighted because I'm currently on master.
So the way I would go to the little feature branch I'll say git checkout little feature and there you
go.
Switch to branch little feature.
And now I'm on a 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 save here.
And again I do my simple workflow that we did in the last video git status.
I see that.
Yeah.
We have the index.html changed, going to clear so we can see.
So now that we've made this change let's do git add and again just git status to make sure everything
went through.
Yeah we're ready to commit index.html.
So we'll git commit message will be changing text. Perfect.
Let's clear that.
And now again in order to let github know all of the changes we need to do git push.
So we'll do git push.
Lets 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 this green button here compare and 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 request.
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 OK for me to merge it into master.
And what will happen here most likely as Marcy's 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 Andrea just did this change.
She'll look through the changes and she'll say Hmm well if she like says she can be like looks good
she can click on start a review and you know what she really likes it so she's just going to approve
Now Marcy or myself.
Usually you don't want to merge your own pull request 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 Marcy can go
to her project and say git 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 our 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 git checkout or git branch.
Big feature. She'll say git checkout big feature.
And if I do git 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 background color or background generator because
all the users are complaining that the title changed and they liked the old title.
So she changed that.
She has done the git add, git commit,
reverting back to old title perfect and then she's gonna do git push.
Oh let's clear the first actually.
And we do git 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
to background 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.
Let's clear she'll say git add, git commit. You do this a lot.
So you get really really good at git after working in the company for a while and she'll say added exclamation.
That's not what I wanted to do. Git commit.
Commit added exclamation
and she'll do git push again.
And let's go back to github.
If we look at the pull request they'll actually have both of these reverting back to old title and added
exclamation and we see over here both of the changes create the pull request needs changes.
Andrea
so while this pull request is out there I decided to start a new branch called Let's just call it conflict
for now.
And I'll do git checkout 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 Marcey to merge the 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 git status and we have to add these so git add then git commit
I'll just do a short message here.
Just check and now if I go back to master. Oh I have to do git checkout master again before I push my
changes I want to make sure that I have the latest version of master so I'm not changing anything.
I won't have any conflicts so I'll do git pull to get the latest.
And now I go to git checkout conflict branch and I can do this command git merge master.
So I'm saying merge whatever is in master into conflict.
Marcy has been working on the big feature and she's merged it so now Master has the big feature branch but...
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 Marcy worked on.
Pull it in and make sure that there's no conflict.
So I do that and oh-oh I get conflict merge conflict in 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 h1 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 git status now OK.
We have the modified status here.
Let me just make this smaller again so you can see.
Let me clear this.
What we do now is we have to do git add again because we've made those changes and we have to do git
commit fixing merge issue.
And I forgot the "m". Let's try that again.
Conflict fixing merge issue.
Let's clear here and do git status.
Nothing to commit, working tree clean.
And if I do git push Well again I get this error but I want to show you this time around if I do git
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
we just reverted all my changes so it's completely empty.
There's no changes now so Marcy will be like hey did you mean to, to make this PR?
It's empty.
They all see this message on my PR and I can keep going.
And that's pretty much the workflow that you'll see in git.
I'll leave the commands for you after this.
But 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 team mates have done.
Once you're done with your feature you make a pull request by doing git 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 git add, git 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 git pull as well.
It does takes 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 same projects without causing any errors and making sure that everybody
collaborates well and that's it.
Hope you found this useful.
I'll see you in the next one.
Bye-bye