Today I will talk about version control with Git, and later we'll talk about GitHub for collaboration. So everybody should have Git installed, here's the website, once again, and register a GitHub account while you're at it. Anyway, what is version control? Well, we write source code as developers, programmers, software engineers, and we release many new versions of software over time, but how do we keep track of all those things? And not only that, I'm going to talk about later about other useful stuff about version control. Basically, a very naive way of keeping track of different software versions as you copy and paste and have different folders with different versions, but over time you're going to have so much duplicate code everywhere, and it's going to be really messy. What if you want to go back and fix a bug, but you have to go through every single version, you know, every single folder, there might be thousands of them, and it's a huge mess. So basically what people came up with, okay, if we're writing a document or any kind of text file, over time there will be changes, people will add some stuff, people will remove some stuff, something will be changed. How can we keep track of all those changes over time so that we can look back if we need? So that's where version control was introduced. Wow, there are many different programs that implement version control ever since many decades ago, but today the most popular one is Git. Of course, you can use other stuff, in the past they used to use like SVN, CVS, and all that stuff. Today maybe other stuff, alternatives to Git might be Mercurial or Perforce, and so on and so on. But Git is the most popular, and Git itself has even spawned industries like the company GitHub, GitLab, and many other stuff. So it's a really powerful tool. Now how do we go about doing Git? Well, let's focus just on overview before we jump into it. So basically what happens is with Git, you make changes to the code, and then you add to what's called the staging area, and then you commit. Commit is like a snapshot in time of that change. So over time you're going to have many commits, and then if you want to look back in time you can also do it, look at the previous commit and the previous commit to see how the code changed over time. Other benefits for version control is, for example, if you're going to deploy a new feature, and for some reason the application production breaks, what do we do? Well with Git you can always go back. Let's roll back or revert back to the previous version, and then deploy that so there's no more problem. And then you can also, it's helpful if you want to look back, maybe you're developing a new feature, and you're like a newcomer to the team, you're not very familiar with the code, maybe you could look back, hey, what if I look back and see how people built this in the past? Maybe I can base my solution off of what they did in the past to be consistent across the code base, so that's another thing that's useful. And so on and on you can go back in history to see, hey, something was changed recently that caused this bug to appear. What is it? Let's go through the history and see what people changed, and you can see there exactly who changed what at what time. So it's a really powerful tool. In any case, let's just jump right into it, enough of talk. So first you need a terminal, so open a terminal. In my case, I'm using Windows right now, so I'm going to use command prompt, but you can use PowerShell, you can use git bash if you're on a Mac, just open the terminal app or use iterm2. On Linux, it's just the terminal emulator, there's so many. Anyway, just have a terminal open, and I just had the git space dash dash version here because I was letting people know you probably already had git. So if you type that, you should see the version. So what we do is you go to a folder that you want to make it a version controlled. So let's say I'm going to make my, I have my username on GitHub here in a directory, so I'm going to change directory to that. What happened? I put a title, nbko. And I'm going to make a directory here under my username, directory, I'll call introduction dash to git, and because I already have others, I'm going to do three. And I'm going to cd to that. And this would be like my project directory, of course you already have code, you would cd to that directory where your code is, like the root. And what we do is if you want to version control this, you would call the git command space init, which would initialize this as what we call a git repository. Basically all it does is create a directory called .git. Now if a directory name starts with ., that means it's like a hidden directory, a hidden file. It came from Unix systems and Windows also considered that hidden now. Anyway, if I do a dir, I won't see it, but if I dir slash a on Windows, by the way, if you're a Mac or Linux, it's ls dash a, I can see the git directory here. Anyway, I'm going to open my visual studio code editor by typing code space dot, which means open the current directory. I'm going to share with you what I'm seeing, I hope you can see that. Okay, whoops, that's not the one, sorry. Let me go and click. If you're coming from visual studio code, you can also do file open folder and locate the right folder. I hope that's the one. You can see, yeah. Anyway, here's my directory and I can also open a terminal here, control back tick. If you can do it with view terminal as well, and you can choose the terminal here if you're using visual studio code. This one is PowerShell like command prompt and I'll trash the other one and here it is. So for convenience, so I don't have to be switching around, so I'm going to create a new file here, test dot txt and I'm going to say hello world like that. So first thing you're going to do is if you want to know the status of this repository is the status command, so you type git space status, what happened? I think I went to the wrong place, right, yeah. Let me cd to introduction git 3, not the first one and do get in it again, there you go. I was in the wrong directory when I did the command because I had so many already made before. Anyway, going back there, I should be able to do git status now, yeah, there you go. So when you do git status, we want to know okay git, are you keeping track of anything in this directory? What's going on? Right now it's saying I have untracked files, which means git does not yet keep track of test dot txt. So what we do, if we want to keep track of that, is we always follow two step process first we add what's called the staging area and from there we can finally commit. So what we want to do is git space add space the name of the file, test dot txt, then you can do git status again to see what's going on. You can see now it says changes to be committed and this is in green now. It's recognizing you added a new file to be tracked. Okay, finally the second step is to commit. That is we want to describe this change in time that we made. So we do git space commit, let me increase the font size. I usually like to do dash m, but if I do like this git commit, it will open a text editor that's the default. It's probably going to open vi or vim if you're using mac. And to get out of that you've got to use colon and then wq. Let me see if this one does, no this one is opening my VS code. So you're going to see it like this and then you're going to type the message describing your change. This is the commit message. So let's say add test dot txt. And if you want to be more specific with hello world message, something like that. It's a brief but concise message that's letting other people know when they look back in time what was done at this point in time. And then once you're done you can save the file and close it. Now like I said, if it opens vi or vim, to get out you've got to type colon wq. The w means write and q means quit, colon wq or vi, paste in the zoom. I'm going to close that. I probably can show you that later in the git bash, I wonder. Anyway, if I do git status now, nothing to commit. That means git already kept track of that file, it already knows about that. So if you want to look back in history, you can type git space log and it will tell you the commits. Something I didn't tell you before is probably going to complain about who you are in git if you haven't done git about your identity. So if you want to identify yourself to git, you can run the following commands here. You can do git config dash dash global user dot name and then your name. That's one way. I'm going to paste it in the zoom chat. So this one will configure your identify your name there and the other one is, I already did it so I don't want to do it again. So git config dash dash global user dot email and then your mail here. So those two commands will identify yourself to git and paste that to zoom. Basically what those two commands are doing is basically just changing a file called dot git config in your home directory. Your home directory on Mac and Linux is the dollar home or tilde. So it's going to be if you do cat dollar home slash dot git config or open it in visual studio code, it will you should see your name and email there. In my case, I'm using Windows, I would have to say percent user profile, which is the variable for the user C colon users, my username, and then backslash dot git config. And that would open the file there. So you can verify it indeed get config just changes that file. In any case, yeah, so like I said, going back to git log, you should see your name here and the email and the description of what you did at this point in time. Now every commit has what's called a shot, which stands for secure hashing algorithm, and also called the hash, this code here. So every commit is going to have a different one that identifies that that okay. So if you hear if you hear a shark or commit a hash, that's what it means. Okay, so let's make a change to the file I replace world with there, save that. So I made a change to the source code. In the real world, it would be working towards a solution to some problem, right? And you change it there and so on. And then you would go here and get status to check what's going on. Okay, this file was modified, therefore, I must follow the two step process if I want to commit this to the history. So git add test dot txt. But before I do that, let me show you how you can actually, obviously, right now I can see my change. But if I didn't have the editor open there for some reason, right? How could I change, could I see what I changed? What happened here? I lost my thing. Anyway, I could do get diff like this, and it will tell me what the change is. So you can see the minus with red color was removed, and another line plus with the green color was added. In practice, you just know that the word, the word world was replaced with there, right? Anyway, if you're satisfied, you think that's fine, git add. And you're going to do status again to check, okay, changes to be committed. Okay, also called the staging area. And then you're going to do git commit. And if you want to do the message right away, you can type a dash M option and write it here instead of opening an external editor. I can describe replace world with there, enter. And that creates yet another commit. So you can see git log, there's my new commit here. So let's see, I want to annotate line with. So with time, let me write it here. With time, this is the timeline T, we're going to be making commits. And usually that's represented by a circle. If you ever read about yet, let's make a circle here. This is one commit that we did. And then at some other point in time, we did another one. Okay, so that's the graphical representation of that. But this is the main timeline, what we call the master branch, as you're going to see if I type git branch, right now the star is next to the branch that's currently selected for work, and that's the master or branch. You're probably going to see main now that they changed the name to instead of master, you're going to see main. So that's also common these days. Anyway, this is the main timeline you're going to see, but you can actually have separate timelines. And that's what people usually do when they build new features. So what's going to happen is, let me branch off here. Highlighter, people are going to branch off of the main timeline to work on a new feature. Let's say after this commit, I want to build a new feature without affecting what's currently already there, because if as you're building things, many things could break as you're working on it and committing. So you don't want that to be present in the stable version in the master timeline, because that's always supposed to be stable without any bugs. And it's also the one that's deployed to production. So what you want to do is you want to branch off, create a new branch called a feature branch, and then you want to do your commits there, do your things as many as you want. And then once you're ready to actually launch the feature, right, you finish your work, what you're going to do is propose changes to the main timeline, and that will eventually be integrated back. So that means all of these get integrated there and go to the main timeline. And this in GitHub, as you'll see later, this process of merging is the proposal of changes is called a full request. And then after that, you merge your feature branch into the main branch. And that way, the main branch will now get all your commits and integrate those changes. Okay, so let's try to work on that right now. So to change the new branch, let's say we're going to implement a new feature or fix a bug or whatever. So we're going to do get check out to switch to a new branch, you've got to use the dash B option. And then give it a name. Actually I name it lowercase separated by dash. So let's say add sentence, I want to add a new sentence to the file. So that's my feature. So I would do enter. And if you see here, it says switch to a new branch. And if I do get branch now, I see that the star is now at the add sentence branch. That means right now I am selected, I have switched to the add sentence branch. So that means I can start doing the work here, let me add a new sentence, a new sentence, and that's my work. Maybe there could be multiple commits over time as I'm working through the solution. And so on and so on. Let me demonstrate get bash. I think that one has vi. Let me see. Okay, I'm going to get bash right now. So get status, okay. Another nice feature about get, there's this dash B option I'm going to show you right now. If you do get add dash B and the file name, it will actually show you the change right there. Oh, I added a new sentence, nice. So I can say why, which means yes to accept it or no and or I can press Q to quit. The other options we don't care about right now. So I'm going to accept that with why. And there it is, it's been added to staging area. As you can see changes to be committed. And I can finally do a get commit. Now I'm going to do without dash M to see if vi appears. I know it doesn't. Nevermind. Anyway, so just write your add a new sentence, save it, and that's my commit message. And then I would keep going making commits on and on in my feature branch. And that's that's not another one. Maybe I forgot to put a period, I'll put a period there, do the same thing, get add test dot txt, and then get commit dash M, add period to end of sentence, something like that to be clear. So you for the message, you want to be tried to be, you know, as descriptive as possible of what changes happen in that commit. Don't just write a message like update file dot test dot txt, that's that's of course you can write it that way, but it's best we can add something more like more specific because over time when people look back, when they read the message, they will understand right away what was happening. Whereas if they read update test dot txt, okay, what did you change there? Exactly. Because, you know, you already know that file was changed, but what exactly changed. So you want to try to be good at writing commit messages like that. Anyway, now I can see the history. We got this, and that, and the other one here, right now. So what we got two commits out in our feature branch that is not in the main timeline. Okay, so if you go back here to switch to master, so I'll show you that the commits are not there, I do get check out master the name of the branch to switch, okay. And if you go and switch, you see the sentence no longer there, okay, but don't worry, you didn't lose it. It's actually just there. You just got to go back to your add sentence by doing get check out, add that sentence like that. And there you go. Now the change is there. Okay. In any case, so when you're ready for this feature to be merged into the main branch, usually you would go to GitHub, propose the changes using a pull request, or if using get lab, it's called merge request, they're all the same kind of feature. And then the other person who would review the code would either give you feedback or approve it right away and merge eventually. But since we're not doing GitHub yet, what I'm going to do is just do get check out master here, and I'll teach you how you can merge a branch into the current branch. So first make sure in master, and then you're going to go get merge and then the name of the branch you want to merge add sentence. So what this is going to do is exactly what this graph annotation is showing, you're going to integrate all those commits into the main timeline. And that way you suddenly appear there. You can see now the Git log, you get all the commits that I have. And then once you're done with that, you can delete the other one, you can see I already integrated my changes, you can do get branch dash D to delete the add dash sentence. Make sure you never delete master, that's not what we want to do. We just delete the feature branches after they have been integrated into the main branch. And while you're doing all this stuff, you always have to be aware what's your current branch. So always be typing get branch to be aware, because when you want to create a new feature branch, you want to be first check out master. So always type that if you're unsure. Make sure in the master, then you can branch off with git checkout dash be a feature. And then if you want to build yet another feature not related to this, what you have to do is check out master again, so it switches back to master and then you branch off master the same way. Okay, otherwise you would be branching off a feature branch. I think somebody in the previous bootcamp was did that. And that's not really what we want to do. Let me try to write it here. So the reason we always go back to master so we branch off like this in the annotation. If you did, if you didn't change it, let's say I switch to this red branch. For some reason, I branched off this. So I would create yet another timeline there, like this, which is not what we want. That's totally different. And this would go on like that. And then the other one would go on off of this one, which is wrong. Actually this one here should be branched off the master like that. If you know what I'm writing here, I don't know if that's clear. Okay, so get checkout master always before you create a feature branch. Keep that in mind. All right. I think that's good enough. So we get status, a diff, commit, log. If you need any sort of help, you can always do get dash dash help. I think it shows you the commands like that. Or you could go to the website, get website and click documentation, reference, and it tells you all these commands here. The ones we learned was add, status, diff, commit, and so on in it. Or you could ask your AI, artificial intelligence, chatbot like chatGPT, GitHub, co-pilot, jammin9, whatever. Okay, nice. Now let's talk about GitHub. Let's introduce GitHub. What is GitHub? Well, GitHub is like the social media for voting, and let me share the other window here because I'm logged in. Actually, I can maybe use this one. So basically, here is a place where you can store your code. Let me type slash explore here. So you can explore other people's projects and most of them being open source in the sense you can read the code. It's not closed. And basically, they store git repositories in a website here. And you can see, for example, Microsoft's generative AI for beginners. This is the repository. And this is the file explorer view. We can explore the files. So basically what we were seeing in our local machine, but in the cloud, right? And they have the readme file and all that stuff. And then you have contributors, which are people who contributed to this code. So it's basically social media for coding. If you find a project that you like, you could go there and contribute. If for example, one way of contributing is you go to issues tab and you report some problem. Or maybe you want to suggest a new feature. And going back to code, if you're a programmer, you could propose some changes to the code. Maybe you want to build a new feature or fix a bug and then you propose it. It's the pull request tab here. You can see people are proposing new changes and you can collect files change. And this is the code. They change. It sounds like some Chinese translation. That's one way you can help. If you don't know how to program, you can translate some of the program strings. That's what this person is doing. So you can contribute in many sorts of ways to open source. Okay, now let's learn how we can actually bring our code that we wrote to GitHub. So it's open for everybody to help out. So here's a code if you recall, just a file, but in the real world have a lot of things there. So what we got to do is first, after registering in account of GitHub, you want to go there and create a new repository. Let me see if I have my Chrome open here. I think it's this one. So I'm logged in. So there are many different ways to get there. You could go to your top right icon and click your repositories and you click new. That's one way. I think other ways is if you're github.com, you can click new here in the sidebar. That's another way. Anyway, you choose the owner. I have many. So I'm choosing my personal account and the repository name will be the same folder name that I had introduction to github. You don't have to have the same name, but I'm just trying to be consistent. And then I'm going to make it public and I'm just going to create it like that without any of the other stuff. So this establishes the repository in the cloud at github. So what I got to do now is send the code to github. And that's called a git push operation. Before we do that, you have to identify yourself to github as you're sending it. So there are different ways. There's the default HTTPS way, which if you do that way, it will probably open a browser window asking you to authorize. And there's the SSH way, which is more convenient because the process is kind of automated and you're not going to notice it actually using our key to unlock stuff. So I'll show you how it can generate a key if you don't already have one and add it to github so you can leverage SSH, which is usually the preferred way. Okay, so what you got to do is go to your local machine in the terminal. And I don't know if you already have it, but usually the keys are placed in your home directory slash dot SSH. So if you go there, let me try going there in my Explorer here, github Explorer, user profile dot SSH, because I already have it. So I want to show you, you probably have it to one moment where I share my screen. So if you go there in your finder or file explorer, if you have the dot SSH in your home directory, you probably have the key usually called id underscore ed25519 and the one dot pub. Okay, so if you already have this, that means you already have the key. Otherwise, if you don't have it, I'll show you how to generate one right now. So you would do SSH dash key gen space dash t. And then you do think ed25519, which is the algorithm. And then dash capital C option here with your email. Let me do the test on mail.com. Let me just rename my file so it's actually acted as if I didn't have it one moment, because I want to show you a test one, how I would create it. Okay, I just renamed mine. So press enter, and it's going to ask where you want to start. You should always use the default location, my recommendation, don't type anything. Or if you have different keys, obviously, you would have to type a different location. So I just keep it in dot SSH slash id ed25519. And then passphrase, I can leave it empty, enter, enter, and that's generated. And if you notice in my directory there, I have now a new key here that was created. There's the private one, this one, id underscore ed25519. And there's the public one, which is with the dot public extension. And if you want to get the contents of that in the terminal on Windows, just type percent user profile, percent backslash dot SSH slash id25519, let me see, ed, sorry, ed25519.pub, that's the public key that you want. If you're on Linux or Mac, just cat, and you can use either tilde or dollar home, either way, and the slash is forward. You want to do that to get the content, okay? Once you've got the content, you got to copy that to GitHub. Let me show you here. You want to go to github.com, click in the top right and settings. You want to go to SSH and GPG keys, you want to click new SSH key, and you want to paste it here under key and give it a name like this describes. So you know where this key is stored, maybe my laptop with username, whatever, MacBook, whatever, whatever it is that you know exactly where the key is stored, otherwise you won't remember what the key is for. If you want the direct link, I post to Zoom. Anyway, press add SSH key, and that way GitHub will know it's you whenever you try to push or send code. Okay, with that out of the way, let me gather my thing here, oops, it's not what I want. That out of the way, let me revert my keys here, otherwise I won't be able to do the github thing. One moment, okay. So what you want to do now is go back to your local repository, I'm on bash, okay, I'm on bash right now. So you want to add git, a remote. So basically, this is the concept of remote. Your code here is local to your machine. If you want to have it stored anywhere else, that's called a remote location. And the remote right now is going to be GitHub. So we're going to get, get remote, add, and then you can copy whatever GitHub has in the page for the repository here, this thing here with git at, for SSH, you're going to copy that. Okay, I know by heart, so I usually don't have to copy. It's always going to be git at github.com, colon, and your username, slash the name of the repository, .git, enter, what happened, oh, you got to give it a name, sorry, usually we call it origin. So after add, before that, you got to give it a name. We give it name origin, usually. And to verify it's there, git remote dash b. And you should see two of them, one for fetch, another for push, okay. Now to send the code to GitHub, that's called a git push. If you want to download from GitHub, that's called a fetch, okay. So what we're going to do is send for a local machine to GitHub with a git push. Now because it's the first time, I usually do the option dash u, and then you got to tell, okay, what's the remote? It's the origin space, what's the branch? That's the master branch. The dash u option is so that the next time I do this, I don't have to type origin master again, okay. So if I do dash u, it's going to track the branch like this, see that, set up to track. And I can do git push without origin master, and it should work the same way. Now let's go to GitHub, and if you refresh, you should see that the file is down here, and there you go, you can see what you did, and what's nice going back, you can see the git log by clicking this commit thing, and you see all your history here, conveniently, in a web page. So basically GitHub is like a front for the git commands. GitHub is built around the git command. So all you see here is basically a graphical user interface, or a web interface to git. So behind the scenes, GitHub is using git. So GitHub is not the same thing as git, if you think about that. So git is the program that does the version control, GitHub is a service that was built around providing you a graphical and social collaborative way of working with git. Behind the scenes, it's all git stuff. So you can see, click the commit, see what happened, oh, before and after. And you can use the unified view here to see in one thing, or you can use the split. Going back, you can look at the other ones in history like that. This is the first one I did to Hello World. If you go to the file view, it's also nice because I can use the history thing to see how this file changed over time. I can use the blame function here that tells me who changed what line the latest. If I see here, it was me with this commit. And the other one is also me with that commit. And if you want to go back in time, you can click this icon here to see the change that was made prior to this. And you can see now there's only Hello World here. That's before I had the sentence. So very powerful. And like I said, version control allows you to look back in history. You can, let's say you're having trouble in your job, hey, I just can't figure out how to do this feature. What I would do is, for example, I would look back in history to see if there's a very similar problem that somebody already solved before. And I would just look at our solution in the get history and just try to implement that or even improve upon that solution. And if there was a problem in production that your boss came, hey, something's not working fine in production ever since Monday. Can you look at it? So what you would do is look at the history and go back, backtracking, right? Okay, what's the latest change here that I did? Okay, let's look. Okay, I did this. That doesn't cause problem. I did that. Oh, this one is going to the problem because somebody changed the code to do this. And that's causing a problem. So that's very powerful. You always can find things. And then to fix the problem, maybe you want the customers going crazy. Hey, this is, nothing's working right now. What do we do? You can always go back in time. Hey, let's roll back and revert this get change. So that goes back in time. And then we can have it working for now and work on the fix. And then we can bring back all the changes that we did before. So stuff like that, the many, many useful features. And there's also get also allows many other functionality to be built in around a repository like continuous integration, which is in the sense every time you push the code to GitHub, it will run tests to let you know if your code didn't break anything. It's called continuous integration. And if you try to propose new changes, it'll run that and say, hey, your code is not passing or quality standards. Okay, make sure you're passing the test before we approve your changes and merge. So that way you prevent any problems from going to production, even before you merge. There's continuous deployment, which is CD, which is basically as soon as your changes are approved and merged, there will be automation around that that detects, hey, we got new code. Let's deploy that and launch to our production app. So right away, you're going to see your change in production to all your customers, right? So when I work, for example, in a company, we would be doing continuous deployment pretty much 24 seven, we build a feature, another person builds another feature. So we queue up to deploy the changes as soon as merge, it's out. So 24 seven, many, many changes and features being added. All right, so very useful. If you're working maybe with your even useful outside code, like if you're writing a NASA or maybe have some law, right, you've got to change the law, some text. It's always like they change this at that. It's the same thing. You can track it over time. If you ever use Google docs, they have the feature, right, to look back in time revisions, the same kind of concept. Anyway, I think we're good for this session. In the next one, we talk more about collaboration on GitHub.