Today, I'll talk about version control, and why do we have version control? Well, maybe you have used Microsoft Word or an equivalent on Google, and you're writing an essay or something. If you ever use that feature revisions so that it can look back at past versions of your document, that's precisely what GIA is for. It's for version control. So basically, it's a program that we use so that we kind of take a picture of the source code, a snapshot in time, what it looks like. So as we go programming and adding new source code, changing, subtracting, we're going to take a snapshot, and we're going to call that a commit. So through time, we're going to have many commits, and that will be the timeline of your repository. That's what we call it, the project that's managed by Git. And basically, it has so many useful features. Maybe if it's your first time hearing about Git, it might not be so clear. So basically, for example, you build a website, you have a web app that's running, and you have a team of people, developers, and then there was a slight change to the source code that made the app crash in production for everybody. Now everybody's panicking, nobody knows what to do. What happened? Why is the app crashed? And a very easy way to roll back is just go back in time to a different version in the past because your version control everything. So you're going to know, hey, if I look back at the latest thing that I did, what was it that caused the bug to crash the website? So I can see there, and it's registered. So I can quickly roll that back. And other features useful to you could be maybe you want to look back at decisions that took place in the past to understand either in form going forward or just to understand what you're going to do. For example, I want to know, why is this code written this way? Why is the product has this following feature, which is very weird? Why didn't they think this other way? And they can look back in history and see their decisions. And you're going to understand, oh, actually, they thought that way, but they opted to go in this other way because that problem, that problem. So you can understand how the source code changes and evolves over history. So so many useful features, even if you're a developer, maybe you're a beginner developer, you are stuck. You don't know how to build this feature. What you can do is look back in history and see how people did a similar feature. And then from there, you can just base your solution off of that. So that unblocks you. All right. So enough of that. So we're going to need the Git program so you can download from this website, git-scm.com. And while you're at it, also you want to register an account of git-hub.com as well. Anyway, many people already have Git installed. So if you want to check if you have Git, all you got to do is go to a terminal and type git-git-v. And you should see Git version there if you already have it. My case, I have this version 2.41.0. Okay. So what I'm going to do is create a directory in my file system. I'll call it introduction-2-git-4. I call it 4 because I've already done this before. So it's just a directory somewhere in my file system. And mkdir is to make directory. Now I can cd to that like this and I can open my Visual Studio Code of Codespace. Okay, I just have a terminal window. If you're a Mac, it just can go and open a terminal. If you're a Windows, either a CMD or PowerShell or even Windows terminal will do it. On Linux, it's terminal as well. Okay. Okay. Now with that, we have to identify ourselves to Git if it's your first time ever using it. So let's type some commands to do that. I already have my VS Code open that's why I didn't run that. So basically, you're going to call Git space config, space-global, space-user.name, space, put some double quotes there and type your name or nickname or whatever, okay, for example, my username, GitHub. And that's your first command. Let me paste that to the Zoom chat. So basically, you have to let Git know who you are. And the first thing is your name. And then once you type that, I already have it, so I don't want to do it again. You're going to do the same thing again, git config, slash, slash global, user.email instead of user.name. And then double quotes out of your email there. Or you can add your no reply if you have a GitHub account. Let me copy that to the Zoom chat. Basically these commands basically, they change the content of a file called the git config file that lives in your home directory. If you're on Windows, that's your user name, slash, git config. If you're on Mac, it's slash, I think, users, right, slash users, user name, git config on Linux, slash home, user name, git config. So basically, if you do a DIR of user profile or your tilde or dollar home on Linux and Mac, you should be able to see a git config file. Let me show you graphically what it looks like just out of curiosity. As you can see here, I have a file dot config, git config, and that's pretty much what that command changes. So if you want to do it manually without going through those two commands I told you, you can just edit this file in your text editor. So long you know exactly the pattern that it wants you to type. Okay. So with that out of the way, you can go back to the code. Here I am in my folder open in Visual Studio Code. So I'm going to demonstrate how to use git to version control. And let's suppose I have a file, text file, call it task.txt, I have some message here. Save this. So how would I go about version controlling this? So I'm going to open a terminal in my VS code, control, back tick. This one is PowerShell. Let me open CMD, it's simpler. You can choose here. If you've never used this, you can click here to choose your shell and you can add more plus and trash to remove it. Anyway, so first you've got to git init. So you've got to let git know, hey, I want to keep track of this directory. So can you initialize that as a repository? That's the term that's used. And you can read here, initialize empty git repository. So all it does is create a directory, I think I have to put that, yeah, directory.git in the current directory. It's usually on Linux systems, . as a prefix to a file or directory means it's a hidden thing. It also is considered a hidden in Windows now as well. If you want to LS on Mac or Linux, it's LS, I think, dash A to show hidden files. I use Windows right now, so it's dir slash A. Okay, so that creates that directory. We don't have to worry about what's inside, git will take care of that for us. So all we've got to do is type interface through git. So we have to understand the concept of commits again, let me annotate. So basically what we're going to have in git is a timeline. So let me write a timeline here. So we're going to get time, okay, this is a timeline, t. So over time, we'll be making changes to our code. So let's say I added this file. So what we do is what's called a commit, which is a snapshot in time of how the source code was. So we usually represent that with a circle. So let's call it a commit, okay? Let me type the name here in case you don't understand what I'm saying. It's called a commit. But yellow. And then, okay, let's say I add this file, I'm going to commit it, and then I create a register in history at that point in time, me added hello world to this file. And then over time, you're going to have many code changes. Could be another file, somebody changed this file, added something, removed something. So you're going to generate a lot of commits over time, okay? So that's another commit, another commit, another commit, and so on and so on. Now this timeline is called a branch, okay, branch. Let me write it for you here. Branch. And usually we have a main timeline, and that's called either the main branch or historically we used to call it master branch. Now they change the name to main, okay? So you're going to see that a lot, main master branch. And then what happens is this main branch usually is kept, depends on how people have different ways of working with it, but one of them is like this. The main branch is the default branch that everybody is, the code is always stable, there's no bugs, there's no problems. So that's the one running production right now. And then we're going to have developers adding new features, but if they were to change the code right now using the main branch, they could cause problems, right? Bugs, introducing bugs, we don't want that to be manifested in production. So what we do is we separate the timeline, so every developer is going to have their own timeline. And to do that, they create their own branches, that branch off of the default branch. So we're going to see the terminology. For example, I'm working on new feature, I'm going to branch off into my own timeline. This is me, me branch, okay? You could call it whatever, it's called usually a feature branch. And in that timeline, I'm going to create my own commits, and I'm going to create changes to the code, but you can see that's not reflected in the main branch yet. That's the whole point. You want to isolate those changes so that the main branch, the stable one, doesn't get broken. So what happens is when you complete all your features work, what you do is you take all of those commits and merge them back into the main branch. So you're going to merge your feature branch into the main branch, okay? So that's what's going to happen. So we're going to take this and merge back. The moment we do that, we're going to move all these commits to the main timeline. So now it has those changes, and then it applies to production, and then the new features will appear to all the customers, the users, okay? So this is the typical flow for Git. Now let's demonstrate how to do that in code. Let's go. So I added a file. This is the first time I initialized the repository. So the process of making a commit is a two-step process. First you've got to Git add, and then you Git commit, okay? So this thing calls a staging area where you first have to move things there, too. So you're going to do Git add, and then the files you want to add to the staging area. So let's do test.txt. And that's been added to what's called a staging area, but you might ask, okay, how do I know what the heck is going on? What if I forget about this? I come later. Well that's when the Git status command comes handy. So you're going to Git status to see what's going on right now. Okay, do we got any changes? What's the deal? So you can see I have changes to be committed. I have a new file test.txt. Okay, now I know what's going on. Now the second step of the process is actually making the commit. So we're going to do Git commit, but if you press enter right now, it's going to open the text editor and ask for some description. Okay, it opened a new file there, so I got to describe your change. It's called a commit message. So typically we want to be specific about what we did. For example, add hello world message to test file, something like that. So you want to be very descriptive of this description because you want to look back. When you're looking back in history, maybe you caused a problem, right? I remember production just broke and I remember the last thing we did was adding this new feature of chat feature. So maybe you want to look in a history and search the keyword chat, but if you don't have a good message, you will not find it easily. So that's why it's very important to describe exactly what you did. Very specific, but you have to be short, right? This shouldn't be something very complex. If you do have something really like, you need an explanation why you did this and that and that, you can always, I suggest you break two lines and then you can add longer description here. So you can write a story, okay, I tried this and then worked. So I had to do this because of that and that. Usually that's what happens, okay? This case is very simple. I don't need a longer description, so I just add one single line. So I can control S to save and I'm going to close this and then it finally makes the commit. Now if you're using Linux based or Mac, I don't know which text editor is going to be open when you get commit. If it's VI or Vim, and you don't know how the heck to get out of it, you have to press colon, sorry, colon to open the menu to type a command and W to write and then Q to quit. Write means save and Q will exit, okay? If you gather yourself in that situation to know what's going on, just press S, escape, colon, W, Q. But this one will save, okay? If you don't want to save, remove the W. That was just usually like Q, exclamation will save without changes. All right, so with that out of the way, this commit is now in the history. So you can see the Git log to see what's going on. We have one commit and you see there's this code here called a hash and there's an author, which is me, with my name and email. This by the way is what you typed when you first identified yourself to Git using the Git config command. And the date of when this was performed is and then the message. So you're going to hear the term SHA or commit hash a lot and that's this code here. Every time you commit, it generates this code, which is like a points to that commit, okay? So if you hear SHA, which stands for secure hashing algorithm, it's basically this or Git hash, okay, commit hash, and you can see this head here is basically pointing, it just means that the head of in history is pointing to this commit and it's pointing here to the master branch. My Git version is using master, yours might say main, okay? That's the name of the branch. Which by the way, you can see if you type Git branch, what timeline am I in? I'm in the master one, okay? So you might hear terms like trunk, main branch, default branch, it's all pointing to this. Okay, great. Now how do I make another commit? Well, you're going to go about your work, do whatever you need to do. For example, I'm going to replace world with there. I save it. Now I know this file has been changed. I can check Git status and I see modified text, that's that the XT has been modified and you see not stage for commit. That means it's in what we call the working area, okay? So remember, it's always a two step process. So right now it's not staged. So to stage that, you have to get add file name. Now if you do get status again, it's been staged, so changes to be committed. Finally, I can type git commit. This time I'm going to add an option dash M to show you that you don't have to use an external text editor to type your commit message. If you use the option dash M, you can type the message in line here in the command. Say replace world with there. That's my commit message. Make sure you put quotes there because you might have separate words, right, in space. And there you go. Now I can check the Git log again. I can see at the top, I have my new commit with a different hash and this one is the at the top of the master, right? The latest that I did, and this is the past one. So if I check it status again, there's nothing, okay? So if you add any new files that haven't been tracked before, Git will not know about it. So you have to manually add them the first time, okay? So be aware of that. So if I add a new file here, hello.txt, if I do get status, you're going to see it's not tracked, untracked files. So I got to follow the same process. Git add the file name, Git commit, add hello.txt, like that. And then I can see now nothing to commit and Git log, but tell me all this stuff. Now you notice my log has now become so long, it has kind of this prompt at the bottom. That's pagination. Okay, if I press up and down on my keyboard at the arrows, I can navigate. Now if you want to quit this, it's Q, okay? Press Q to quit. Q to quit. Okay. How's everybody doing? If you have any questions, let me know in the chat. Let me teach you a couple more commands. Let's say somebody comes along and, okay, we type a message here. And we change the file. Write hello.txt has been changed, we can check Git status. Let's say for some reason I don't have access to a text editor to see the file. Let's say I don't have a hello here showing, let's hide it, close it. How can I see the changes? Now you can type GitGIF to see the difference between the working area and the top of the branch. So you can see from the difference, the file, hello.txt, the plus means added something. Okay, added this line with testing. And then you can do Git status. Again, okay, I'm going to add, remember, two-step process. Add. Now, if you do GitGIF again, just to confirm, it doesn't work. Why? Because now it's in the staging area. So when you do GitGIF, you compare the working area with whatever is in the branch that the top commit. So if you want to do staging area to the top of the branch, you have to do GitGIF with the dash-dash-stage option, okay? Because you've got to compare from the stage area. Okay, that looks good. I'm going to commit. Add some text to hello file. And I tap fast. I press enter before I press my quotes, but it works anyway. If I do the log again, it's there. If you need any help, you can always do git-dash-help if you forget any command, and it will tell you all of the list of commands. Can also reference the website, git-scm.com, documentation, reference manual, and you can see all the commands here. For example, I want to know if you click there, it tells you how to type it and the description, some examples. It's very long, so. All right. And that's Git in a nutshell. You just always follow that same process. All you got to do is remember. Type it somewhere, and always, the more you do, the more you remember, so eventually you don't need to look up your cheat sheet anymore. Now let's talk about changing branches. Go back to VS code, like this one. So right now, if I do git branch, I'm in the default branch, master or main for you. Let's suppose I'm somebody who wants to add a new feature, usually you don't want to commit directly to master, unless you know what they're doing, but most cases as a developer in a team with many people, you don't want to do that. What we want to do is create a feature branch, work on our own features without breaking the main branch. So to navigate or create a new branch, you're going to do git checkout command with the option dash B. And then give it a name. Usually I like to name my branches lowercase letters, separate words or dashes. That's my convention. I think many people use that way. It's very simple. Let's say I want to add another file. So this my name of the branch typically wanted to name the branch after the future feature you're building or whatever you're trying to do. Switch to a new branch, add another file separate by dash. If I do git branch again, notice how the stars now next to add another file. That's because it means, okay, right now you are checked out. And your branch right now is at another file. That's what the star means. Remember this is a different timeline now. We have the master timeline branch. We have branch off of master. Remember where you execute git checkout matters, okay? Make sure first you know what branch you are before doing git checkout, a new branch. Because if you do it from another feature branch, probably making a mistake. That's very common for people to do. So first most cases you want to be sure you are in the default branch first. Git branch, make sure it's master there before you do the checkout to create a new branch. That way you branch off of master. Now we can start building a feature and just add another file, another .txt, hello. Very simple. Now git status, I can do git add, remember two step process. Git status again to verify and then git commit, dash m, add another file, okay? Now git log to verify, you can see my top is add another file. Now how do I go back to master or another branch? Git checkout and name of the branch like master. Remember no dash b or don't want to create any branch here. Now back to master, how do I know I'm master for sure? Git branch, check the star next to master. Now if I do git log here, watch what happens. I do not have that commit that we just did. Look at my files here, I don't have another .txt because it's in a separate timeline. Okay? So that's what's so great about git. So let's go back to the branch just to practice and press Q here, why it's not working. There you go. Git checkout, now I forgot the name of my branch, what do I do? Well, I have to do git branch again. And okay, add another file. Okay, git checkout, add, dash, another, dash file, switch to branch, verify again. I know it just there but just for practice. Okay, you see the file appeared again? It's back to the timeline. Okay, great. Now at this point, you build your future, you've got all your commits. By the way, you don't have to have only one commit, could be many, as many as you want. In any ways you want. People like, there are different approaches to how do I commit? Should I commit everything at once or should I do file by file? There are many approaches. Usually I recommend you commit often. And usually it's when you're finished building something significant. Like maybe I added a new function that does something. I can commit that function and say, describe, I add a new function to do this. That's a commit. And then I change somewhere, something, I can add another commit. So you can do incremental commits like that. Some people like doing everything at once. Like they build a whole future and they just make one single commit. I don't recommend that because let's say that feature took many days to build. And then if you don't commit until the end, you're not going to save all that code that you wrote all those days. It could be that for some disaster happened and you lost your computer and you never committed. So that means it's not in the record. So you cannot look back. If your computer was trashed, you can always get a new computer. And because Git, it remembers everything, you can always get downloaded again. And for that, we're going to learn about GitHub, which is the next topic. But basically, we usually have a central location or anybody else's. It's kind of distributed, but most people just centralized on GitHub. So in case your computer fails, you can always download it back from GitHub. So make sure to commit often. That way you always have the latest version there whenever, you know, in case something happens. And also it's good for other people to know that the code is right there. Maybe people needed to look at a code, what you're doing, that kind of stuff. OK, so in this point, how do I merge? How do I integrate my changes back into the main timeline? Well, that's called a merge. Now, usually we do that using GitHub via what's called a pull request. But for the sake of just using Git, let me show you how we do it here. First, you want to check out the branch you want to merge into. This case is usually master or main. So what I've got to do is I merge my changes from my branch into the master. So git merge, and then you've got to tell the name of the branch. So I'll take all the commits from add another file and then merge into the commits for master. Once I do that, I have my file here, nutter.txt. And you can see the Git log that commit is now present in the master branch. After doing that, we can clean up. If you do git branch, you can git branch dash d to delete the branch. Add another file. And then we delete it, you can check git branch again, it's gone. So we cleaned up. OK, so I always make sure to clean up after you merge your branches. I suggest you write, if you don't know these commands, write it down somewhere so you can always reference it, because people might be confused. Hey, why didn't you use the git branch command to switch? Why use checkout and all this stuff? So what is the dash d? What is dash b? Right? So to change another branch, I usually do git checkout. And if you need to create this dash b, and if you need to delete a branch, it's git branch dash d. All right, somebody asked, missed some commands, give me an overview. You know what commands were run, try to do my term. Yeah. So let me just give a preview overview before we go to GitHub. So basically, we created a directory somewhere on the file system. I called it introduction to git for. And to version control the directory, we do git init. Let me see if I can scroll up. There you go here. Right, to initialize the repository. So it creates the directory.git. So if you see a .git directory, a hidden directory, it means it's under version control of git. After that, we have to make changes or add new files. And we always follow a two-step process to make a commit, which is snapshot in time of how the code base looks like. And we basically do git add in the file name. And we check the status of git status to see what's going on, if always. And we git commit to finally add a commit with a descriptive message. Save it. And if you want to know about the history, git log. It will tell you how to commit history. Remember, each commit usually has an associated hash or shell that uniquely identifies it. If you want to know what branch you are, git branch. The star next to the branch name means this is the branch you're currently under. You have switched to this branch. And we learn how to commit with dash m. Basically, we don't have to open a new text editor window just to write the message. And I taught you git diff at some point to see what changes. Yeah, git diff. If you change anything at all, you can git diff to see what changes were there. And if you're comparing changes from the staging area after you did git add, you got to add dash dash stage. Otherwise, it doesn't appear. And I paste that to the Zoom chat. Let me see. So people can reference it. Hope that's useful to the person who asks. And then we learn check out to switch to a branch. So if you want to check out switch branch, if you want to create a branch, that's git check out dash b branch name. Let me type this switch branch. And then to merge into master, your feature branch into master, you first check out master. Then you get merge name of your branch. And finally, clean up with delete branch, git branch dash d branch name. I pasted it as in chat. OK, with that, let's do GitHub. This is all great, but then GitHub came along, which is basically Facebook of coding. What GitHub did was make it like a social media, where people can kind of centralize location, where they can showcase their source code and other people can collaborate. They can either comment on your code, they can add proposed new features or report bugs, and many, many other features now. It's grown so much. So create an account on github.com if you don't already have one. Once we're there, what we're going to do is, we're going to take the code that the repository we have, local, I'm going to kind of push that, that's the name of the term, to GitHub, so we showcase it there. So I'm going to do is go to my, I'm basically github.com, I can go, there are different ways to approach this. So I want to create a repository there, so you can click new in the top left here. You can go to your profile, and somewhere here, repositories, you can click new as well, but many different ways. Anyway, it's going to go to github.com slash new. So what you're going to do is choose the person under which this will be owned. In my case, I have my org, so I choose that. And then the repository name, I'll use the same directory name as I had, introduction dash two dash get four. And I'm going to make it public so you can see it. And all the other stuff I don't care about right now. Like create repository. So now it's been created. I have to kind of push the code. That's the name of the term get push. So there's some of the instructions here, if you ever forget. Now to communicate with github, there's two approaches here, HTTPS. And this one we kind of tedious because it will open a browser window and it asks for authorization, you have to click. And people usually do SSH. And with SSH, everything is done for you, so you don't have to worry about the authentication. Basically, what you got to do is you need to create two keys, public key and private key. So you give your public key to github, so it knows when you reach out, they will unlock and let you go through and upload the files. Now, how do I know I have an SSH key or not? So let me show you. Going to the terminal. So usually the keys are kept in a standard location dot SSH directory in your home directory. OK, let me open a new window. So my home directory windows is this one, which you can see from the variable percent user profile. Like this, you can see the value. If you're on Mac, it's either dollar home. Or tilde, that's the same for Linux, which is going to translate slash home slash user name of Linux slash user slash user name of Mac. So basically here, you can check if there's a directory dot SSH. So dear dot SSH, I have it. If you're on Mac or Linux, it's LS dot SSH. Or you can just LS dash L to see if you have it by eye. And this directory we're going to have our keys. Usually it's dot pub for the public key. And the other one is the private without the extension. So if you have this directory, usually ID, ED, 25519 dot pub, you already have a key. If you don't have a key, how do I create one? Let me show you how. I'm going to use the command SSH key gen SSH dash key gen. The option dash T, you got to choose the algorithm ED 25519. That's the now recommended one. And dash capital C quotes your email. And mail dot com. Let me copy and paste this so you can get it from the chat. If you do this, let me do a demonstration here. I'm going to rename mine because I already have it. So let me rename. You don't have to do this. True. Oops. Let me cd to that before. You don't have to do this. I'm just moving my file here to demonstrate. Oops. Okay, now that it's assuming I don't have it, I'm going to do the key gen dash td 25519 dash c capitalize my mail mail dot com enter. It's going to ask where you want to save the file. I just use the fault. Okay, I recommend you use the fault to express enter. Otherwise, it's going to be a mess. It's not going to work off the bat and you might want to debug and know where's your key. It doesn't know where it is. So just leave it default. If you want to pass phrase, you can do it. I don't usually do it. Enter, enter. And you see, it generated the file for the public one, which is dot pub. That's the one you want to give to GitHub. The other one is the private, you want to keep to yourself. And what you want to do is I'm going to cat. If you're on Linux or Mac, it's cat for man. And when does this type dot SSH, if you're not already there, and id 255.pub. That way, I can copy this content to the file. Basically, the type or cat command shows you, prints the content of the file to the screen. Okay, there you go. Somebody asked, who are the keys? What is ppk? You don't have to worry about that. That was just my stuff. That was my files. Yours probably doesn't have the files. Pub is public, correct. Dot pub is public. Private is the one without extension. Yes. For SSH, we always would get at as the user. Yeah, we're going to talk about that. That's yes. On GitHub, you're adding a remote. It's always get at github.com colon. Okay, so copy this, and we're going to go to github.com to let GitHub know about our public key, SSH key. If you don't already have this, okay, this is only for people who haven't never done this. You don't have it. Okay, we're going to go to click to your profile settings. And you're going to click SSH and GPG keys. Let me copy the link. You're going to do that. And then you're going to click new, okay? Let me do that here. Let me give you the direct link, by the way. You can go directly to that link on Zoom if you don't want to type click through. So click SSH, click new on the top right, and it should be here. So you want to paste that to the key here. And then give it a name that's so you can remember this. Basically, I always like to add my user, whoever, whichever computer, because there's so you could have many computers and different keys. I don't know where the heck this key is from. So I usually put my computer name, and usually the user, because there could be multiple people using the computer with different keys. So something like that. Me at my computer. And then click add SSH key, and get up, oh no, it's you now. I already have it, so I'm not going to do it. Okay, once you do that, let's go back to the repository. And what you're going to do, we've got to kind of upload this and get terminology as push. So let's go to the terminal. I'm going to go back to the, oh, actually let me go back to VS code, because I got a terminal there. So this terminal VS code is open to my project directory. And I'm going to, I have to first let get know what my remote is. When we have somewhere else where we want to keep the code, that's called the remote. Right now we are on local, right? How do I add a remote? Well, get remote, add. You get, you got to give the remote a name. Usually we call it origin, origin. Space, now you got to give that address that GitHub tells you in the website. If you go here and click SSH, okay, if you're using SSH, you got to click SSH. I got to copy this one here. Okay, it always follows the same pattern. If you do it a lot, you know exactly how to type without even copying that. So basically it's just this pattern of get add GitHub.com like somebody asked, colon and then owner slash repository name.get. Once you do that, you can verify your remote to get remote dash B which stands for verbose. You should see two of them for origin. One is for fetch, one for push. So fetch is like download, push is like upload. So when you need to get code, retrieve it from GitHub, your fetch, get fetch. If you want to send code to GitHub, it's push. Now right now we need to send code to GitHub. So we're going to do get push. So get push. Now we got to say what's the name of the remote origin? Okay, what branch? Master. Get push origin master all separated with space. Now, before you do that, if you want to be lazy, and the next time you do this, if you don't want to type origin master, you can just type get push. You can use the dash you option the first time here. That's going to track the branch. Okay, now it's giving me permission to deny it because my SSH key is not properly configured. Remember I changed my files? Well, let me change that back. Well, let me know if everybody got it right. If you got this error, that means something's wrong with your setup. Meanwhile, I'm going to go there and rename my files back. Let me see, not SSH. Here. Move ID. Move ID. Pub to ID pub. Move ID. To... Okay, move the files. Let's try again. Now it's working. I can see branch master set up to track, so the next time can just get push without origin master. Now let's see GitHub. If you refresh, you should now be able to see your files here. So on GitHub, there are many features. This is the files feature, our source code explorer. I can see your files, just like we did in our local file system. You can click that to see the content and it can browse through them here. If you go back to the repository, I can add a readme, if you got a readme file, it will appear here automatically. And some features you might be interested in is the commits, which is basically Git log. So GitHub is like a front, to be, it's like a pretty face interface to Git. Okay, behind the scenes, it's using Git. Okay, so if you want to see the Git log, basically the feature is the commits feature here, you can see all the history. You can even click each one of them to see what was done at that point in time. You can see this one, it will tell the changes before and after. There's two views, the split and unified view. Split view you can see before on the left-hand side and right-hand side is after. So I can see I added a new file with hello. If you want to see unified is like this. Let me show you a more useful one for unified. If you go back to commits view, I think this one replace world up there. This is before and after, you can see the red color is what's removed and then the green what's added. If you do unified, maybe you find it easier to see together like that. Okay, going back to code. So basically people will use GitHub, like I said, to collaborate and there are many other features. There's the issues feature, which is basically you can either track things you gotta do, maybe somebody can go and report on some problem. And then we got the pull request feature, which is basically we're gonna add, it's basically proposing new changes. Okay, if you have any new change you wanna propose, you would instead of doing that merge that we did locally, you would take your feature branch and propose the changes from that branch into the main branch here. And there's actions, which is basically continuous integration, continuous development. So you can run automated tests, you can run a lot of automated things, deployment, lots of useful things. This is very useful. Typically the use case is you submit a pull request to propose changes and then a lot of tests will be run to make sure you didn't make any regression tests, the regression bugs. Make sure your code doesn't have any problem and it's up to a code with whatever project requires for a quote quality. And other use cases are deployment, maybe when you merge into master, the main branch, that's gonna automatically trigger a deployment. You're gonna launch a new version of the product automatically whenever that happens. That's very useful, so many things. You can even use it for things not related to that. Okay. And there's projects, which is basically a combo board. You can create a board of things like columns to do in progress, done. I've usually used that for your standups when you work in a team to tell your teammates and the manager what you've been up to. And there's Wiki, there's some security tab for security related stuff. You can get alerts about using a version of software dependency that has a bug or has some exploit somebody found. And many other features, code scanning, secret scanning. Basically, if you put like a sensitive information in your code base, which you shouldn't do ever, never commit sensitive passwords and tokens, that kind of stuff. This will kind of scan for it and find that for you. And Insights is just kind of stats about your repository. You can see I'm the top contributor. Backlit contributors gonna crunch some data about it and some settings there. Okay, so lots of features there. Here, I'm the top contributor. Anyway, if you have a lot of people working in the project, you're gonna see a lot of people there and maybe people compete to be the top. Yeah, so that's GitHub in a nutshell. If you have any questions, let me know.