Launch Your Websites with Github Pages

1. Introduction: Hey, guys, My name is Paris. I am a full stack Web developer based in New York City, and I've been working as a professional Web development instructor since 2016. Today I'm gonna walk you through a really simple process that's going to show you how to deploy static websites. So what Page is that you have been offering in HTML, CSS and JavaScript. I'm going to show you a quick and easy way to get those online so that anybody with a Web browser and with your girl can access them publicly. If you find this course helpful and you're enjoying what I'm doing, please leave a review. If you have any questions or comments, do share them so that I or the rest of the community can help you out on. We can all learn together. I really do encourage you to post your work so that future students can see what is possible after taking this course. And lastly, if you want to stay up to date with all the courses that I post in the future, just follow me on my instructor profile 2. Course overview: Alright, guys. So before we dive in, I just wanna show you exactly what we're gonna be making today. We're not really going to be writing any code. I've already written some code. If we look at my text editor, I have an HTML file that just has a button and I have a CSS file and I have a javascript file that. Well, when I click this, it pops up an alert box. Eso as you can see right here by looking at the address bar. This is this Web pages being loaded from my local file system and what we're gonna be doing today is figuring out OK, how do we go from local development to having the same thing on a really your l so that anybody with a Web browser and this year Earl can visit this Web page and see all of the same functionality 3. Initial setup: All right, So the first thing that we're gonna do is visit. Get hub dot com and we're going to sign up for an account. Obviously, if you already have an account, you don't have to do this. You can just use that account. But if you don't have account, if you're new to get Hub, just visit the home page. Click the sign up button that's going to kick off the sign up flow, and it's gonna ask you for your user name. Your email. Your password. As you continue, it's going to ask you to choose what account type you would like be that paid or free account. Um, going to suggest for now, just to go with the free account, it's going to mean that all of your code that you push up to get hubby is going to be public. However, in our case today for what we're trying to do, that's not an issue at all. If you choose Teoh, uh, pay, forget hub in the future. You can always make that change later on to have private repositories and make your code not publicly accessible. But for today, just to get things started quickly Why don't you go ahead and just sign up for a free account if you don't already have one, the second thing that I'm gonna have you to have you do after you, son. Afriat Hub is visit desktop dot Get hub dot com and we're just going to download, uh, the native desktop application. Forget, huh? That's going to make our lives a little bit easier in terms of communicating with get hub, we're not gonna have to use the command line to use get We're not gonna have to open up a terminal window for a lot of people that's going to make things a little bit more user friendly. Um, and it's just going toe Make this a little bit more of a quick learning experience. If you in the future wanted to dive deeper into get and use it on the terminal, by all means go for it. But for right now, we're just going to use to get Hub desktop client and make things as simple as possible release that we can just launch our Web pages and get them public, and we can go from there 4. Version control explained: All right, So now that we've got our get have accounts and we've downloaded the get have desktop client, we're going to talk about version control. We're gonna talk about get and we're gonna talk about get, huh? We're gonna go into a little bit of detail about what they actually are, how they're different and how they what role they play into what we're trying to do right now that is launch are our first websites so that they're publicly accessible. So version control is this concept of tracking changes to a project over time. Ah, good version control system will provide you with a way to take snapshots of your code base as you make changes. And then you can go ahead and inspect how your code looked at each snapshot. And if it has a rich set of features, a version control system should also allow you to time travel, if you will, between snapshots so that you can return Teoh previous versions of your code base regardless of what it looks like right now, as long as you did take the appropriate steps to make those snapshots in the past. So this right here is just a little diagram, a little visual representation of how a project might look over time and how version control actually works to create snapshots of a project as it changes over time. So if we look over here, uh, the green box indicates the entire project. You can think of this as the directory where all of my code files live. So for building html, see, as as a job script websites, you might guess that I would have an index dot html file in the root directory of my projects. My project folder is called my Project, and I have one file in here. It's called Index Study. She, Mel and I just have in each one tag that says, Hi there. I'm going to take a snapshot of my project at this time, and I'm going to say that this snapshot is snapshot one, and I'm going to give this snapshot a message on. I'm just going to say that the messages add first html file. After I take that snapshot, I'm gonna make some changes to my code base on. I'm going to add a main dot CSS file. This main dot CSS file is just going alter the color of H one tags. And once I have that file added and I have all of the the content of that file the way that I want, I'm going to take another snapshot. I'm going to say that this snapshot has an idea of two is the second snapshot, and I am going to give it a message that says, I added the first CSS file Then after that, once I have this this first snapshot in the second snapshot in my snapshot history, I'm going to change my code base again. And I'm going to actually just modify my index dot html file so that the H one tags are now p tags. And once I have this the way that I want it once all of the code has been modified and I think that things were looking good, I'm gonna go ahead and take another snapshot. That's going to be snapshot number three. The message for that is going to be that I edited the HTML file. So if you think about all of these snapshots, you know, at at the end of all of these changes, my code will look like it does in the third snapshot. That is the current version that I'm working on. However, the thing that is so powerful about version control is even though my H one tags air now p tags and I now have a main dot CSS file, I can always go back and reference what my code looked like at the first snapshot what my code looked like at the second snapshot. And I can also switch between any of these three snapshots as long as I I took the time in the past to take them. And that is in a nutshell. What version control is and why it's so powerful. You can imagine if you've been, you know, doing Web development for some amount of time that these files don't just have three lines in them. They could be dozens or hundreds of lines long. They could change every few hours every few days, and it could be really, really difficult to know or remember what you're could look like in the past. Which is why version control is so useful and why it's so powerful. So now on to get get is the most widely used version control system by far it's actually a command line program, meaning that you have Teoh know how to utilize the terminal or another command line interface. In order to use the raw get program. However, there are a lot of desktop applications get Hub desktop being one of them, the one that we just downloaded that allow us to utilize the power of get to some extent without needing to dive into the command line. So there are a few key phrases that we want to familiarize yourself with. Eso that when we talk about get and using get were on the same page. The 1st 1 is commit. Commit is just another word for one of these snapshots that we take any time we make a modification to our code that we want to save in our get history, we're going to take a commit, and that commit is gonna have a unique idea. And it's going to also have a message of the changes that we made a repository. A lot of people call them repose. Repository is just a collection of commits for a given project. So if you if you look at all of the commits for a project, you can get the entire history, and those are all stored inside of a repository. Ah, local repository is a copy of a repository that exists on your machine, your computer, your laptop, your desktop, whatever. A remote repository is a copy of a repository that exists on a remote server now on to get up. So it's very important to distinguish between get and get up, although they both have get in name. Get Hub is actually a company, whereas get is a program. Get is an open source project that was created by Linus Torvalds. Get Hub is a private company that charges for its services and tries to make the worlds of software development a lot easier. It is a cloud based SAS platform for hosting remote get repositories, and in our case it's going to be extremely useful in providing features for serving Web pages included in repositories that we host on get and this is going to be through a feature called Get Hug Pages. It also does a ton more stuff, and we can get into that later. But for now, we only care about these two things. Get Hub Desktop is the native desktop application that we just downloaded, and this is going to make it easy for us to sink our local repository on our computer with the remote repository that we create on Get. 5. Creating and cloning a GitHub repository: All right, So now that we have a bit of an understanding of what it is and and what get Hub is and how they play together, we're gonna go ahead and create our first get hub repository. So we go to get hope dot com in the knave bar in top. Right, there's this plus icon. We're gonna click that there's going to be a drop down with the new repository option. We're gonna click that, and that's gonna bring us to the page where we can create a new repository. So we're first going to select a name for this repository. I'm gonna call it Hello, World Website. Uh, make sure you don't have any spaces in the name. I'm going to leave the description blank, and I'm going to leave it as a public repository. I'm just gonna click the screen button and kick things off. So now it's created my repository on get, huh? But we don't have any code yet. Obviously we just created it, and it's giving us some options of how we might add some code from a an existing repository using some command line commands. However, today we're going to be using the get hub desktop client. So instead of using these options, we're going to click this button right up here. And that's going to ask us if we can open up the it have desktop applications. I'm gonna click that. And once we open this up, it's going to give us a few bits of information the first bit right here. This is the U. R L. To the repository, the remote repository that we just created on Get up. The second bit of information is the local file path to where this local version of the repository is going to live on our computers. So, as you can see, get Hub Desktop client creates this get hub directory in my Documents folder and it's just going to store this project in the Hello World Website directory within that get of directory. So this all looks great. I'm in a click clone and now you can see that this hello world repository has been added to my local get hub repositories directory and everything is linked up 6. Committing local changes and pushing to GitHub: all right. So in our last section, we created our first get home repository, and we cloned that repository to our computers so that we have a local instance of that remote repository. So if if we think about these two several repositories, they're kind of just copies of the same thing, they can become out of sync. But really, we want to keep them in sync. And that's what this get up desktop application is helping us do. So as we make changes on our local computer, we're going to sink them to the remote repository so that all of the code can be the same in both places. So first thing I'm going to do right now is open up finder, And I'm just going to show you what Get Hub desktop. Does it actually in your documents? Holder, if you're working on a Mac, I'm not sure how this works on the windows, But if you're working on a Mac in your Documents folder, it's going to create a get hub directory for you. And all of the repositories that you create or manage with your get up desktop application are going to be stored in this get Hub directory, you can change the default location. But this is where it will store things for you and where it will look for repositories if you don't change that default option. So as you can see here, since we just cloned the hello World website repository to our local machines, we have this hello world directory right here. And this is where all of our source code is going to go so that we can commit those changes and then send them up to the remote repository. So I actually have some starter code right here, and you guys can download the same starter coat below from the link. I'm just going to copy and paste this into here so that we can get up and running real quick. And when I do that, if we come back to the get hub desktop application, we can see that it has these three files that I just added. And it says that these air new files that have yet to be tracked that's what this green plus means so I can look through all of the files. Everything that's new is going to be in green, and this is all looking pretty good. I just have a JavaScript file. I haven't index dot html file and I have remained at CSS file. So I'm going to commit this and this is going to be my first commit. And the convention for your first commit is just to name it first commit, and I could give it a little description here. In this, they add index html I mean, not CSS and need dot Js files. And once I've added that message and the little description, I'm just going to click this button, commit to master, and that's it. I have created one of those snapshots that we talked about earlier. That version of my code has been solidified that it is now in the history for this. Get repository. Now, remember, that's all on my local git repository. None of those changes have been reflected yet. Get hub dot com. We come over here and we refresh the page. We can see that it still looks exactly as it did before. So we have Teoh push these changes up to get hub dot com. And we can do that just by publishing this branch right here. Click that button it's going to ask me to sign in. Obviously ups. Paris and my password don't peek great. Once I've signed in, it knows who I am. And it could make this connection. And it can sink this code up so that it when I refresh this page, all of my code is now here on get hub dot com. 7. Enabling GitHub Pages for your repository: All right, So now that we have sink tar code from our local repository toe a remote get hub repository , all we have to do to enable our website to be publicly accessible is go to the settings tab , scroll down to the section labeled get hooked pages, change this none. Drop down option to master branch and click this save button. Once we've done that, we can scroll back down. The page is gonna refresh, and it's actually going to give us a you, earl that we can visit to access our website. So if we click on this, we're probably going to get a 40 for well, actually not. So it updated for me pretty quickly. Sometimes they can take a few minutes to even a few hours, but as you can see right here I have this public girl that anybody can visit. And this is my web page. I can click on this. My job script is working. My CSS is working and it was really that simple. Back here, all we did was change one option on a repository and it just works. That's why we're using get hub and get up ages. Today because it really takes a lot of the headache out of deploying static page websites. And it makes life super simple again. Just gonna click this button. It's so satisfying, Great job. 8. Making changes after you've deployed: All right. So we've just seen how easy it is to author code on our local computers. Push it up to get hub, flick a switch to enable get her pages and then have a publicly facing website that's fully functioning with a really earl that other people can visit on their web browsers. How are we going to now make modifications change code and keep things up today as we continue to develop? Well, it's really just a simple as things were in the first place. I'm gonna open up my text editor and I'm just gonna do it really simple at it. I'm going to change the color of this button from pink. It's you, green. I'm gonna come over here to get up desktop. I see that there is one line that's been changed. I'm going to make this a commit so again, you can't push any changes unless there wrapped up in a commit or unless you take one of these snapshots. So I'm gonna make another commit. The message here is going to be changed button color. I don't have to add a description, but you always can. And then I'm going to click this button to commit. Once I do that, I can see that I have this little air over here and this little one with a narrow over here . This is indicating to me that my local repository and my remote repository are not in sync in that I actually have one commit that's ahead on my local repository, then my remote repository. So I'm going to click this button pushed origin, and that's just going to sink everything up for me. If I come back to get hub the page for my repository and I refresh, I can see that the latest commit is now changed button color instead of first commit. I can also see what files were affected by this. Commit. So the CSS file right here This was changed from pink to green. Great. Come back over here to my life site every refresh the page and it's great 9. Gochyas: All right, guys, that pretty much wraps it up for this video on how to utilize get up pages to deploy static websites. I'm just gonna go over a few gouaches that might give you a hard time If you don't know what you're looking for. The 1st 1 is probably one of the most common ones, and that is just not having a index dot html file in the root of your project folder. That means that in the very outer most level of your get hub repository, there has to be an html file called index dot html. That is the file that is going to be served as your route page for your website. You can't have it named anything else. It just has to be indexed on age. Now you can have a bunch of other HTML pages that you link to that are other pages of your site. But you have to have this one index dot html. Another problem that might arise is that you are making changes locally, but you, for some reason, can't push them up to get hub. It might be that you have not actually committed those changes. So remember we have to take those snapshots in order to push local changes up to our remote repository. So if you did not take those snapshots after a change, you will not be able to push those changes. Another thing that might be a little frustrating and confusing in the beginning. What you will very much get used to is the fact that code that you push up might take a few minutes even a few hours before it is live. So I used some movie magic in this video kind of speed things up. But there was a few minutes of delay between when I made some changes and pushed off to get help to when they were reflected in my life site. So hopefully this covers most of the road bombs that you might experience. If there are any others, please comment below. I will try my best to address any issues. If not me. Hopefully the community will help you guys out 10. Conclusion: alright guys, so that's pretty much it. As you can see, deploying static webpages with get hub and get pages is pretty straightforward. That was really my goal in this course was to deliver to you a method of deployment that has a low barrier to entry. Is that really all you have to do is focus on writing code and you don't have to worry about Dev ops or anything like that again. If you find this course useful and if you're enjoying what I'm doing, please leave a review. You can share this with anybody who, you might think also would benefit from the information. If you have any questions or comments, just share those as well so that either I or the rest of the communicate community can try to help you out. And lastly, if you have any ideas for courses you might want to see in the future, just let me know and I will try to make that happen. You can follow my instructor profile to see any courses that I post from here on and share your work so that you can inspire other students