Welcome back and let's continue discussing GitHub and version control, so let's go briefly on what
we have covered in the previous lecture.
So first of all, we went over to GitHub, dotcom, and we have created we have went over the sign up
process.
Then we have downloaded the GitHub desktop app.
And here we created a new repository by pointing out the project that we are working on from the beginning
of the course.
And then we pushed it to the cloud of GitHub, OK?
And by that, we have created a repository in the cloud.
Here it is.
And now it is safe on the cloud.
From this point, we went over to the GitHub desktop app and we've seen that any changes that we are
making and by chance.
All right.
For example, ABC.
It is reflected in GitHub desktop immediately, and then we can put some note, the comet, which comet
means is on hold, the changes are on hold, and then once we commit, then this button turns into push.
We can click on this button and it pushes the changes to the main branch.
OK, this is what we have covered in the previous lecture.
I've also mentioned briefly the branches topic, and I've said that we're going to elaborate on it later.
OK, so later is now.
And let's talk about branches and what are they?
So what are branches?
Let's first go over the slides and then I'll explain what we have just read and then you will see some
live code example.
So called branching enables software developers to work on different parts of the project without impacting
impacting each other's work.
Team can efficiently organize a on a efficiently organized work on shared code base on different branches,
while while one is not interrupting the other, the main branch is the default branch, which the programmers
mission is to keep him intact and earless at all times.
Once we create a new branch, it will be a complete duplicate of the main branch and then we will apply
changes on top of it.
OK, so basically what we're going to do now is to create a new branch.
All right.
We're going to create a new branch and we're going to make changes on top of it and not on top of main
branch.
OK, that way developer AI could create his own branch while developer B.
Could create his own ranch.
They both can work on their personal branches without interrupting each other while committing and pushing
to their own branch.
OK, so I'm Developer A. And there is a second developer, developer B, I'm creating my own bridge
while the second developer creates his own branch.
And then we can each of what each one of us can work on the project without interrupting the other.
Because imagine yourself that currently I'm working on Collection's dictionary basics and I'm changing
this line line of authority and I've changed the line.
And then I said commit and then push.
And the other developer also made changes on this line line 30.
So we would have many problems because we're both working on the same file simultaneously and pushing
to the same branch, our changes.
So basically, GitHub would go crazy and would not know what to do with it.
But once we create, each of each of us creates his own branch, OK, which is a duplicate of the main
branch.
There is no such problems because each of each one of us works on his own branch, OK?
And then once they are done, developer AI and developer B, once they are done committing and pushing
through their own branches like the finish to making me making their changes.
OK, their branch should be merged to the main branch.
OK, so we're going to go over all of this flow right now in a few minutes.
It sounds horrible.
It sounds hard, but stay with me.
I'm going to help you.
And we're together, going to go over all of these steps.
OK, I feel your pain.
Don't worry.
Everything's going to be all right.
So we're going to leave this sketch here for a second and we'll go back to it at the end just to restudy
what we're going to see right now.
So, first of all, let's see a live goat example.
So right now, we are in main branch and we're going to create a new branch, OK?
We are only branch and we're going to create a new branch, OK?
Clicking on this pass Central Park right here, then we have new branch and let's create Branch see,
OK, I already created Branch in Branch B, so let's create Branch C.
All right, now we have created Branchy, but still it's on our local machine and we need to push it
to GitHub.
So GitHub would also be familiar with it.
The cloud would be familiar with our branch.
So click on this.
And now let's do some exploring.
All right, we are on Branchy and let's make a small change.
OK, let's add here, Brint.
This line will appear at Branch C..
OK, I've made some changes, I'm on Branch C and I've seen I'm seeing this record right here.
I've removed removed this line and added this line right here.
I'm going to add a note here.
I removed all print, added a new print.
OK, this is the comment commit.
Then it turned into Bush, pushing and pushing to where to branch.
All right.
And now let's have a quick look, we we discussed about GitHub desktop connected to both by charm and
to GitHub dotcom, and let's test it.
OK, let's put this word to the test.
So right right now we're on Branch C and we've made this change the change here.
We deleted the old print and added this line would appear on Branchy.
Let's for a second switch to Main and see if this line stays here once we click Dumaine.
All right, Buck, you've seen the change.
OK, the old line that we have removed a here and the new line, the new changes does not appear here
because these changes were not made on the main branch.
We have created a new branch which indicates the line here, and the main branch does not see these
latest changes.
All right.
And once we go again to Branch C, look at this line right here.
But you see it returned to the new line we have added.
Now let's go back let's go back to GitHub dot com to our repository.
And currently we are working on collections, dictionary basics.
And let's see the same thing right here.
So collection dictionary basics.
We are in our repository and I'm clicking on the file.
We've changed.
So in the main branch main, we're seeing here the last line print and I'll file once we are switching
to Branch C.
You can see that old line disappeared and we're seeing this line with a red branch, see?
All right.
So you can see the difference between these branches.
OK, so we have created a new branch here and we've made some changes on it.
But it's not the same as M. its main branch, main branch and this branch, see, are not the same.
There are some changes in Branch C that do not appear on the map on the main branch.
OK, this we already understand.
Now, going back to our slide and we can see here, developer AI could create his own branch, OK?
They both work on the own personal branches without interrupting each other while committing and pushing
through the orb to their own branches.
Once they are done and check their code, their branches should be merged to the main branch.
So basically what we're going to do is, is to take these changes that we've made on Branch C and push
them, basically merge them into the main branch.
And how do we do it?
We go to GitHub desktop, we click on the central part, we switch to the main branch, which is the
default.
And then we opened this part again, and right here at the bottom, we can see choose a branch to merge
into Main, OK, we click on this part and here we choose Branch, see?
And then you can see here merge Branch C into Main.
OK, we're clicking on this part simultaneously.
Simultaneously.
Let me open pie chart because I want to see the changes happen here as well.
It's too small.
OK, we'll go back to that in a second, OK, so we choose to merge Branch into Maine and once we clicked
it, we can see here, push Oregon.
OK, so we need to push these changes.
All right, we're done now let's look at beachum, remember?
Currently, we are on the main branch and you can see.
This line would appear at Branch C, appears in the main branch, while a few seconds ago it appeared
only on Branch C, but now we have merged Branch C into Maine main OK.
We basically took this branch.
We open here and merged him back to the main.
And this is how version control works.
Basically, every developer can create his own branch and make his own changes.
Then then once he commits and push these changes into his branch after checking his code, he can merge
his branch back to the main branch, which is the default branch.
And it will always be the most updated one, the main.
OK, so all developers, like if you have 10 developers working on a single project, each and every
one of them at the beginning of the year, they should create their own branches.
For example, I'm working and Google and I'm working on developing this Google doc.
And my mission for today is to create the Zoom feature.
So I'm going to create a new branch in GitHub and call it Zoom feature.
I'm going to develop lots of code, going to write lots of lines of code and develop these for that
feature.
And after I'm done, I'm going to merge the code that I've wrote into the main branch so everybody else
would see my changes.
OK, so basically all developers work on their own branches and once they are done, they merge, they
branch into the main branch.
I think this summer's the GitHub and version control pretty good.
And now we can say surely that we have completed the GitHub.
By the way, this is advanced.
We have completed the version control topic.
Thank you and bye.