Transcription
Hey guys, welcome to my Git and GitHub crash course for 2025 and beyond. So, I figured that this would be a good idea for the first crash course of the year because Git is something that absolutely every developer needs to know at least the basics of. And I do want to stress that this is a crash course, meaning that we don't dive super deep into really advanced topics. This is more for beginners as well as intermediate developers that may know just the very basics of Git and want to learn a little bit more.
So, we're going to cover all the stuff that you need to know, such as creating a local repository, staging, pushing to a remote GitHub repo, pulling, branching, and merging, and more. And we're going to start with some slides just to go over what Git and GitHub is and just some of the fundamentals. And then we'll jump in and we'll start using Git along with GitHub. And I'll even show you how to deploy a project using CI/CD, which is continuous integration and continuous deployment. We'll do that with GitHub and, uh, a company called Vercel. All right, so let's get into it.
All right guys, so I just want to go through some slides, talk a little bit about what Git is, what GitHub is, and look at some of the key features and so on. So, Git is a distributed version control system, or VCS, and it helps developers track changes in their codebase. It also allows them to collaborate with others and manage multiple versions of a project. And in its absolute simplest form and simplest use case, it's used to back up your code.
Now, unlike other version control systems, some of the older ones, Git is decentralized, meaning that you don't need a central server to use it. Instead, every developer has a full copy of the repository on their local machine. And a repository, you can think of as a, like, a digital filing cabinet that stores all your files and all the changes that you've made. So, it's kind of like a time machine for your code, and you can roll back to certain versions when you need to.
Version control is a must-have skill for any developer. It's used in almost every software project. And if you think about big companies like Google, Facebook, Microsoft, they have thousands of developers that are working on the same giant codebases, and they need a way to manage all the changes that are made. And that's where Git comes in. It allows developers to work on the same project without stepping on each other's toes. And it also provides a way to track changes, roll back to previous versions, and it's used for anywhere from, you know, a one-person to giant companies like Google and Facebook.
Now, just to go over real quickly, the key features of Git: it's distributed, it's decentralized, so there's no need for a central server. It keeps track of changes made to your codebase. Multiple developers can work on the same project. You have branching, which we're going to talk about more in a little bit, but if you want to create a separate branch to work on outside of your main branch, your main code, to either create a feature or fix a bug, you can do that. And then when you're done, you can merge it into the main branch, into the main code. You have the option to work with remote repositories like GitHub, but there's others as well, such as GitLab and Bitbucket. Extensive tooling, so Git is supported by many tools, including IDEs. And we're going to learn about the workflow soon when it comes to Git. But in addition to your repository, there's also a staging area that you can utilize, that you can put files before you actually commit them to your local repository. The speed, so Git is very fast and efficient. It also uses SHA-1 hashing to ensure data integrity. And of course, it's open source and free. It's widely available without licensing costs. It has a large community and support for plugins and things like that.
Now, there are other version control systems like Subversion or SVN, but Git is by far the most popular version control system today for the reasons that I mentioned: it's fast, it's efficient, decentralized. Now, this chart is from the Stack Overflow Developer Survey of 2022, and it shows that almost 94% of developers use Git over other version control systems, which is a huge number. And they didn't even have this question in the '23 and '24 surveys because it's just so obvious that, you know, everybody uses Git.
Now, I want to talk a little bit about GitHub because some beginners can confuse Git with GitHub. But GitHub is a web-based platform designed for version control and collaboration, and it hosts Git repositories, remote repositories, and provides a graphical interface within the browser to manage your code and do other things as well. Um, in addition to hosting your code, GitHub offers, you know, powerful collaboration tools like bug tracking, feature requests, task management. There's wikis for your projects. So, Git is the tool that you use to create these repositories and push your code to them. But something like GitHub, because there's others as well, it's not just GitHub, but these kind of remote services, this is where most of your collaboration is going to happen. This is where people are going to pull your code from and make pull requests and add issues and things like that. So, it's important to note that Git is the version control system, while GitHub is the platform that hosts Git repositories.
All right, so when it comes to installing Git, there's multiple ways to do this, and it really depends on the system you're on. So, if you're on macOS, you can use the Homebrew package manager. If you're on Linux, you can use whatever package manager for whatever distro you're using. If you're on Windows or any platform for that matter, you can download Git from the official website, which is git-scm.com. And when you download the installer on Windows, you also get a really cool terminal program called Git Bash, which is a Unix-like terminal for Windows. And even though the Windows terminal has gotten a lot better over the years, I still prefer to use Git Bash on Windows, but that's just me.
So, when it comes to using Git, you have two options: you have the terminal where you write, you know, type commands, and then you also have tools with graphical user interfaces. Now, I recommend learning Git using the terminal. It's more powerful, and you'll have a better understanding of what's happening behind the scenes. When you use an interface, it's still doing the same thing that you would do in a terminal, but you're not seeing what's actually happening and the commands that are actually being run. And then I would say, once you're comfortable with the terminal, you can try out a GUI. There's many available like GitHub Desktop, SourceTree, GitKraken. If you're using Visual Studio Code or other IDEs, there's usually, well, for Visual Studio Code, there is built-in Git features, and for many other IDEs, there are as well. But again, I would say get comfortable with the terminal first.
Now, when you start using Git, you do have to configure it initially with your name and email address. This is important because every Git commit uses this information, and you can set this with these commands here: `git config --global user.name` and then your name, and then same with email.
Now, I want to go over the workflow of Git, and you're going to learn more about this when we actually do it. This is just kind of an overview. So, if you look at the boxes at the top, you have your working directory, and this is on your local machine. You have your working directory, this is where you make changes to your files. You have the staging area where you prepare your files for commit. And then you have the local repository where Git stores all the changes that you've made to your files. And this will be all stored in a hidden folder called `.git` in your project directory. And then the remote repository, whether that's on GitHub or GitLab or wherever that is, that's stored remote, and people can then pull that code down and so on.
So, I just want to go over kind of the workflow and the commands that you'll run to move files around to these different areas, and again, we're going to be doing this, so this is just an overview. So, first off, you're going to run `git init`, and that will initialize a new repository in your project folder or your working directory, and it'll be a hidden folder called `.git`. Then, once you're ready to add some files to the staging area, let's say it's your initial commit, or you added a new feature, or you fixed a bug or whatever it might be, you add it to the staging area with the `git add` command. And then when you're ready to commit it to your local repository, you would run the `git commit` command, and you add a comment explaining what that commit is. Okay.
Once you're ready to push to your remote repo, whether that's on GitHub or GitLab, then you're going to use the `git push` command. And this is after you configure your remote repository because it has to know where it's actually going to be pushed to, and I'll show you how to do that. Now, when you want to pull changes from a repository, you would use the `git pull` command. That's going to pull the files down to your working directory.
All right, so let's say one person makes a commit and they push to GitHub, and then another developer wants to get those changes, and they're already, you know, they already cloned the repo or whatever, then they would just type `git pull`, and that will get the latest changes.
Now, once you go to a repository for the first time and you want to get those files on your machine, there's a few ways you can do it. You can click the download button and get the zip file, but you don't really want to do that if you're going to continuously work on the repository. So, you would use the `git clone` command, and that would pull the entire thing onto your local machine.
Branching is a key feature of Git. It allows you to work on new features or bug fixes without affecting the main codebase. So, you can create a new branch, make a change, and then merge those changes into the main branch. And this is a common workflow in Git. You can also create branches for different environments like production, staging, and development. So, let's say you have a project that logs workouts and you want to add a feature that calculates the total calories burned. So, you can create a new branch called `feature/calories` and work on that feature. And then when you're done, you can then merge that branch back into the main branch. And this is called a pull request. You're requesting that your changes be merged into the main codebase. So, this is, again, a common workflow in Git.
So, I think that's all I want to talk about in the slides, so kind of a general overview. Now, we're going to jump in, and I'm going to show you how to actually run these commands, how to create a local repository, how to create a remote GitHub repository, how to push it, how to pull, make changes, etc. So, let's get into it.
All right, so first thing you want to do is get Git installed if you don't have it already. And you can check by opening your terminal and just saying `git --version`. That'll show you the current version. If you don't have it, then like I said, there's a few ways you can install it. You can use Homebrew on Mac or your Linux package manager, or just go to git-scm.com/downloads and download it for Windows, Mac, or Linux.
All right, so once you get it installed, we're going to have to configure your name and email. And this is something you do just once, the first time that you're using Git. So, you just want to open up a terminal. It doesn't matter what folder you're in at the moment. I'll get into what this task tracker is in a minute, but we want to run two commands. So, you're going to do `git config --global user.name` and then whatever you want to specify as your name. So, I would say, you know, Brad Traversy. Okay, I'm not going to run that because I already have it set. And you can check what's set by just taking the value away and just running this. So, you'll see that's what I have as my name.
All right, then you're going to want to do the same for email. So, that would be `user.email`, and then you would put in, you know, whatever email that you're using. Okay, so that's how you can configure that. Now, there's one other thing that I would suggest configuring, and that's the name of your main branch. Because by default, with Git, it's called `master`, but with GitHub, they changed it from `master` to `main`. So, you can check what it is by doing `--global` and then `init.defaultBranch`. And you'll see mine is `main` because I changed it, but yours might say `master`. So, what you can do to change it to match GitHub's...
I'm going to talk about the project, which doesn't really matter because that's not the focus. But I have a download, a link to a download in the description to this task tracker zip file, which has an `index.html`, a `script.js`, and a `style.css`. And it's just an example of a project that we're going to use to make changes, commit to our repository, push to GitHub, etc. If you want to use some other files that you create on your own, that's absolutely fine. But I figured I'd just give you something to work with. And the reason that I put it as a download and didn't add it to, you know, its own repository for you to clone is I don't want to start with cloning. I want to start as if this were your own project.
All right, so just download that, and you can see I'm already in the task tracker folder, and I could do everything from here in my terminal, but I'm going to open this folder up in VS Code so that I can use the terminal here, and we can actually see the files. Okay, because there are some Git integrations with VS Code, and even though that's not the focus of this tutorial, the focus is the, you know, the commands and the term, we still have that as like a visual confirmation of what's happening. So, just to kind of go over these real quick, very, very simple, I just have an H1 and a UL here. So, we have a `script.js` with just a console log, and then a stylesheet with a little bit of CSS. So, again, what's in here doesn't really matter.
So, the very first thing you're going to do when you create a project and you want to use Git is you want to initialize a local repository, and you do that with the command `git init`. Okay, if you remember, if we look at this slide here, we run `git init`, that will initialize a new repository, and it creates this hidden `.git` folder, right? So, if I were to do an `ls` (list my files) and show hidden files and folders, it shows this `.git`. That's my Git repository. If you wanted to completely get rid of it, you could do `rm -rf .git` and that would completely delete it.
All right, so, and you can see that a couple things happened within VS Code. One, it shows my branch name down in the corner, `main`, and it also changed the colors of the file names and put this "U" next to it. So, this just represents files that are untracked. The "U" and the green coloring, which means that I haven't added them to my staging area, because remember, there's a staging area, right? And then there's our local repo where we commit to. So, we haven't done anything with these files yet, so they're untracked.
Now, there's also a Source Control tab here, and you can do everything that you can do within the terminal with Git commands here as well, but this isn't a tutorial on VS Code, so I'm not going to get too much into that. But it does show you which files are untracked, and it shows you the status. Now, to check the status within the terminal, you can do `git status`, and that shows us that we have three untracked files. Okay, so what we would do next, if we look at the workflow here, is we would run `git add` and add files to the staging area. So, typically what you'll do is you'll work on your project, get it to a place where you know you want to save it essentially, and then you want to run `git add`. And typically, you'll add all your files, but I just want to show you, you can add them individually. So, if I do `git add index.html`, now in VS Code, just to show you as a visual representation, it has an "A" next to it. It says "index added." So, this file has been added to the staging area. And if I were to run `git status`, it shows me that. Okay, so this here, and then these two are still untracked. So, if I run `git add .` or `git add all`, now they all have an "A" next to them. And if I run `git status`, then you can see that they're all now in the staging area to be committed.
Now, to commit, let's see. So, to commit, we run `git commit`, and that will commit files to your local repository, not your remote, not GitHub or anything. We haven't set any of that up yet. This is all local. So, let's go ahead and run `git commit`, and what you're going to do is add the `-m` flag and add a message in quotes. So, typically, when it's your first one, you'll do something like "initial commit." So, if we run that now, you can see the files are no longer green over here, they're white with no letter because now they're, everything's up to date, everything's added to the local repository. If I run `git status`, it says "nothing to commit, working tree clean" because I've committed everything.
Now, from here, you have the option of either adding your remote repository with GitHub, so you would need to create one on GitHub, or you could just keep working locally for now. So, for instance, if I want to make a change, and I'll just do something silly here, I'll just add another task, right? So, now if I save that, you can see that this has changed color now to orange, which means that this file has been changed from what's in the local repository. So, you go through, you make some changes, you add a feature, you fix something, whatever it is, and then you're going to `git add` again. So, just say `git add all`, which is only going to add the index file because that's all that's been changed, right? So, now that gets added. Now you want to commit it. So, let's say `git commit -m` and I'll just say "added new task." Okay, so now that gets added, and now I have my repository up to date. And you can also run `git log`, which will show you your commits, starting with the most recent first, which is "added new task," shows me the author, the date, and the commit hash. And if I click the down arrow, you can see that it goes to the next one, which is "initial commit." And then to get out of this, you just hit "q" to quit. So, that's going to be your workflow. As you make some changes, you add a new feature, whatever the change might be, you add the files to your staging area, and then you commit them. And we're not dealing with a remote repository just yet, but as far as frequency goes, it's really up to you. Some people will commit really often, some will only do it after major features. It's really just based on your preference.
All right, so now what we're going to want to do is the next step, which is going to be `git push`, where we push to a remote repository, and that could be GitHub, but it could also be GitLab, Bitbucket, or something else. So, what we're going to do is set up a GitHub repository because right now we don't have one to actually push to. So, you're going to want to go to GitHub. If you don't have an account, create one. And, you know, you can list all your repositories, that's what you see here. You also have a profile that will show your most popular repositories and also your contribution grid here. So, basically, the lighter the green, the more contributions. Like this day, November 30th, I had seven. This day I had three. And then the blank ones, I didn't have any contributions, meaning I didn't push to GitHub.
All right, so what you're going to want to do is create a new repository with this right here, it's a plus sign, and the new repository. You're going to name it. Typically, you're going to call it what your project or your folder is called, which in my case would be "task-tracker." And I'm just going to say "demo project for tutorial." I'm not going to keep this. Now, here is where you choose if it's public or private. If it's public, anyone can go to this repository and anyone can see the code. All right, so keep that in mind. I'm going to make it private because I don't want people seeing this because it's just for this video. It's nothing that I want anybody to have because it's just nothing really. And then you can also initialize a README file. I typically don't do this, I create it myself and then push it, but you can do that here. You can also add a `.gitignore` file, which I'll talk about in a little bit, but again, I add that myself. So, let's say "Create repository."
Now, it shows you basically the steps if you're creating a new repository or if you're pushing an existing repository, which is what we're doing. We've already done the init, the commit, the add. So, basically, what we need to do is first run this command. So, this will add the, this repository as our remote. So, I'm just going to paste that in here. So, it's `git remote add origin`. And then "origin" is just the name of the alias of the repository. So, you can name it whatever you want, but typically I'll just keep it as "origin." And then we're just adding the address to the repo, which is my username, yours will obviously be your username, slash, and then whatever you called the repository. So, I'm going to run that. It's not going to do anything, but it did add the remote repository.
So, next, let's go back here. So, we want to make sure that we're using the main branch. I mean, we don't really have to run this, but I usually do anyway. So, we're just saying we want to use the main branch. And then we want to finally push. So, we're going to run this `git push -u origin main`. Now, we only have to add the `-u`, which stands for upstream, and then origin main. We only have to add this this time. Any other time that we push in the future, we can just simply run `git push` after we commit to our local repository. So, keep that in mind. So, we run that, and then you can see that it gets pushed to GitHub.
Now, if I go back to this page and I reload, we see our code. So, we have the three files in the repository. This is private, so nobody can see it unless I give them permission. If it was public, anyone could go to this link, and they would see your code. Now, what shows here is whatever is in your README file, your `README.md`, which is a markdown file. And we don't have one, so that's why it says "Add a README." And we can do it from here, or we can, what I'll usually do is create it on my machine and then push it. But I want to show you how we can pull stuff from the repository. So, I'm actually going to add the README from here. So, I'm going to click that button, and then I'm just going to add a number sign, and we'll say "Task Tracker." Now, this uses markdown syntax, and if you use a number sign, that's going to be an H1. If I use two, that would be, you know, this heading would be an H2. If I use three, that'll be an H3, and so on. And I have a full crash course on markdown if you want to check that out. I'll try to remember to put that link in the description. So, I'm just going to say, "This is a demo project for my Git tutorial." And this is where you'll usually put things like the usage, so what do you have to do to run this? If you're building something with Node.js, you would say, you know, run `npm install` to install any dependencies, `npm run dev` to run the server. You just want to give full instructions on how to use this project. But this is something very simple, so I'm just going to add this. And you can see the preview as well as to what it will look like, which it will look like like this. So, I'm going to commit the changes, and this does a commit just like we did from the terminal. And you can add a description. I'm just going to do "create README," and then we'll say "commit changes."
Now, we have a README file here. However, we don't have it here. So, what we would do is we would pull the changes from the remote repository. All right, and we would do this if someone else had cloned the repository, made some changes, and then pushed to it. We would need those changes. So, that would be this step here, which would be a `git pull`. All right, so let's go ahead and run `git pull`, and now we have the README here, because it pulled any changes from the server.
Now, the next thing I want to talk about is the `.gitignore` file, which is really important because you're going to have some things in your project that you're not going to want to push to GitHub. So, for instance, you might have an `.env` file that has environment variables, which can hold things like API keys and stuff that you definitely don't want the public to see. So, let's actually create an `.env` file, and let's say we have something like `API_KEY` and we have it set to whatever, one, two, three. Doesn't really matter. So, you're not going to want this to be available in your repository, especially if it's a public repo, right? So, what you would do is create a file called `.gitignore`. Make sure you have that dot, and then anything you put in here is going to be safe and not pushed to the repository. So, I'm going to add `env`. All right, so I'm just specifying that I don't want this file to be in the repository, right?
So, now let's make another change. We'll just go ahead and add another task, I guess. And then I'm going to say `git add all`, and `git commit`, and let's say "added Task 5." And then if I want to push, I can just say `git push`. I don't have to do the, you know, the `-u origin` or anything like that. So, I'll go ahead and push. And then if we check out the GitHub repo, I'm just going to reload this. You'll see that we have our `.gitignore`. We have the latest commit, which is "added Task 5," but the file is not here. I have it in my directory here, but it's not included in the actual repo.
Now, there's a couple shortcuts that I want to show you as well. So, if you want to add and commit at the same time in one command, you can do that with the `-a` flag. So, let's say I add another task here, and when I'm adding these tasks, this is just an example. Normally, you would be adding a whole new feature, there'd be multiple files changed, but I just want to make some kind of change. So, let's say that I want to add and commit in one command. So, I can do `git commit`, remember I haven't added this `index.html` to my local repository yet, or I'm sorry, I haven't added it to the staging area, but I can do `-a` and then also `-m` for the message here, and then I'm going to say "added added task six." Okay, so if I run that now, say `git status`, and it doesn't show anything in the staging area. If your branch is ahead by one commit, so I can now just run `git push`. Okay, and now if we go back to our repository, we should see the new commit. You can see "added task six."
All right, so that's how you can do it in one command. Another thing you could do, and I'll just again add another task just to make a change. Another thing you could do is say `git add index.html`, and then we can do `&&` (double ampersand), so `git commit -m` and let's say "added task 7." So, here I'm doing the `git add` and the `git commit` in one command as well. And then we'll do `git push`. Check it out, and we should see "added task 7." And it's only going to be on the files where that were changed. In this case, only the `index.html` was changed.
Now, while we're on the GitHub repo here, the interface, just want to go over a couple things and just to get you a little bit more familiar. So, obviously, it shows our files, it shows the commits, and it shows when they were made. Here is the branch, `main` branch. If I had other branches, then they would show here as well. Over here, it says "six commits," so that's what I've made so far. And if I click on that, it'll show me all the commits that are made, and it breaks it up by day. And if I want to see the state of the code in one of these commits, I can do that. So, if I click on "add new task," it shows me what was actually changed at that point, and what was changed was I added a new task, I added task four. All right, so you can always go back and check what was actually added or removed or whatever was changed.
And let's see, we have up here a bunch of tabs. Of course, the code tab, that's what we're on. The issues tab, so people can submit issues. So, if they run into a bug or something, they can do that, and they can add labels to them. Pull requests, so if someone wants to collaborate and they fix a bug or they add a feature, they can then make a pull request for you to look at and approve. So, all your pull requests will show up here. Actions, so here you can set up continuous deployment and continuous integration pipelines. That's beyond the scope of this tutorial. And then projects, so here you can manage your project using GitHub's built-in project management tools. Wiki, so if you want to create a wiki. Security has to do with your security policies. Insights, so you can see, you know, the traffic and analytics. Settings, so from here you can do things like change the visibility, so if you want to change it from public to private, if you want to disable issues, if you want to delete the repository, archive it, transfer it, so all that stuff is done in the settings tab, or also add collaborators. That's another important one. So, if you want someone else to be able to work on this repository, you would just add their GitHub email here, and that would send an invite to them. You can do more advanced stuff like webhooks. There's a lot you can do here. I'm just scratching the surface, just to give you an introduction. But yeah, there's a lot you can do. It shows here the languages, so whatever technologies are actually used in the repo. But yeah, so that's kind of the basics.
Now, let's talk about getting code from GitHub. Okay, and we've already looked at `pull`, which is one of the ways. Now, you can download an entire zip of the repository if you go to this code button here and you just say "download zip," but you're only going to do that if you just want the code and you don't want anything else to do with the repository. You don't want to add to it, you don't want to do anything with it. It still, I would say clone it anyways, because it's literally just a command, and you have the whole thing on your machine rather than extracting a zip file and so on. And that's the next one, which is `git clone`. You get a copy of the full repo onto your machine. Right? So, to do that, you would run `git clone`, and you can clone with the SSH link here or using HTTPS. Now, to use SSH, you're going to have to generate some SSH keys and add them to GitHub. I'm going to show you how to do that in a minute.
Another thing you could do is `git fetch`, which is going to, it's when you want to get the latest changes from the remote repository, but you don't want to merge them. So, you can use `git fetch`. And then forking is copying a repository from GitHub onto GitHub within your own account. Right? So, if someone else, you'll see I can't fork my own repository, but if I was on, if someone else was on this and they wanted their own copy of this on their GitHub account, like let's say my username was "hello," it would be `hello/task-tracker`. And I could fork it by just clicking this button, and I'd have that automatically in my account. Then I could clone that onto my machine, and I could work on that, which would be my own repository.
All right, so those are the main ways that you would get files from GitHub. Now, I want to go over cloning. So, like I said before, you can clone using this SSH link right here. You need to generate some keys and put them on GitHub. So, the way you would do that, let's just jump back into VS Code here. Just going to close that up. So, the way you would do that, `ssh-keygen`, that's what we use to generate a new SSH key pair. And then we'll do `-t`, so the type would be RSA, and then the bits, so `-b` would be 4096. So, if I run that, it's going to ask me the location and the name of the key. And the default would be in my home directory and then in an SSH folder, which is a hidden folder, and it would call it `id_rsa`. And if you're fine with that, you can just hit enter. But if you want to change it, then you would put the location. So, for me, let's say `users/BradTraversy` (obviously yours would be a different location, at least I hope so), and then `/ssh/` and I'll usually call it like `id_github`, we'll say `github2`. Okay. And you can add a passphrase if you want. I'm just going to hit enter for no passphrase. And now you can see that it's created this. So, two things: `id_github2`, which is your private key, and `id_github2.pub`, which is your public key.
All right, now what you would do is put the public key on GitHub. So, the way that we can read that public key to copy it to put it on GitHub is with the `cat` command. So, we'll say `cat` and then the tilde, which is just an alias for your home directory, `/.ssh/` and then `id_github2.pub`. And there it is. So, what you would do is copy this from here, the `ssh-rsa` to the end. So, you copy that, and then you'd go to GitHub, go to your, not your repository settings, but your actual settings, which are right here, and then go to "SSH and GPG keys," and then "New SSH key." And then you just give this some kind of description, like you could say, I don't know, "Basement," this isn't Windows, "Basement Mac," something like that, that just describes your computer, your machine. "Add SSH key," and then that would get added to your account.
All right, and you can test to see if that works by doing `ssh -T git@github.com`. And I get this success message. Okay. Now, if you get something that says like "public key denied" or something like that, usually what will fix that is to get your agent running. So, `eval $(ssh-agent -s)` and then, oops, still within backticks, `-a`. And you'll just see like this `SSH_AUTH_SOCK` and some number. Then after that, you would add the key. So, `ssh-add ~/.ssh/` and then whatever you called it, so `id_github github2`. And you wouldn't put the `.pub` here, you're adding the private key. And it says "identity added." So, once you do that, then you can try that again, and hopefully that works.
All right, so now you're ready to clone. If you want to get this, let's say we're on a different machine and we want this task tracker application, we want to clone that repository onto the machine. So, what I'm going to do is open up, let's see, I'll just create a new folder, I guess, and I'll just call this, let's say, "task," I guess I'll say "task-tracker-2," and then I'm going to open that in my terminal. Okay, so now I want to clone the repository into this folder. So, we'll say `git clone`, and then you're going to grab, let's see, we're going to go to repositories, go to the task tracker, and then I'm going to go to code, and then get this right here, copy that, paste that. Now, if I just run this as is, it's going to create a new folder called "task-tracker." If I want to take the files and put them into this folder of "task-tracker-2," then I'll just put a dot at the end. So, now it says "Cloning into..." Now, if I do an `ls`, you can see I have those files. And then you can continue to work in that folder on a different machine.
Now, I'm going to go back to where I was here in the first task tracker, and I want to now talk about branching and merging. So, branching is a key feature of Git. It allows you to work on new features or bug fixes without affecting the main codebase. And you can create a new branch, you can make changes, and then you can merge those changes back into the main branch. And this is a common workflow in Git. You can also create branches for different environments like, say, production, staging, development. So, let's go ahead and create a new branch. Let's pretend that we're creating a login for this project. So, what I might do is create a new branch. So, I'm going to say `git checkout`, so `checkout -b`, so I'm checking out, creating, and checking out a branch, and I'm going to call it `feature/login`. That's a common naming convention. It's `feature/` and whatever it is. You might also have like `bug/` whatever bug you're fixing. So, let's do that. And not only did it create the branch, but it also switched us to the branch. And you can see which branch you're on with `git branch`. So, you can see that there's two: there's `main` and there's `feature/login`, and that's the one that I'm on.
All right, so anything that I do from this point on, while I'm in this branch, is only going to be on that branch. So, I'm going to create a new file here called `login.html`. And normally you'd create, you know, the whole login functionality, not just the page, but again, we're not doing that, that's not the focus of the tutorial. But what I'm going to do here is just copy the `index.html` and paste that in here. And then we'll just change up some stuff like we'll just add "login" to the title. And let's change the H1 here to "login." And let's see, we're going to get rid of this UL and we'll add a form. And in that form, let's do `form-control`. And I do have some classes in the CSS to make this look somewhat decent. We'll just have a label, label, then an input, and then let's go under, well, actually, we'll just copy this down and then let's change this. Actually, we'll change all these to password. Change the type to password as well. And then we'll go under that div and we'll add a button, give it a class of `btn`, and we'll say "login."
All right, and then just to check out what this looks like, if we go to, I'll show you the index page, doesn't really matter, again, it's not about this project, but it just looks like this, right? And if I go to the login, so `/login.html`, then it looks like this. All right, so let's just say we just added the whole login functionality. So, I want to obviously add that to my staging area first. So, `git add`, I'll just do `git add all`. And then we want to `git commit`, and let's do `-m` and say "added added login page." So, now that's committed to my local repository. Now I'm going to push it to GitHub, but it's still, I'm going to push it in the feature branch. So, let's say `git push`, and then I'm going to do `-u origin` and then the name of the branch, which is `feature/login`.
Now, when I go back to my, my repo, we're going to see this window, it says "Compare and Pull Request," because we can make a pull request to merge this into the main branch. And you can do that as a separate developer, you know, if you just, if you're working on an open-source project and you create a feature or you fix a bug or whatever, this is how you would create a pull request. All right, but if I don't want to merge that into the main, then you're going to still see right here, `feature/login`. So, when I'm on the `main` branch, we don't see the `login.html`, right? But if I switch to `feature/login`, then we do see the `login.html`. So, you can switch between branches here.
Now, let's actually make this a pull request. So, I'm going to click this button here, and you just add a title to the pull request, add a description, and then "Create." All right, and then the owner of the repository will then go into, they'll see that there's a pull request. You can see there's one here, and they can check it, they can click on this and check the code, and then they can choose if they want to merge that pull request. So, I'm going to say that I want to merge that pull request, "Confirm merge." And now "Pull request successfully merged and closed." And then you can choose to delete the branch as well. So, I'll say "delete branch."
Now, if I go back to my code, you can see that there's no more branch on the remote repository, and the login is now merged into the main branch. All right, now back on this machine, what I can do is switch back to the main branch. So, we'll just get rid of that, let's say `git checkout main`. So, now I'm on the main branch. And then you can see that the login isn't here because I'm not up to date with the latest changes on the remote repo. So, what I'll do is I'll say `git pull origin main`. So, I'll do that, and now the login is now there. Okay, so I'm up to date with the latest changes.
Now, if I say `git branch` locally, I still have that `feature` branch, right? Because I didn't delete it here. And you can actually merge it into the main branch on your local machine as well before you actually push it to the repo. So, I could say `git merge feature/login`. I'm not going to run it because I've already pulled down the latest changes, but that would merge it into the main, and then I could push to the remote repo. So, there's a lot of different ways to do things.
Now, I want to delete the `feature/login` branch locally. So, it's already deleted on the remote. So, let's say `git branch -d feature/login`. And now that branch should be deleted. If I say `git branch`, then we just have `main`, and we're all up to date. So, that's how you can not only create branches and merge, but also how you can create pull requests.
Now, the last thing I'd like to show you is how to set up a CI/CD pipeline with continuous integration, continuous deployment with Vercel, which is a great hosting company with a very generous free tier. So, there's nothing you have to pay or anything like that, and this is great for hosting small projects. So, let's go to vercel.com. Now, I'm already logged in. You're going to have to just log in with GitHub or whatever they offer. I forget, it's been so long. But you'll get this "Hobby" package. So, I do have a "Pro" package as well, but I'm using my Hobby, which is the free one. And all we have to do to get this task tracker deployed is simply click "Add new project." And then since I'm logged in with GitHub, they have access to it, and I can choose the task tracker. Right? And then down here, since it's just a basic, it's basically just an HTML file with a little bit of styling, there's nothing I have to add as far as build and output settings or environment variables. If I were using environment variables, I would take the ones that are in the `.env` and I would add them here on my server, but I don't have any. So, I'm just going to click "Deploy."
All right, so that was very quick because it's basically nothing. And then I can say "Continue to dashboard." This is the dashboard for my project. If I click on the, if I click on "Visit," it takes me to the project, which is now deployed publicly at this domain. And if I go to `/login.html`, takes me to my login page. Okay, so it's as easy as that.
Now, if I make a change, right? So, let's look at the deployed version. We have what, five tasks? So, I'm going to come back here and I'm going to add another, say, six. And then I'm going to go ahead and say `git commit -am` and say "added new task." And then `git push`. And of course, you can use the source control tools as well. Maybe I'll do another tutorial on that, but like I said, for this, I just wanted you to get comfortable with the terminal. So, if I go to Vercel and I go to "Deployments," you can see that "add a new task" is the latest deployment, and it happened really quick because it's such a small project. And then if I go back to the deployed version and reload, there it is, Task six. So, it's as easy as that.
Now, if you guys have been around for a while and you know, you remember using like FileZilla and stuff like that, it's a lot different now, and it's a lot easier. You know, once you know how to do it. So, yeah, I mean, Vercel is a great platform. They're not sponsoring this in any way, and there's a lot of different options and things you can do, which I'm not going to get into. But I just wanted to give you an example of how simple it is to deploy a project using GitHub and CI/CD with Vercel. So, that's it, guys. Please give this a like if you enjoyed this, if you learned something from it, and I will see you next time.