Hi everyone, Kevin here. Today we are going to learn how to use both Git and also GitHub. We’ll start with what even is Git and why would you use it. Then we’ll look at how you can get Git running on your computer, and then we’ll look at how you can use it. After that, we’ll look at GitHub. GitHub is a hosting platform where you can collaborate with others on your Git repositories. By the end of this video, you’ll be proficient in using both Git and also GitHub. If you’d like to follow along, I’ve included some sample files down below in the description. All right, let’s check this out. First off, what even is Git? Git is open source and free source control management or what’s referred to as SCM. With Git, you can manage changes to files over time, and you can go back and see what those changes were. Here for example on the KevinCookieCompany.com website, I say that our eggs come from chickens that listen to classical music. Did anyone ever really believe that? We don’t play classical music for our chickens. So, I need to update this text on the website. I can now create another version of this website or another branch and then I can update the text there. Once I’m confident that the changes look good, I can then merge that back into the main branch and then I can commit that. Basically, that means that my changes will now show up on the website. Now, let’s say that maybe the operations manager comes up to me and says, hey Kevin, we actually do play classical music to all of our chickens. Well, with Git, I can simply revert back to a previous version. That’s the magic of using Git. I could revert back to previous versions. I can compare the differences between different versions. I can see who changed what. Basically, if I screw something up, well, I could just jump back to a previous version. Now that we know what Git is, next, we need to install it on our computer and to do that you can head to the website up above or you can click on the link down below in the description. Once you land on the website, click on downloads and then select your operating system and then run through the installation process. When I installed Git, it came with a terminal called Git Bash. To launch it, simply click on your Start menu and then type in Git Bash and then you can launch it, but you could also use any other terminal that you have on your computer. You could also use PowerShell or command prompt. If you’re on Mac, you could use the terminal that comes with your machine. You could also download third party terminals like Hyper.is and that works across all different platforms, so the choice is really yours. Once you’ve installed Git, you can use any terminal now to interact with Git. For this video, I’m going to use Git Bash simply because it came with the Git installation on Windows. Here I am in File Explorer, and I have these four different files that make up the KevinCookieCompany.com website. If you would like to follow along, you can download all of these files in the description of this video. I want to use Git for source control. So how do we do that? Well, let’s open up Git Bash. This is the terminal that we just installed. Now again, you could also use any other terminal that you would like. Here I am in Git Bash and before we can get started, we have to configure a few things. First, we need to specify your name and also your e-mail address. The reason this is so important is any time we commit something or write something to the history book, we need to know, well, who’s doing it. First, let’s specify the name. Here type in git config –global user.name, then insert quotes and here you can type in your name. I’ll type in Kevin Stratvert and then close my quotes and then I’ll press enter. Next, we also need to specify your e-mail address. In here let’s type in git config –global user.email and then type in your e-mail address. I’ll type in [email protected] and then hit enter. Next, we also need to set the default branch name and that might not make that much sense right now. Later on, we’ll talk more about what branches are and why you might want to use them. But for now, let’s once again type in git config –global init or initialize.default branch and we’re going to call the default branch main. Once you type all of that in, let’s once again press enter. So far, we’ve been using a command called git config, and as we’re going through this, if there’s ever a command and you’re not quite sure what it does or what different options you have for that command, you can very easily ask git for help. Here for example, I could type in git config and then I can type in a – with an h. When I press enter, this will show me help information about git config. Now zoom out a little bit more and here you can see all the different ways that you can configure things. Down below as well if you want more detailed help information, you could also type in git help and then the command config. Here I’ll press enter. This opens up a manual that’s hosted on your computer, so even if you’re on the go or you don’t have Internet access, you’ll still be able to access this file, and here it tells you more information about what that command does and here you can see a full description of what it does, and you can see all of the different options that you have when you run this command. Back now in the terminal, to clear it out, the easiest way to do that is you could simply type in clear, press enter, and that gives you a fresh view once again. Here once again I have the following directory with all of the files that make up the Kevin Cookie Company website and I want to use Git to track these files. So, let’s take a moment to look at this address here and just remember where all of these files are stored. It’s likely in a different location on your computer, so just make note of that. Back here within Git Bash, we need to change the directory to look at where we have those files. To change the directory, let’s type in CD, that stands for change directory, and then let’s type in the location. I have it in C:/users/Kevin and then Kevin Cookie Company.com Now I can press on enter and here we see that it’s now looking at this location on my computer. To now turn this into a Git repository, I simply type in git, initialize or init, and then I could simply press enter. And here we see that it’s now initialized this repository. Look at that, we’ve now created our very first repository. Back within File Explorer, it doesn’t look like anything changed, but here if I click on view and I’ll go down to the option that says show and here I can show hidden items, and here there’s now a new folder called .git. I can now click on that, and this contains all of the necessary repository files. Back within Git Bash, we’re now going to enter a command that you’ll likely use often. Type in git status and this will tell us the status of our repository. When I press enter, here I can see that I’m currently on the main branch. Remember at the very beginning, we set main as our default branch. Here I can see that there are currently no commits yet, and don’t worry, we’ll get into what that is in a little bit. And down below, I see that there are currently four untracked files. These are all of the files that we saw in File Explorer. Currently all of my files are untracked. That means if I make any changes to any of these files, Git won’t care because they are untracked. Now if I track a file, Git will know what changes I make to that file. So, let’s say I want to revert back to a previous version. I can do that. So how do we track a file? To track a file, I can simply type in git add and then I could specify the filename. So, let’s say that first I want to track the index.htm file. Here I’ll simply type in index.htm and then hit enter. So, this file is now being tracked. To confirm that it’s being tracked, once again, we could use the command that we used earlier. I can type in git status, hit enter, and here I see that one file is currently being tracked and we continue to have three untracked files. Now let’s say that for whatever reason, I no longer want to track a file. Right up here, I see the tracked file and right up above that I see a command that I can use to unstage or basically untrack this file. I can type in git rm for remove –cached and then the filename. So, let’s try this out. I’ll type in git rm –cached, and here let’s type in index.htm, then I’ll hit enter. Now once again, let’s type in git status, hit enter and once again we’re back to the original state where all four of my files are currently untracked. When I look at all of the different files that Git knows about, here one of the files is called Employee Salaries.txt. And I definitely don’t want to risk having anyone see this file. In fact, I would prefer to have Git just completely ignore this file. Let’s open up File Explorer to see how we can ignore it. In File Explorer, we’re going to create a new file called .gitignore. This allows us to ignore certain files, folders, or even just entire extentions. Here I’ll right click and let’s go to new and I’ll create a new text document. Right here, let’s select the name and the extension and let’s re-title this .gitignore and then hit enter. Here it tells me that it might become unstable if I also change the filename extension. Let’s click on yes. And here I have a new file called .gitignore. I’ll take Notepad here and let’s open this file in Notepad or you could use whatever text editor you want, and currently there’s nothing in this file, so I need to tell git what files or folders that I want to ignore. Here I’ll add a comment by entering in the hash symbol and I’ll type in ignore all .txt files. Remember, the employee salaries is a .txt file. Underneath that, here I could type in an asterisk, so basically any filename .txt, I want to ignore. Now I can go to file and save. To see a comprehensive list of all of the different ways that you can ignore files, folders, or even just entire extensions, you can go to the website down below. This is ideal for things like log files or auto generated files that you don’t want to include as part of your project, or in this case, maybe you just don’t want to show employee salaries. Back within Git Bash, let’s see if Git is in fact ignoring that file. Once again, just like we’ve been doing all along, we can type in git status and then hit enter, and here I no longer see employee salaries. I really dodged a bullet there. To give us a little bit more space, let’s clear out this view. Now that we’re ignoring one of the files, I want git to track all of the other files. Earlier we tracked that one file index.htm, but then I also untracked it. So how do I just rrack all of the files. Here I could type in Git add –all, and that’ll track all the files. Alternatively, I could also type in -A or I could even simply type in . for the entire directory. Those are all different ways that I can track all of the files. Here I’ll press enter and let’s check what happened. Once again, let’s type in Git status, hit enter, and here I can see that all of these files are currently being tracked except for that file that I ignored, and currently all of these files are in an environment called staging. Now that I’ve added all of these different files, I want to commit them. So, what does it mean to commit? To commit, you’re taking a snapshot of your repository at this point in time. Basically, what all of your files look like right now. In a sense, it’s like writing an entry into a history book, and if you ever want to go back to this point in the future, you could do that. To commit them, we could use the commit command. I’ll type in Git commit -m, and then open quotes and here I can type in a message to go along with this commit. Now remember when we commit something that’s like writing the current state of all of these different files to the history books, and this message will go along with that entry. Here, I’ll say this is my first commit and let’s say committing all files to the repository. Then I’ll close my quotes and here I can press enter. Congratulations, you just finished your first commit, and there’s now a page in the history book. That wasn’t so bad, was it? And just like that, I’ve now committed all four of these files and they are now officially part of the Git record. Here I could type in Git status once again and I see that there are no longer any files to commit. Let’s say I now want to change one of my files. I want to modify the index.htm file. Here I’ll click on this file, and I’ll drag it into Notepad, and here we see the contents of the file. Now, if you remember, we say eggs from chickens that listen to classical music, but I’ve recently found out that that’s actually not true, so let me remove this reference and maybe we just say that are, let’s say, free range, and next I could go up to file and I can now save this file. Back within Git, I can now type in Git status, hit enter, and Git recognizes that one of these files has been modified. To see what’s been modified, Git has a command for this. We could simply type in Git diff, and this will show us what the differences are. I’ll hit enter and right here, if I scroll up just a little bit, here we can see what the file name is, and here I can see the original text in red and here I can see the changed text in green, so once again the red text shows that listen to classical music and down here in the green text, we see that are free range. I’m satisfied with all of these changes, and once again, I want to add this change to the history books. Let’s once again type in Git add index.htm. The file is now currently sitting in staging. Staging is a place where your files sit until you’re ready to commit them. In a sense, it’s kind of like a holding pen until you’re ready to add that entry to the history books. In Git, you have three different environments. You have your working files where you can make edits to files. Then you have staging, and once again, this is that holding pen until you’re ready to add it to the history books. And then you have your third environment or where you commit things, and this has now been added as a log or an entry into the history books. Let’s say I want to remove this file from staging. Maybe I’m not ready to commit it. I could type in the command, Git restore –staged, and then index.htm. Now, once I press that, this moves that file back to my working files. So, if I were to commit now, this file would not be included because this file was currently in the working environment. So, let’s say that maybe you’re working on 6 files and let’s say that three of them you’re ready to commit. You can move those three to staging and then you could commit them and the files that are currently in the working files, those would not be included. The index.htm file is once again in my working files, but I do actually want to commit it. So once again, I could add it back to staging and then I could commit it from staging. But I could also just bypass or skip over staging altogether. To do that, let’s simply type in Git commit –a -m, and here I could say updated text to free range. Then I can close my quotes and now when I hit enter, this skips over the staging step and it’s now committed this change. Here within my git repository, I have one file called Secret Recipe and I definitely don’t want that falling into the wrong hands, so I should probably just delete the file, and I can do that directly through Git. I could type in Git rm, rm for remove and then I could type in the file name Secret Recipe.htm and then close my quotes. But an even easier way to do that, just directly in File Explorer, I could also delete the file right here and now that file is gone. Back within the terminal, let’s type in Git status and then hit enter, and here Git recognizes that this file has been deleted and the reason why is this is one of the files that Git is tracking. On second thought, maybe I should keep this file. I personally haven’t memorized the secret recipe yet. And right up here, I see a helpful hint. If I want to restore this file, I could type in Git restore and then the file name. So, let’s test that out. I’ll type in Git restore, and here I’ll insert quotes and let’s type in Secret Recipe.htm and then close quotes and hit enter. If I go back to File Explorer, look at that, the file is now back. Now once again, this is one of the advantages of working with Git. If you’ve ever previously committed a file, you can always go back to a previous version, or you can recover that previous version if you need to. Similar to deleting a file if you want to rename a file, you can either do that directly in File Explorer, or you could do that back in the terminal. Let’s try renaming a file in the terminal. I’ll type in Git mv, and we’re using mv, and that stands for move, so we’re basically moving from an old filename to a new filename. Here, I’ll type in the original filename and that’s KCC logo.png and I want to move to the new name primary logo.png, then I’ll close my quotes and let’s hit enter. If we go back to File Explorer, here I can see that the file name has been updated. I want to add this change to the history books. Basically, I want to add an entry that says that this file name has been changed. I’ll type in Git commit -m and then here I could type in the message. So, let’s say we changed the file name of an image, and then I’ll close my quotes and here I could hit enter and that has now been committed. So far, we’ve made a number of different commits, or basically entries to the history book or the log. What if we want to review all the different commits that we’ve made? We could type in the command Git log and then press enter. And here we see all the different commits. Every single commit has a unique identifier. Here we also see the author and if you remember at the very beginning, we defined who the author is. So, I typed in Kevin Stratvert and then we also typed in an e-mail address. Then I could also see the associated date with this commit. So here at the top we go with the most recent, all the way down to the oldest commits and right here I can also see the text that I typed in as part of that commit. If I want a more abbreviated version of this view, I could type in Git log –oneline, and then I could hit enter and here we see an abbreviated version of all the commit history. Now looking at this commit history, I just noticed that I typed in this text incorrectly, and I could go back and commit again and then type in the text properly, but I actually just want to amend that text. Luckily, with Git we can do that. I’ll type in Git commit –m and here I’ll say changed file name to primary logo.png and then close my quotes and at the very end of this commit command, I could type in –amend and then press enter and that’s now amended that entry. Now here I could press the arrow up icon on my keyboard and I could go through all the different previous commands that I’ve entered. I could go up to Git log –oneline, hit enter, and here you see that that text has now been corrected, so that’s a really neat way that you can just go back and quickly amend a previous commit without having to submit yet another commit into the history books. I have all of these different commits, but let’s say I want to see what actually changed in these different commits. I mean I have some text here, but what if I want to dig into these specifics. Here I could type in Git log –p, and then hit enter, and here I can look through and see all of the different changes. Here for example, I can see in the most recent commit, I changed the file name to primary logo.png. And here I can see that I updated text to free range and if I press my arrow key down, here I can see what the original text was, and I can see what the new text was and if I press my arrow key down some more, here I can see my very first commit where I added all of these different files to the Git repository. To exit this view, I can press Q on my keyboard, Q for quit and that exits out of this view. Git log has all sorts of advanced capabilities. You could search for specific text. You could look for changes that happen before a certain date or even after a certain date. Now once again, as we looked at earlier, if you want to find out the full capabilities, you could type in Git help log and then hit enter. This once again opens up the manual for Git log, and here you can see the description and here you could go through to see all the different capabilities of how you could find specific changes in your commits. One of the great things about having this commit history is you can always jump back to previous commits. To do that you simply type in Git reset and then you can type in the hashtag. So here for instance, if I wanted to jump to updated text to free range, I could simply type in this value here and that would bring me back. Now of course, I don’t want to do that, so I’m going to remove this. You also have the option to modify what appears in the history book and also the order in which all of these commits appear, and you can do that using something called rebasing. Here I could type in Git rebase -i –root and then hit enter. This brings me into an editor. Here I see my three commits and then I have all of these different options to modify the way things appear. Once again, I can change the order. I can even merge together or squash two these commits. Now this is beyond the scope of this video today, but I wanted to let you know that this is possible. To exit this view, press the colon key, then X, and hit enter and that brings us back into the main terminal view. So far, we’ve been making all of our changes just directly to the main branch, but you can also set up additional branches. What is another branch? Another branch is basically a copy of your main branch, and it has all the same entries in that history book, but this allows you to go off and work on let’s say a feature or maybe you’re fixing a bug and you can make all your changes and it won’t affect the main branch. Once you’re satisfied with all of your changes, you can then merge it back into the main branch. This is also how software development typically works. You’ll have developers and maybe one’s working on a new feature. They’ll create a new branch to work on that new feature. Maybe someone else is working on a bug fix and they’ll create another branch to work on that bug fix, and once they finish all of their work and they’re satisfied with how it looks, they can merge that back into main. Here in File Explorer, there’s a file called Secret Recipe and this has the Kevin Cookie Company secret recipe in it. Now I probably shouldn’t be showing you this, but we’ve been working a bit together now and I trust you. Let’s click into this file. Here within the secret recipe, all of this looks pretty good, and this is a really good chocolate chip cookie recipe. But right down here I see that it calls out heating the oven to 500 degrees Fahrenheit. That’s extremely hot, and that would probably burn the cookies. I need to change this to 375 degrees Fahrenheit. Let’s create another branch to make this change, and once we’re satisfied with the change, then we can merge it back onto the main branch. To create a new branch, I’ll type in Git branch and now I can type in a name for this new branch. I want to update or fix the temperature. I’ll type in FixTemp and then press enter, so now we should have two branches. To confirm how many branches we have, I can type in Git branch and then hit enter and here I can see that there’s one branch called FixTemp and there’s another branch that we’re currently in called main. How do I know that we’re currently in main, right over here I see an asterisk next to main, indicating that this is the currently active branch. To switch into the other branch, let’s type in Git switch and then I can type in FixTemp and hit enter and here it says that we’ve switched to branch FixTemp. Once again, I can type in Git branch and then hit enter, and here I see that FixTemp is the currently active branch, and here I see the asterisks indicating that. I’ve opened up File Explorer and all of the files that you see here in the repository, these reflect the FixTemp branch. Now I want to edit the secret recipe temperature. I’ll take this file and I’ll drag it over into Notepad and here I can see the contents of secret recipe. Now once again, I want to change the temperature down here. Currently it says 500. Let’s change that to 375 and then click on save. Back now within Git Bash let’s check the status of this branch. I’ll type in git status and then hit enter. And here I can see that there is one modified file for secret recipe. We just updated the temperature so that makes sense. Now I want to commit this change to this branch. Just like we did before, let’s type in Git commit –a -m, and then here I’ll say updated temp for baking instructions, then I’ll close the quotes and hit enter, and that has now committed the change to this branch. Next, let’s switch back to main. Here I’ll type in git switch main, then hit enter. Here within File Explorer, because we switched back into main, all of these files reflect the current state within the main branch. So here if I click into secret recipe, here we’ll see that it still refers to 500 degrees Fahrenheit. We only changed it in the FixTemp branch, so we now need to bring those changes from FixTemp back into main, or essentially, we need to merge those changes in. To merge all of the changes back in, let’s type in Git merge -m and here we can type in a message for this merge. I’ll type in merge FixTemp back to main and then close my quotes. Then I also need to specify what branch I want to merge back into main. Here I’ll type in FixTemp and then hit enter and there I can see that the file has now been merged back into main. Here in File Explorer, in the main view, I can now click on the secret recipe and here I can see that the change has been merged in and here main is now referring to 375 degrees Fahrenheit for the oven temperature. Now that we’ve merged all of the changes from FixTemp back into main, we no longer have any need for that additional branch, and at this point, we can simply delete that branch. To delete a branch, let’s type in Git branch, then enter -d and then you can type in the branch name that you want to delete. I’ll type in FixTemp and then hit enter and that branch has now been deleted. Let’s type in Git branch and here I can see that I only have one branch left and that’s the main branch and that’s also the branch that we are currently in. Overall, this merge went pretty smoothly. Nothing had changed in main so it was really easy to bring our changes back in. But what if you create a branch and then you try to merge it back in but main has changed since you created your branch. In that case, you’ll have a merge conflict, so let’s see how that works. And first, let’s create another branch. Here I’m going to use a command that not only switches me to the new branch, but it also creates the new branch. I’ll type in git switch –c, the c will create the new branch and let’s call this one UpdateText and then hit enter. Once again, to confirm that we have in fact switched to a new branch, I could type in Git branch and then hit enter and here once again I can see that we have two separate branches and we’re currently in the UpdateText branch. Here in File Explorer, once again, all of the files that you see here reflect the UpdateText branch. I want to make some edits to the index.htm file. Here, I’ll take the file and I’ll drag it into Notepad so I can make some tweaks to it. Here we refer to the finest ingredients, but I think I’d prefer to say the best ingredients, and here I’ll save the index.htm file, and back within Git Bash, let’s now commit these changes. Here I’ll type in Git commit and then I’ll type in -a -m and here I’ll say update index text and then hit enter. Let’s now switch into main and we’ll make a change there as well. Here I’ll type in git switch main and then hit enter. Here in File Explorer, this now represents the main view, and here I want to make a similar change to the index.htm file. Here I’ll select the file and I’ll drag it over to Notepad, and here it refers to the finest ingredients. Let’s say maybe the most amazing ingredients and then I’ll save this file and close it. Back now in Git Bash, let’s commit these changes to main. I’ll type in Git commit –a and then -m and here once again I’ll say update index text and then I’ll hit enter. So, I’ve now committed this change to main. Let’s now try merging the changes from UpdateText back to main to see what happens. To merge UpdateText to main, let’s type in Git merge and then UpdateText, and let’s see what happens when we press enter. When I press enter, here I get an error message telling me that the merge failed and the reason why is that there are conflicts and right down here in the bottom right-hand corner, I can see that I’m currently in a branch called main merging. Let’s go back to File Explorer to see if I could resolve these merge conflicts. Here in File Explorer, I can see all of the files for the merging view, and if you remember, we had a merge conflict with the index.htm file. Here, I’ll drag that file into Notepad and here I can see some text that says head. Head refers to what’s the current reality or what’s currently in main and down below I could see the text that I’m trying to bring in from the branch UpdateText, and I could decide which one I want to keep. Now I want to keep the text from UpdateText, so here I’ll delete the head and here I’ll delete this portion and then I’ll save the file. Let’s go back to Git Bash. Back in Git Bash, I can now commit the change. Just like we’ve done before, I could type in Git commit –a -m, and then update text on index and then I can close my quotes and hit enter and that’s now updated that merge conflict. So that’s one way you can resolve your merge conflicts. And now that I’ve resolved that conflict, here I could see that I am now back in main. This should give you an idea of the typical flow that most people use in Git. You have some feature or bug that you need to work on. So first you’ll create another branch. Then you’ll go in and you’ll make all of your changes. Then you can merge it back into the main branch. And once you do that, then you’ll delete the branch that you were working on. Now that you understand the fundamentals of working with Git, you might be wondering, well, how do you work together and collaborate with others? So far, we’ve just been working with a Git repository that’s hosted on your local computer, but you can also host your Git repository in the cloud, and one of the most popular cloud repositories is called GitHub. Not only do they offer a cloud repository, but you could also manage your project. You could set up Kanban boards. You can track issues. You could assign features or bugs to different people. In a sense, it’s a social coding website. Let’s check out how you can get started with GitHub? First, we need to create a GitHub account. You could head to the following website. You can click on a link up above or also down below in the description. On the home page, type your e-mail address to kick off the flow for creating a new account. Once you finish setting up a new account, we can now create a cloud repo. Over on the left-hand side, you should see the option to create a new repo. Alternatively, you can also head to the URL GitHub.new and that’ll also drop you on the new repo page. Let’s click on this. You might be wondering, do I really need to create a cloud repo, especially if you just plan on working by yourself? Well, if you’re planning on working with a team, it makes sense to set up a cloud repo so you can all work together. But even if you plan on just working by yourself, by storing it in the cloud, if something happens to your local computer, you have a backup, and all of your repo files are safe. To set up a new repo, over here I need to enter in a name for this repo. I’ll type in KevinCookieCompany.com. Down below I could also type in a description for this repo. I’ll leave it blank for now. Here I could decide, do I want to make this repo public so anyone can come in and access it or do I want to make it private? If I make it private, I could assign different individuals access to my repo, so I could just work with a smaller group of people Down below I also have some other options. Here I could add a readme file. I could also add a gitignore file. Remember earlier when we were working with our repo, we manually created a gitignore file, but here you could just create one as you create your repo and down below you could also choose to add a license. Now all this looks good, let’s click on create repository. Now that we’ve finished creating our repository, here I see a quick setup guide. Right here, I can see how to create a new repository on the command line. Right here, I see the option to push an existing repository from the command line. We already have a repository on our local computer that we’ve been working with for most of this video. We can take that repository and we can push it into the cloud. So, let’s take this first command. Git remote add origin and then this URL. Your URL will be specific to your GitHub account. Let’s copy this and then go back to Git Bash. Within Git Bash, here you can right-click and you can paste, or you can press shift and insert to paste what we just copied. Right here, this is establishing a remote connection with GitHub and we’re calling this remote connection origin. That’s a common name that most people end up using, and here we can see what the address is that we’re going to connect to. Here I’ll press enter. Let’s now go back to the website to see what the next command is. The next command will set the target branch to main. Let’s copy this and then go back to Git Bash and here I’ll paste this in and then let’s run that command as well. Once again, let’s go back to GitHub and here we can now push all the contents from our local repository to the cloud. I’ll copy this and then let’s paste this in and once again, let’s press enter. And here I can see that my entire local repository has now been pushed to GitHub into the cloud repository. Back on GitHub, here I can click on the repository name KevinCookieCompany.com and check that out. Here I can now see all the files from my repository synced onto GitHub. That’s pretty cool. Right up here, I see that there’s currently only one branch, and I had another branch called UpdateText. If we go back to you Git Bash, I could also push through all of my branches. Here I could type in Git push –all, and that’ll push through all of my branches to GitHub. Let’s press that. And here I can see that it also passed through the UpdateText and branch. Let’s go back to GitHub. Here within GitHub, I can see now that there are two separate branches. I have my main branch and then I also have the other branch titled UpdateText. Now that we’re on GitHub, let’s take a look around to see what we can do. Here, I can click on my different files, so let’s say I click on my primary logo.png. Here I can preview what that looks like. Here I’ll go back. Right here I could also see what the last change or commit was for a specific file. So right here with the secret recipe, here I could see that we updated the temperature for the baking instructions. Here if I click on that, I could review what it was and what it was changed to. So here I could view that log or the git log of all of the changes. Back on the main screen, if I want to add additional files here, I can simply drag and drop them onto GitHub or I can click on add a file right up here. Let’s say I want to edit one of these files. Here I can click on the file name secret recipe and here I can click on this edit icon, and I can go through and make changes directly in here and once I’m all done, I could also commit directly on GitHub. Back on the main repository view over on the right-hand side, here I could edit details about this project. I could click on this settings gear, and I could type in a description, the website. I could enter various topics and here I could decide whether I want to include releases, packages, or environments directly here on the repository home screen. Up across the top of the page, we have all of these different tabs related to the project and the first one is called issues. Let’s click into this one. Issues is where you can enter in feature requests or maybe someone finds a bug. You could enter the details of that directly into this page. So, let’s say that on the homepage, I notice that we say that we get our sugar from India, but it turns out we also get it from the Philippines. So that’s a bug on our homepage. Right over here, let’s click on new issue. On the issues page, over here, I can give this issue a title, and let me type out we should call out that organic sugar comes from India and the Philippines. Over here I could also type in additional details or comment. Over on the right-hand side, I can assign this issue to someone. Now currently there’s no one else on my team, so I’ll assign it to myself just so I can keep track of this issue. Down below, I could also assign a label. I’ll click on the settings gear and here I can add a bug, but you have all these other labels as well. I’ll select bug. Right here I could also assign it to a project. I could also assign various milestones. And I’m all done entering in the details here, so let’s click on submit new issue. This has now successfully created an issue and the great thing in GitHub is, it’s a social environment so other people could come in here, they can leave a comment. We could discuss is this truly a bug that needs to be fixed and maybe what priority should we give it? We can have that discussion all right here within this page. Now I have this issue assigned to myself, so I should probably get to work and update our index page to also call out the Philippines. In the top left-hand corner, let’s click on the code tab, and right here I have my index file. I want to edit this. I’ll click on index.htm and over here let’s click on this edit icon. Within the edit view, right up here let’s change it so it wraps. So here I can see all the text on this page, and if I look right here it calls out organic sugar only from India. And of course, we also get it from the Philippines, so here I’ll say and the Philippines. Now I’m all done making my changes. If I scroll down just a little bit here, I could commit it directly to the main branch or I have the option to create a new branch for this commit and to start a pull request. So, what is a pull request? Well, I can start a new pull request and then this change has to be approved. So, especially if you’re working with others, you can have other people go in. They can make changes and then you can have them submit a pull request, so the change has to be reviewed by someone before you push it through to the main branch. I’ll give this new branch a name. I’ll call it IncludePhilippinesSugar and then click on propose changes. This has now successfully created a new branch called IncludePhilippinesSugar and now I want to submit a pull request. This is basically a request for someone to approve merging this back to main. Right down below, I can see the pull request details. It says update index.htm, but I probably want to be a little bit more explicit. I’ll insert a – and maybe include some text that says we should include Philippines as one of the countries that we get sugar from. All of this now looks good. Let’s click on create pull request. This has now successfully created a pull request so we could go through and have a discussion about the merits of this change and if everything looks good, we can then merge the pull request. Over on the right-hand side, there’s a section called development, and when I click on this settings gear, I can tie this change, or this pull request back to the original issue. So, here’s the issue that I called out where we missed calling out the Philippines. I select that and this is now tied back to that issue. Now if I merge this pull request, here I’ll confirm the merge. Not only will it merge this back into main, but it’ll also close out the corresponding issue. Let’s go up to the top of the page and click into issues and here you’ll see because I accepted that pull request or that change, it has automatically closed that open issue. Here if I click into closed, here I could review that bug that came in and look at that we’re getting work done. That one is all done. Up at the very top, there are a few more tabs. There’s one called actions, and this is where you can run different tests. You can basically write programs to manage your repository. There’s another tab called projects, and this is basically a project management view where you can view all of your issues, view all your pull requests, you can filter the different views. It makes it really easy to manage your project. There’s another tab called Wiki, and this is where you can document your code. It’s kind of like Wikipedia, but for your project. There’s another tab called security, and this is where you could manage all of your different policies. You can define what should happen when let’s say a vulnerability is discovered. You could also set up scanning, if that’s what you want. There’s another tab called insights, and this is where you can see,well who’s contributing to your project. What does the traffic look like? How many issues have been closed? How many commits have there been? How many people are contributing? You can view all of that right here. And lastly, there’s another tab called settings, and this is where you can configure various settings related to your project. Over on the left-hand side, if you click on collaborators, here’s where you can add additional people to work with you on your project. Let’s go back to the main repository view and over on the right-hand side, we can also create a release. Now this is V1 of our website. Let’s click here on create. And here I can choose a tag. Why don’t we call this release. And here I’ll select that. And here I could give it a release title. I’ll title it V1.0.0. This is just the first iteration. Over on the right-hand side, you can see some suggestions for how you should name your release. Now this all looks pretty good, let’s click on publish release. And look at this, we now have V1 available and here anyone can now come in and they could download the source code for the KevinCookieCompany.com website. Now you might be wondering, we made a few changes in GitHub on the cloud, but how do we get those changes back onto our local computer? Well, there are a few different commands that we can use. First, we could use Git fetch, and this will download all the history from the remote tracking branches. And to merge that in we could type in Git merge and that’ll now merge it in with what we have on our local machine. But instead of typing in those two separate commands, we could also type in git pull, and then I’ll hit enter and this will download all the files. So, it basically combines fetch and merge into just one command, git pull. All right, well hopefully now you have a strong understanding of how you can get started with both Git and also GitHub. To learn more, I’ve included some fantastic resources down below in the description. To watch more videos like this, please consider subscribing and I’ll see you in the next video.