Okay, so today I'll talk about Git for version control. So here's the website. Basically the premise is when we write the source code, we eventually release a version and we compile that program and then distribute to the public at large and they consume a specific version of the software. And then we continue building new features and adding changing the code base. So the problem is how can we keep track of these changes? How can we like, okay, we release the version, we got the source code for that specific version. Now we add new features, meaning we change the code. So how can we keep track of, okay, we need to keep the old one and at the same time to give support to the users who are using it. And then we have to release new features. And then a silly way we could do is maybe you can copy and paste the code into different folders for different versions. But eventually that doesn't really scale, it gets really messy with time. So that's why they developed a source of version control programs in the beginning, something like CVS, SVN, that kind of stuff, Mercurio. And then the most popular today is probably this one that we're going to talk about that's called Git. And it's even spawned industries like the company GitHub, GitLab, Atlassian, and so on. Yeah, so we'll start off just by learning the Git command. It's a program that we use on a command line, and we're going to learn the basic commands. So let's jump to it here. Make sure you have a terminal. And I usually like to namespace my file structure with my ownership. In this case, this is my username as it's found on github.com. So I usually am inside there. And then I can create my projects here. Now let's suppose I create a new directory with the command mkdir. And let's call it introduction to Git. Now I'm going to use two because I already did this before. So you can use any name you want. And then I'm going to change directory CD, introduction dash to dash Git to. Now it's an empty directory. There's nothing there. So I'm going to open my Visual Studio Code. If you have another text editor, that's fine as well. For me, it's the command code space dot, dot meaning the current directory. So let me share with you one moment, resize. Okay, share. So here it is. You got to get the directory. Let's create a like a text file, test dot txt. And I'm going to say hello world here. Just a simple message. Assume it's like a source code in the real world, but we're just keeping it simple and make a text file. So I want to keep track of the versions of this in this project, this directory. Like I want to know exactly with time what happened to the text file. Did somebody add something? Did somebody remove something? Who changed this line? Who changed this other line? Another great benefit of version control is you can keep track of the history of changes. A snapshot in time of every single change that was made. And you can look back. You know, it's very useful for like for me, when I was working for some company and they I need to develop a new feature, I thought about it, how am I going to implement this? Actually, this feature looks a lot like what we already have. So I'm going to do some research and look back in the history to see how these people made the decision for that old feature that we already have. So that maybe I can base off my own source code on that and hopefully improve upon that solution. And that's one of the benefits. Another benefit is if there is a bug or something crashes in production and nobody knows what's going on, you got to look at the history. Hey, what was the, what were the changes that happened between what we just launched and the previous stable launch? What changed? So you go there and see the history. Oh, you realize, oh, this was changed. And then you go back in history, you can run the program at another version and you see that the bug doesn't reproduce. And then once you introduce that new change, you see it reproduces. And then you conclude, hey, this change was the problem here. That's why it's crashing right now. Therefore, you can mitigate that and add a bug fix and so on. So that's a really great benefit of version control as well. Yeah, Lawrence said, who to blame and the code breaks. Yeah, it's called get blame. If you're interested, it's the way we use to find out who changed with blind. But yeah, in the typical company, I wouldn't blame other people. Try to just fix the bug instead of blaming others. But anyway, continuing what we're doing here, going back to command prompt. Yeah, blameless root cause analysis. Yeah. Any quotes. Any case. Yeah, so if I go here, let's track the changes in this project. So in the world of git, we call this directory a repository. So we want to initialize a repository. To do that, we call in the git command in a command line space and init initialize. So if you do that, it's going to say initialize the empty git repository at this location here where we are. But actually, what it does is create this directory dot git. And on Unix systems, when a file starts with a dot, it's like a hidden file or directory. So that's why it's called dot git. Now, anyway, if you do a deer on Windows or LS on Mac or Linux, you should be able to not see it in my case, but there's an option to show it. In Linux, you have to say LS, I think dash A. I usually use dash LA to list in all. But in any case, let me show you that it's actually there either in my Visual Studio Code or my Finder. And let's see. Here is my file explorer and I go to my own and you can see it's here like hidden. All right, how's everybody doing so far? So good. Everybody got to get installed without an issue. I assume many of you already know some git. So let's see. So I just looked at the option here for DRR, seems like dash A is to show the hidden files on Windows. That's now, now I can see dot git there. Anyway. All right. So once we got that down, we can finally see what's going on here with git space status. And this will tell you if anything happened in the current repository. And you can see there's some untracked files. And the one, it usually appear in red, red color, if you can see the color, it's test.txt is untracked, meaning it has not been committed to the source control. So git doesn't keep track of that yet. So to keep track of this, you have to first, it's a two-step process usually. First you add that to the staging area. That's what they call it. And once it's staged, it means it's ready to be committed to the git history. So we can do git add, space and specify the files that are to be added, in this case test.txt. And then you can follow with a git status again to see if anything changed. Now you can see it says changes to be committed. And then you can see the command to undo that, which is to unstage. So first we place the file in the staging area. And then, okay, I think this is good to go. But you can always do a diff. I don't know what I changed. That's one question you could ask. And I didn't do that before, but that's a command called git diff. But since I already added to the staging area, I cannot see anything, but I would have to add the options dash dash staged, because that means what's the difference between what's been staged and what I had. And you can see I added hello world. In any case, once I'm ready to commit this, I use the commit command. And it's going to, if you do just like this, going to open some text editor that whatever is the default, and then it's going to ask for a description of the change. But before we do that, we have to set up our git to know who is doing what. So I don't know if you already did this, but we have to make sure to tell git who we are. So the typical commands we use for that is this one, a piece of the chat. And then the other one is let me put it in your window here. One moment introduction to get to this one. So those two, if you haven't done this already, you can do it basically called a git command config, and then dash dash global space user dot name and quotes, double quotes, put your name or nickname or whatever. And then after you press enter, that's going to actually change a file called dot git config in your home directory. And that's one way you can check if you already have set this up. I'm going to open my percent user profile slash dot git config. Now I'm on Windows right now. So if I want to go to my home directory, that is c, colon, backslash, users, backslash my user name backslash dot git config, I can do it with this environment variable called percent user profile, all in caps percent. And that should open mine. If you are using a Mac or Linux in Mac is slash users, if I'm not mistaken, slash your username slash dot git config. And this variable here, you could use as dollar home or the tilde. So you could do that on Mac or Linux for Linux is usually slash home slash or user name slash dot git config. In any case, that should be in your home directory. If you haven't found that, let me know. So I opened that in my home directory here. And you can see if I looked for the line that has a brackets square brackets user, that means I already set up my name and email if I see them here. So that command that we use git config, all it does is set these values in this file. Of course, we could have opened this file manually, even if it didn't exist, create one, and then just write brackets user, and then break a line and add name equals whatever value and then break a line email equals whatever your email is. This works the same way, all right. And like I said, after I do the username, I would do the email like it typed here. Let me know if you have any trouble so far. Okay, I'm assuming everybody is okay so far. Okay, so with that, we can continue with the commit. Remember, we first added to the staging area with git add. Now we are ready to commit with git commit. Now I usually like to type the message right away in the terminal instead of having to wait for the text editor to open and I can type the message. I usually follow with the option space dash m, which stands for message, and you can describe whatever in quotes, in double quotes here. Let's say add dash dot txt hello world message. Usually you want to describe what you changed, for example, add a function to calculate something or fix bug that caused the production to crash, whatever, something very descriptive. So try to be descriptive yet brief. So once you press enter, that is committed to the history and it's called a commit and you usually get this hash, what we call a hash. It's like a code that every commit has and if I do a git space log, I can see the history, what happened. And this one only has one commit and you can see commit followed by its hash or you're also going to hear the word a shah for this kind of code here. It stands for secure hashing algorithm. It's a way of creating this thing, but it's also used as a word for that, all right. And it tells me who did it, like me. That's why it was important before we did this to set our git identity with the git config dash dash global command and then the date and then the commit message here. So then let's say we come along and we change something. We change hello to planet and then we go back to the terminal. Now we can see that we got some changes, not stage for commit, meaning I modified here the file. If I want to know, okay, what did I modify gets the difference. And it will tell you with the minus meaning remove line plus meaning add line and usually the minus is in red color and the green, the addition is in green. So you can see I changed hello world and I replaced with hello planets, but in practice I only changed the second word, right, set a world, it's planet. Okay, if I'm satisfied this, I can do that two step process. I can do git add test dot txt because I want this to be committed, add it to staging and then if I do get status again, you're going to see it's now changes to be committed to become green and I can finally do git commit again and I can say change world to planet, my description of the change and enter do a git log. I now see that the top one is the latest thing that I did. Here's the shot or hash for that commit and who did it and the description. So as you can see as people, different people make changes to the code, it will build up and pile up lots of changes to the history. So you can see this becomes very useful to look back as you have many people working the code, frequent code changes, you know, you want to find out some some issue that happened, like I said before, always look back in the history also useful to build new features, look back to see how people have done it, analyze. Maybe you think this part of the code is very weird. Why was it written this way and you can look back in the history and see why did they make that decision? Are you understand? Oh, they actually wrote it this way because they couldn't do it in a certain way. They had to decide it this way. And if they didn't have that problem, they'll probably do the way I was thinking, but unfortunately they had this thing blocking them. So that's why they did it that way. So it's important to understand how decisions were made over time in the source code. How's everybody doing so far? All right, I'm assuming all is good. Now, you might be wondering, what if I forget all of this? Well, you can always get help. If you're on the command line, you can type git dash dash help, and it will tell you a bunch of commands that you can do if you forget. And each of them have their own help. Now the way is if you go to the git website, they also have documentation. Let's share the browser. Where is it? Share. This is the website, git dash scm.com. Click documentation. It's the slash doc, or docs, I guess. Yeah, this becomes docs when I click reference. And you can see the reference of all the commands, and you can see we did init. We did add stats, status diff commit. And we did help. And there's a bunch of other ones. Okay, now there's one thing I didn't mention yet, and that's about the branching. Going back here to the terminal. If I type git space branch, it will tell me what branch I'm on right now. And usually there's a default branch. Branch is like, it's useful because let's say you have the source code at certain point in time, and then you want to build a new feature. But if you start building the new feature, you're certainly going to break the stable application as it was written. So what you do is you branch off into a different set of history timeline so that you can work on additional features without affecting the main timeline. So the main timeline is always stable, and you branch off, and you write new code that's not yet merged into the main timeline. The main timeline is kind of in the has its own source code in a certain point, and then you build a lot of new code. And then once you're done with the feature, you know it's not going to cause any problems anymore. That's when you go and branch, you go inside and merge back into the main timeline. That's the point of branches. And maybe the most popular way and very simple way of doing branching is you create what are called feature branches. So you are in the default branch, you branch off to what's called a feature branch, because that's supposed to be something that you're working on a new feature. And then once you're done with that, you have all the code that's necessary, you merge back that new code into the existing timeline, the main timeline, and then keep going like that. Different people have their own branches and branch off and build their own code. And once they're ready, they merge into the main timeline. Now my branch here is called master. That's the default branch that I have in recent years. This has been renamed to main. So keep that in mind. If you don't see master, you're probably going to see main. And the star means this is the branch I'm currently on. If you want to branch off to another branch, it will put the star something else. So maybe we can do just an example of how to branch off. So make sure you're in the branch you want to branch off of. In this case, the master, there's only one. So you're going to do get check out dash B. Yeah, I know it's confusing to people. Why don't we use the get branch command? Just the way it is. It's called check out. You want to check out a new branch, create a new branch, you have to use the dash B. And then you can do, you have to name a branch. Usually it's the description of the feature. Maybe let's say add new sentence. How about that? I usually like to name my branches separated with a dash in all lowercase, but you might see other people naming it differently. That's just my naming convention that I chose and adopt. They get simple and easy. So I press enter and you can see switch to a new branch add dash new sentence. And if I do get branch, I am in add dash new dash sentence. Now I have branch off the main timeline, the master one. And I can start adding code here, making my changes. Let's say I go to visual studio code and here's the new sentence in the second line. And I add a line break there. And then once I wrote that, I completed the feature, wrote out a code, all is good. I can go here. And actually you can, you're going to have many commits. So as you're building a new feature in the feature branch, you're going to make so many commits and let's say I do get status, I have the modification. I can do a get diff to see what has been changed. I can do a get add to stage that and I get status again to see that's now changed. The changes are to be committed. I can do the commit and let's say add second sentence, enter. I do the get log. You can see we got one, two, three commits. And just as a demonstration to show you that this branch is in a different timeline than the other one, I'm going to go back to the master branch. To go back, I use get check out space, the name, in this case master. Switch to master branch. You can see here. Now if I do get branch, I'm a master right now. That's the main timeline. Now if I do get log, watch what happens. I only have two commits. I don't have the one that adds the second sentence. See that? That's important because the main timeline is supposed to be a stable version that does not yet have the new code we're working on in a different branch. Okay. To go back to my feature branch, I can simply do get check out now add dash new dash sentence. Notice I don't have dash b because I'm not creating a new branch. It already exists. Now if I do get log, I'm now back. I have the add second sentence. Commit there. Okay. With that, let's go back here. Get status, nothing to commit. So I will keep going working on this, building the feature and so on. Maybe I can do one more just for the sake of another one. Save it. Now I have three. So I'll go back and I get status. Now I have something else. Now I want to teach you something interesting about get. It's the get add dash p. I like using this a lot because every time I want to add something, I want to verify what exactly changed and of course I can do get diff and then do a get add. You can do it all at once. If you do get add dash p, get space add space dash p. This is very neat. So it tells you whatever was changed currently. Now if I do it without any file, it will look at everything in the current directory. So make sure if you're working multiple files, just put the file name there. Anyway, it's asking you, do you want to stage this? It's telling you I added this another one. If I want to stage that, I press Y, which stands for yes. And there's other options there. We don't have to know it right now. But most of the time you just say yes or no, or Q to quit. If you want to cancel this, Q to quit. But I want to say yes, I press yes. So what happens is it stages that for commit. And at the same time, I could see the diff. So I find that very convenient, get add dash p. Okay, it's stage for commit. We can do get commit dash m, okay, add a third sentence. Now get log, we got two extra commits on top of master. Now once we're done with this, let's say the future is built. I can go back to master. Okay, make sure you go back to master. Now I'm going to merge the changes for my feature branch into my default branch master. To do that, I can do get merge, space, the name of the branch. In this case, let me check the get branch, add dash new dash sentence. So get merge, space, add dash new dash sentence. Oops, they'll make a typo here. So you see what happened here, fast forward updating. So now if I do get log, by the way, I'm in master right now. Get log, I now see the two extra commits that were part of my feature branch. So now that the merge is done, we should clean up the other branch because it still exists, you can see here. It's still there. So we can do get branch dash d with sense for delete. Be careful of this, okay, dash d. Don't delete master. Anyway, add new sentence, that's the feature branch. We already integrated those changes into master. So we are safe to delete it. Now to see deleted branch, add new sentence. If I do get branch again, it's gone. So make sure to clean that up whenever you merge your changes. Any questions so far? Okay, I think we're good to use GitHub now. Now, Git as a program is usually done for the command line like this, but what really popularized it was GitHub. You know, they built a whole companies around this program. So GitHub is pretty much like the social media of coding. They made collaboration and socialized coding. So if we go here to GitHub.com in the browser, if you register an account and everything, you can explore different. So basically, you can host your source code there and it's very popular for open source projects. Open source is like anybody can see the code and propose changes and collaborate on it. It's different from the closed source where you can't see the code. You only get the compile program and nothing else. You don't see how it was written. So if you have anything, it's a lot of interesting stuff here from many different companies. If you know Discord, here's one specific repository that works with Discord and you can see here's the source code. And there are different features built into GitHub. Like you can create issues. It's like a task management, project management for things to do. You can create a new one, report an issue or ask a question. Recently, they added discussions in recent years because people were posting a lot in the issues. So they decided to make discussions. Now, there's this thing called pull request. That's basically proposing changes to the existing code. So you as an outsider can propose changes to anybody else's code. That's open source on GitHub. So if you find a bug or you want to add a new feature to an app or application that you really like, you can do that if it's open source. And there's other features built into GitHub. But most of the time, click the code here. This is where you see the source code. That's what we're going to focus today. So I want to be able to take my code here that's local in my file here, repository. And we're going to push it to GitHub. That's the name they use, push, get push. Basically, GitHub is like a centralized location for the source code that's open for everybody to see by default. You can also have private. Many companies, they operate in private repositories that only the company employees can see it. That's also common. They usually call that practice inner source, which is like open source practice and collaboration within the closed setting, the inner company context environment. Anyway, how can we do that? Well, we have to set up what's called a get remote. Now, to do that, first, you got to go to GitHub after you created your account. You're going to first go to your repositories. There are different ways to accomplish that. You can click this hamburger menu and click, where is it? I think repositories here, but maybe click home. And you can see your repositories and click new. Or you can go to your top right and choose your repositories. And you can click new. Now, I'm going to click now there. So I'm going to ask some questions. For example, who is going to own this? You can click this dropdown and choose if you have a different user or organization. I'm going to just keep it in my personal username, slash, then the name. Usually, the name is the same. I like to name it the same as the directory I had locally, but it could be anything else. Introduction dash to dash get two, because I already got the one without two. And if you want to add a description, that's fine. I don't need it. I'm going to choose public to make it available for everybody to see. You can choose private if you want. And there's other options that I really care right now. So I'm going to click Create Repository. OK, now we created the remote in GitHub. Now we've got to push the code here. Now there are different ways. There is HTTPS or there is SSH. Now, if you haven't set up SSH, you have to do HTTP. Copy this link here. And we're going to do what's called, I'm going to add the remote. So let's go here to the terminal. So if I do get remote dash v, there's nothing, meaning there's no remotes. So I have to do get remote add. And then you have to give it a name. Usually, it's called origin. And then you paste that URL if you do HTTPS. Now, if you do HTTPS, it's usually going to ask for authentication. I already have SSH set up, so I can use that instead. Let me go here. If I click SSH and copy that, that's what I would use instead of this HTTPS here. I can go over setting up SSH that is desirable. Let's see. But we've got to take a pause for a good remote. So SSH is basically another way of authenticating. What we do is we create what's called a key. There's the public key and private key. And that can be used to authenticate automatically so we don't have to manually type your logging or access token on GitHub. Usually, I think these days, it opens a browser window, and then you've got to authorize that kind of stuff. So if you don't want to do that, you can set up SSH. Let me give the command here. So SSH key gen is the command we use. So I'm going to put this on the hold and open a new tab while this is on hold. And you can do it from anywhere. The command is called SSH dash key gen. Let me paste it to the Zoom chat. Space dash d, space ed25519. That's the recommended one these days. Space dash capital C, space double quotes your email, and then close double quotes. Now, if you've already done SSH, you probably have one. To find out, it's usually placed, if you haven't changed the default settings, it's usually placed in your home directory. If you look for dot SSH directory, you should have something like id ed25519 and id underscore 25519.pub if you chose the default settings when you created the SSH key. But if you put it somewhere else or chose a different name, then I don't really know where it is. But that's where it usually is. Your home directory slash dot SSH directory. So that's one way you can find out if you already have it. Or if you just try to add the remote and this push to get hub and if it works, that means it's already there, set up. Anyway, after you create your own SSH key, let me just for the sake of example, create one here. Press enter and it's gonna ask where do you wanna save it. And I don't wanna do it like this, but usually I'd press enter without changing it because I already have one. I'm just gonna change another name, another name. And then enter a passphrase if you want. I can leave it empty. Enter a same passphrase empty and then it creates one. If I didn't put another here, I would be created like I said, in dot SSH and you got it like a private key and the public key. The public key is the file with the dot pub extension. Okay, once you got that, I think the another is in this. You see another, another dot pub because I put a different name. So basically you can do what you wanna do is take the public one, the one dot pub and we're gonna copy that, the content. It's just a text file. I can use cat or type another dot pub and just copy this. Okay, or you can open a text editor or through file explorer, whatever you need to get the content of that file. So after you get the content of that file, go to GitHub. In the top right, click your avatar, click settings. And then you're gonna go to SSH and GPG keys. And then you're gonna click to add, let me see here, one moment. And a new window. Gonna click to new SSH key in the top right and it should go to this page here. I'm gonna paste in the zoom chat. And then you just paste whatever you copied from the dot pub file, paste it here, give it a name, maybe my user at my computer name. So you know exactly where this is from. So otherwise you won't know where's this key from. So make sure you give it a good title there. And then you click add SSH key. So what this is doing is GitHub is receiving your public key so that it adds to the list of keys that they will use. If you try to send your code to GitHub, GitHub will see, oh, we got your key here. I recognize you. I'm gonna, you know, unlock. That kind of stuff. Okay, with that, I hope everybody either has a key or hasn't, if you haven't been able to get one and set up on GitHub, let me know right now so we can debug it. Okay, otherwise I'll keep going, okay? Anyway, going back to where we're at. Here we, the code introduction to Git. You can click at the dot, the SSH one and copy that one. A user starts with git at github.com. So going back to the terminal here, we can continue with the Git remote. Remember, we were trying to add a remote to our local so that we can push to GitHub. Going back to my tab in the terminal where I had git remote, space add, space origin, origin is usually the name we give. And then the SSH URL. And I can press enter. If I do git remote dash v, enter, you should see two entries, one for fetch, one for push. Now dash v stands for verbose so that we can see the entries. If I don't do verbose, it appears like this. Only origin, which is not useful to me. Nada asks, each time I create a new project, do I need a new SSH key or can I use the same SSH key? So you don't need to create another one. The SSH key is a general thing, meaning you only have to create it once and then you will go to GitHub and add the key there. And once you've got there, you don't have to do anything else. Every, any repository that you have, it's always gonna work. So long you're using the same machine to push or fetch code. If you have a different machine, you would have to create another key and add to GitHub. So basically it's a per machine, different computer. All right, so now that we got the remote setup, we have to push, you see this terminology. Push means sending the code, it's like upload. Fatch is like download, you know, grabbing the code into our local. So we can make a distinction where we are right now, machine is a local and GitHub's a server somewhere else, computer somewhere else, called the remote. So we're gonna do git push. Now, because the first time we're doing this, I usually do the dashu option to track it, the branch, and then the origin, which is the name of the remote, and then finally the branch. So what that's doing is, okay, git, I want to push and please track with the dashu. It's the remote origin and we're pushing the branch master. Once we do this, you can see branch master setup to track origin dash, slash master, that's the point of the dashu. So that way we don't have to always have to do origin master every time you push, git push origin master, git push origin master. We don't have to do that, you can just say git push and it automatically knows it will go to origin. Okay, going back to GitHub, you should see if you refresh or reload the current page. Now I have my file here and my commits. So in the GitHub interface, you can see the file browser explorer here, click the file and there's the contents. And you can remember how we talk about blame, you can click this blame function, that's basically using the command git blame to see who changed what, every line, who changed that. You can see line number one would change by me and the commit was this one, change world to planet and the second one and then the third one. And what's nice, you can click this and it will point you to the commit. You see in the URL commit slash the hash and it tells you the change before and after. Now this is called the split view. If you want everything together, you can choose unified view here, so it's one thing. Okay, I'm gonna change back to split view. And it also, you can click to ignore white space and if you have lots of changes that's just changing the white space that might be useful to you to see what's going on. Anyway, going back, if it lets me, going back to the code, you can see here, there's this icon of the arrow kind of clockwise, that's where you can see the history of commits. This is like the Git log in the command line. So you can see every single commit here and you can click them like we did before to see what the change was. Okay, this one, this commit, I added the second sentence and then go back and take a look at the other ones. Nice. So that's basically GitHub. Now, let me show you how you can push new code. Let's say I'm in my local. First, let's do fetch because, you know, let's say we are in this project and there's many people working on it. Somebody came and added something new. Let's simulate that by using the GitHub interface. I've got to go here and I'm gonna click to edit this file. We can actually add it through GitHub. That's basically doing all the Git commands through the browser in the back end. So let's say fourth sentence here and I click to commit, make a commit. Remember, this is like doing add and then commit and this is my commit message and you see commit directly to master branch. And now I have the fourth sentence here but this is only on GitHub. This is to simulate somebody else making a code change, emerging their feature. And you can see in the commits, we have the update test here. That's the one with the fourth sentence. Now, if I go to my local, I get log, right? I don't have that. And if I do cat or type the content of the file, I don't have the fourth one. So how can we integrate the remote changes into our local? Well, that's usually called either get fetch or you're gonna see a pull which is like fetch and merge. Okay, either way, get fetch and get merge or you get pull. I'm gonna do, I usually like to do fetch. So I do a get fetch to bring, okay, I'm gonna download the latest changes from the remote. And now that I have it, it's not yet integrated. I have to do get merge. Okay, if you notice this origin slash master, that's like the remote master. We just updated that, but our local master is just called master. So that's why here we usually do origin slash master, which means we take the remote master, which has the new changes and integrate into our master. Make sure you are in the master branch, by the way. I'm doing, let's do get branch to confirm. Yes, I'm on master. So I'm gonna do get merge, origin slash master. Okay, don't forget to slash. Origin slash master is one thing and it means like the remote master. Now you can see fast forward, this file was, something that was added. And if I see the content of test.txt with either the type in Windows or cat command for Mac or Linux, I see the fourth sentence there. Okay, so that's the fetch, bringing code and integrating for the remote. Now let's do the opposite, which is push. We already did push before, right? Remember when we push this to GitHub, but just for the sake of doing it again, let's go to VS code, have a fifth sentence here, save it, go back to command prompt. Remember, get status, get add test.txt. Important to add this here, instead of the current directory dot, because I have other files. I don't want to commit them, so be careful. Don't just use get add dot. Anyway, get status, I can confirm only the test.txt is to be committed. Commit, add another sentence again. Okay, we got it locally, but get log, add another sentence again. This is not on GitHub, not on GitHub yet. If I go to GitHub, click code, click commits. It's not here, I don't see it here. Okay, now let's go back to the terminal. Now, I press Q to quit, by the way. If you do get log and it's, now there's too many commits, I press Q to quit if you see this colon prompt. Okay, I'm gonna do get push. And if I, remember I do the tracking with dash U, so I don't have to do the origin space master. There you go. Now, if I go look at GitHub, refresh, I see another sentence again here in my commits. If I click that, I see my fifth sentence. If I go back, go back, look at my file content, I see it's there as well. All right. Yeah, so that's get at GitHub.