Weather Forecast has now been on our site. Check it out!

Lesson-1: Set Up the Project

📖 1.1.1. Introduction

Welcome to the beginning of your journey to becoming a full-stack web developer! During the next week, you’ll learn three web development technologies that are fundamental to your success as a web developer: HTML, CSS, and Git.

You'll learn these skills by building a webpage for Run Buddy, a company that matches runners with personal trainers. Run Buddy is launching a new landing page to attract more sign-ups, and they need someone to build it. A friend who works at Run Buddy put in a good word for you, and the company has agreed to hire you as a freelance web developer. Your job is to make the Run Buddy landing page look good, and then hand it off to Run Buddy's internal developers to complete the data collection portion.

In this first lesson, you'll learn about some important tools and processes, which is the first step towards writing that first line of HTML code. Specifically, you'll accomplish the following:

Navigate through folders and create files from the command line.
Set up the basic structure of an HTML document.
Use Git to save your work and push it to a remote repository.

📖 1.1.2. Preview

Let's peek at what we'll build this week. The Run Buddy design team has provided a mock-up of the landing page, which is shown in the following image:

IMPORTANT

You'll refer to this image frequently as you work on the Run Buddy landing page, so consider downloading it so you don't have to search for it. To download it, right-click on the image above, select "Save Image As", then choose a location for the file on your computer that will be easy to recall in the future.

As a new developer, you might think that this mock-up looks pretty daunting. Don't worry—we'll approach it step by step. Web development technology changes rapidly, so even seasoned developers often need to learn new tools when they start a project. As you'll come to see, a big part of becoming a developer is learning how to learn.

To succeed this week, focus incrementally on each task at hand, and reach out to your class support system if you have questions. You'll be amazed at how it all comes together in the end!

For this first lesson, all we need to do is buiLd the layout shown in the following image:

To accomplish this, we'll follow these steps:

Get started with the command line. We'll learn some basic commands to set up the file structure for the project.
Add a little HTML. We'll create the main HTML file for the project and learn some important HTML elements.
Get Git. We'll learn the basics of the Git version control tool, and use it to create a repository for this project and make the first commits.
Outline the page. We'll dive a bit deeper into HTML and plan the basic structure for the project.
Revisit the Git workflow. We'll commit the progress to the local Git repository.
Publish with GitHub. We'll publish the local repository to GitHub Pages, where it can be viewed by anyone in the world!

Let's jump right in and start coding!

📖 1.1.3. Get Started with Command Line

In the old days, entering text-based commands on a black screen (known as the command-line interface (CLI) or terminal) was the only way to interact with a computer. With the advent of graphical operating systems like Windows and macOS, that all changed. Now, most people never have to even look at a CLI. But developers still frequently use it for many tasks.

For now, we'll use the CLI to set up the project. Before we can do that, we need to figure out how to access it.

Access the Command Line

Follow the directions for accessing the command line based on which operating system you're using.

macOS Users

macOS has a built-in Terminal app, which you can launch by searching for "terminal" in the Spotlight Search. To access the Spotlight Search, click the magnifying glass icon in the top-right corner of your screen, or press Command+Space on your keyboard.

Windows Users

You installed Git Bash as part of the prework. Open Git Bash by searching for "git bash" in the search box in the bottom-left corner of the Windows screen or by using the keyboard shortcut Windows+S.

Use the Command Line

When you open the command line, you should see a window that resembles the following image:

In this window, type pwd and press Enter. The pwd command stands for "print working directory." In this context, print refers to displaying something to the screen. The working directory refers to the directory (aka folder) that the CLI is currently in. Thus, typing pwd is like asking, "Where am I?"

IMPORTANT

To succeed in this boot camp, type out every line of code instead of copying and pasting it. This will quickly build the muscle memory you need to become an expert coder.

When you first open Terminal or Git Bash, the default location is your user directory on your local machine. You can confirm this by typing pwd. When you do, the command line will display something like /c/Users/<your-username> on Windows, and /Users/<your-username> on macOS.

Now let's look at the contents of this directory using another command: ls. This command lists the files and folders within the current directory. If pwd is like asking, "Where am I?" then ls is like asking, "What's here?"

After you enter ls, you might see folders like Documents, Pictures, Music, and Desktop in your user directory.

NERD NOTE

The graphical "desktop" you see when your computer starts is the Desktop folder in your user directory!

Let's navigate to the Desktop now in the command line by typing the following commands, pressing Enter after each line:

cd Desktop

pwd

PAUSE

What do you think cd stands for?

Change directory.

The cd command allows you to move in and out of directories. With that in mind, try the following commands, noting what pwd prints each time:

cd ..

pwd

cd Desktop

pwd

So cd .. took us back a level (or "up" a directory). Make a mental note of that!

Now that you've returned to the Desktop directory, run the command ls. Do you recognize the listed files and folders as things that are already on your desktop?

Let's add to the clutter by creating a new folder! Type the following commands, pressing Enter after each one:

mkdir projects

The mkdir command creates a new folder. Folders are also known as directories, so the command literally means "make directory." In this example, we used mkdir to create a folder called projects. The second command, ls, helps us verify that the folder was created.

SHOW PRO TIP

You can clear anything that you just typed into the command line by typing clear and pressing the Enter key. Clearing the contents won't undo your work, but it will keep your command-line interface from getting cluttered and hard to read.

Now try something neat: minimize the command line and look at your computer's desktop again. You'll see something like the following image, depending on your operating system:

Do you see the projects folder you just made? There you have it—what you do on the command line has direct consequences on your computer! This projects folder is where you'll keep all of your work throughout the coding camp.

From the command line, let's navigate into the projects folder and create another folder for the Run Buddy project. Run the following commands:

cd projects

mkdir run-buddy

cd run-buddy

pwd

If you were to run the ls command inside the run-buddy directory, nothing would happen, because currently there are no files to list.

Let's go ahead and make a few files using the touch command, as shown in the following code:

touch hello.txt

touch index.html

We use the touch command to create files. Here, we've created two new files: a text file (hello.txt) and an HTML file (index.html).

Be sure to use lowercase for the file names. A file named index.html would be an entirely different file than one named Index.html.

IMPORTANT

Be sure to use lowercase for the file names. A file named index.html would be an entirely different file than one named Index.html.

On second thought, we don't really need that text file. So let's (permanently) remove it by using the rm command, shown in the following code:

rm hello.txt

Of course, you could also accomplish all of this with cursor clicks and menus. But in time you'll find that the command line allows you to work much faster. Plus it'll make you feel really cool!

Let's recap. So far you've learned the following commands:

pwd: Print working directory.
ls: List files in directory.
cd <directory-name>: Change to directory.
cd ..: Go back (or up) a directory.
mkdir <directory-name>: Make a new directory.
touch <file-name>: Make a new file.
rm <file-name>: Remove a file.

DEEP DIVE

Search the internet for these other useful commands to learn what they do:

cp
mv
rm -R
open . (macOS)
explorer . (Windows)

Now that we've learned our way around the command line, we're ready to add some HTML.

📖 1.1.4. Add A Little HTML

HTML (Hypertext Markup Language) is the underlying structure of any webpage. Every piece of the Run Buddy mock-up—including the header, sign-up form, and trainer images—is contained in an HTML element. And all of it will be contained in the index.html file that we just created.

We could open only this single index.html file in a code editor, but eventually the Run Buddy project will contain multiple files and folders. So let's open the entire run-buddy folder in Visual Studio Code (VS Code).

You can open the entire project in the following ways:

Drag the folder into VS Code.
In the VS Code menu, you could select File, then Open Folder.
To open VS Code from the command line, type the command code . in the run-buddy directory. (The . syntax means "this directory".)

macOS users might need to enable the code command first. To learn how to do that, refer to this article on launching VS Code from the command line.

Click on the index.html file in the Explorer on the left to load it in the main panel on the right. You should see something like this image in VS Code.

VS Code has a built-in terminal. To open it, right-click anywhere in the Explorer menu on the left and select Open in Terminal. Windows users: the default VS Code terminal is Powershell, not Git Bash. To learn more, refer to this article about how to use Git Bash in VS Code.

You don't have to use the VS Code terminal over Git Bash or Terminal; it's just a nice option.

Now we're ready to code! Type (don't cut and paste!) the following code in the right-hand panel in VS Code:

<!DOCTYPE html>

<head>

<title>Run Buddy</title>

</head>

<body>

<h1>RUN BUDDY</h1>

What We Do

</body>

</html>

Awesome! You just created your first webpage! Before you can view it in a browser, you need to save the file. You'll know the file hasn't been saved if a white dot appears in the tab next to the file name, as shown in this image.

Using keyboard shortcuts for actions you frequently take is a great time-saver. Saving a file is something you'll do many times a day—if not many times an hour! To save a file in Windows, press Ctrl+S. In macOS, press Command+s.

Now open this HTML file in Google Chrome. If you have the Open in Browser VS Code extension.

installed, you can simply right-click anywhere in the HTML file and select "Open in Default Browser". You can also click File > Open File from the browser's menu and then choose the file.

The webpage should now look like this image.

Okay, so it's not the most exciting webpage in the world, but you have to start somewhere!

Introduction to HTML Elements

Let's back up and explain in more detail what we just wrote. Notice that a lot of the code was composed of elements that are made up of an opening tag (for example, <title>) and a closing tag (for example, </title>). Anything that is between those tags is affected by what that element signifies.

The <h1> Element

The <h1> element is a "level 1" heading element, so it makes the text inside it big and bold. If we have other less important headings on the page, we can use the heading elements <h2>, <h3>, and so on.

♦ Deep Dive: To learn more, refer to the MDN Web Docs on HTML section heading elements.

Try changing <h1>RUN BUDDY</h1> to <h2>RUN BUDDY</h2>. Save the file and refresh the tab in the browser. Notice how the text shrunk slightly.

★ Pro Tip: You can quickly refresh a web page in Chrome by typing Ctrl+R in Windows, or Command+R in macOS. This reloads the page you're viewing. You'll be doing this a lot in this course!

Also make a note that this change only affected the "RUN BUDDY" text. Why do you think that is? It's because the element was closed. If you remove the closing </h2> tag, the text that follows "RUN BUDDY" would also be big and bold because the browser wouldn't know where the <h2> content ends.

Now change it to an <h3> and observe again how the text shrinks.

The <html>, <head>, <title>, and <meta charset> Elements

With this new understanding of HTML elements, let's look at the others we used in index.html. We're writing an HTML page, so it makes sense that everything would need to be contained in an <html> element. The only thing that didn't go inside this element was the <!DOCTYPE html>. This is an extra line that tells the browser how to interpret your HTML code.

♦ Deep Dive: To learn more, refer to the MDN Web Docs on quirks mode and standards mode.

Inside the <html> element, the webpage is further divided into two other elements: <head> and <body>. The <body> is where all of the content should go. Basically, everything in the mock-up will go here. The <head>, on the other hand, is where we can provide anything else the browser needs to know about the page.

For example, the browser wants to know what to call this webpage. The <title> element inside <head> tells it to call it "Run Buddy." Whatever is in the <title> element will become the name of the browser tab or window, as shown in this image.

Try changing the title in the HTML file. Save the file and then reload the page in the browser to see the change.

Before we move on, let's make sure we understand what we've done so far by taking a quick assessment:

♥ Quizz-1.1 💯

There are two remaining pieces we haven't covered yet. You might've noticed that the opening <html> tag was actually written as <html lang="en">, which specifies the default language for the page. In this case, we're letting browsers know that this page is meant to be read in English.

Lastly, there's an element in the <head> that looks like this: <meta charset="UTF-8" />. This is an example of a meta tag, of which there are many. Like <title> elements, meta tags give the browser extra information about the page, sometimes for display purposes and sometimes for search engine optimization. We'll discuss these more in future modules.

♦ Deep Dive: To learn more, refer to this HTML meta tags cheat sheet.

The charset meta tag is important to include because it specifies the range of characters (letters, numbers, symbols, etc.) that can be used. UTF-8 accommodates just about any character, from foreign language symbols to emojis.

Try this out for fun: Copy this emoji (🏃) and paste it somewhere in the <body> of index.html. Note that it shows up just fine in the browser. But if you change the meta tag to <meta charset="ASCII" />, it no longer works. Why do you think that is? It's because the browser then limits the available characters to those of the ASCII character set, which does not include emojis. Best to stick with UTF-8!

♦ Deep Dive: To learn more, refer to this W3C article on character encoding for beginners.

The good news is that much of this is boilerplate, meaning that every webpage will start with this same structure. Every page needs a DOCTYPE, an <html> element, a <head> element, etc. It's worth typing out again and again just to reiterate their importance, but it can also be copy/pasted into future projects without harm.

Pay attention to how we've been organizing code in the HTML file. New elements were put on a new line, and whenever a element was inside another, we indented the code. You could choose to write your HTML like the following example:

<!DOCTYPE html>

<head>

<title>Run Buddy</title>

</head>

<body>

<h1>RUN BUDDY</h1> What We Do

</body>

</html>

The browser would still render it correctly, but it is difficult to make sense of. As you write code, make sure it is as legible as possible. This benefits other developers who work on the project, as well as yourself when you return to work the next day having totally forgotten what you were doing!

📖 1.1.5. Introducing Git

This is a good time to introduce another important aspect to managing codebases: version control. One of the most popular version control systems is Git.

Git allows you to create "save points" (known as commits) of your work. It's good practice to commit your work whenever you reach a logical stopping point. This creates a history of changes and allows you to revert to an earlier version if necessary.

☕ Note: As a software developer, you'll hear the term production a lot. This refers to the live version of your app or website that users are currently using. Sometimes bad code can make it to production. When this happens, the best course of action is to immediately undo it. With Git, an older (working) version of the codebase can be pushed to production while developers investigate what went wrong with the new version.

Git allows you to push commits to a remote location so you won't lose any work if your computer gets run over by a bus or struck by lightning. This also lets you easily switch between computers while working on the same code.

Git also facilitates working on a team, which is common in software development. Without Git, it would be extremely tedious for developers to share code and work on the same app without accidentally losing or overwriting each other's code.

Using Git, developers can create alternate versions of the same codebase (called branches). When they're ready to merge these branches, Git will point out any conflicting lines of code and give developers a chance to fix the overlap. Pretty nifty stuff!

♦ Deep Dive: To learn more, watch this Git Basics video from the Git team.

We'll be honest—learning Git is tough. It's okay if things don't click right away. You'll have plenty of opportunities to practice Git in the coming weeks. By the time you complete the coding camp, you'll be very familiar with the environment and workflow!

Create a Run Buddy Git Repository

Let's turn Run Buddy into a Git repository, which is basically a project folder with version control capabilities.

⏰ Important:

By default, our local Git configuration has the default branch set to master. To stay in sync with GitHub, which now sets the default branch to main, we need to change our local Git configuration to use main as the default branch. We'll touch upon this a bit more later in the lesson.

If you're using macOS, before you set the default branch to main, you must confirm that you're using Git version 2.28 or later. To do so, run the following command from the command line to install the latest version of Git:

# only macOS users need to run this command; Windows users do not need to do this

brew install git

For both macOS and Windows users, to set the default branch to main, run the following command:

git config --global init.defaultBranch main

If the command executes successfully, no confirmation message will appear; it will simply return back to the command-line prompt.

At the command line, make sure you're in the run-buddy directory and then type the following command: git init. The command line should print (display) something like Initialized empty Git repository. If your computer doesn't recognize the git command, make sure you've installed Git from the Git website.

It might not seem like much happened, but this created a hidden .git folder in the run-buddy directory that designates it as a Git repository. If you want to verify for yourself, run the command ls -a, which will list any hidden files and folders as well as normal files. A file or folder starting with . is hidden. We can conclude that the .git folder is marked as hidden because it's probably not something we should be messing with!

Try Some Git Commands

Now that we've created a Git repository, we can use Git to track versions of our codebase in this folder. First, try typing the command git status, which should display the information shown in this image.

⏰ Important: macOS users, if you see a .DS_Store file in there as well, ignore it for now. You'll learn more about this file later in this lesson.

The git status command is a great way to quickly check which files have changed since the last time you saved, or committed, your work. Granted, we're just starting out, so there's not much to see yet. But notice that Git has listed index.html under Untracked files. The thing about Git is that it only cares about files you tell it to care about—in other words, files you tell it to track.

Well, we definitely care about index.html, so let's add it to Git's tracking. To do that, type the following in the command line:

git add index.html

git status

The git add command is another important command that moves any new files or changes to staging. Think of it like the process of getting actors ready to go out on stage. The show hasn't started yet, but we need to round up who is going. In Git terms, we haven't saved or committed anything yet; we've just prepped Git on what could be committed.

⏰ Important: The git add command shouldn't display any output and should just return you to the command-line prompt, so don't worry about not seeing any feedback from the command. If something goes wrong, Git will let you know.

Make Your First Git Commit

If you run git status again, you'll see that index.html now falls under Changes to be committed.

Make that commit now by typing the following:

git commit -m "page template"

git commit takes everything in staging and commits it. The -m "message" part of the command contains a short description of the commit.

★ Pro Tip: Every commit needs to include a message to explain what the particular change to the code is doing. If you neglect the -m "<message>" portion of the command, you'll be entered into a prompt that's hard to escape!

On your first commit, Git might ask you to identify yourself, as shown in this image.

This is normal. Just run the commands that the terminal is suggesting (git config --global user.name "Your Name").

If you needed to do this step, you'll also need to run the git commit -m "page template" command again. You'll know you succeeded if the terminal prints something like what appears in this image.

Great! You made your first commit! That was a lot to take in, so let's go through the process again.

Make Another Commit

Now let's try making a change to the index.html file. Change the content in the <body> element to look like the following HTML:

<body>

<h1>RUN BUDDY</h1>

What We Do What You Do Your Trainers Reach Out

</body>

Now run git status. Git will recognize that the index.html file has been modified but the changes are not staged for commit.

The command line should now look like what's shown in this image.

If we want to commit this change to Git, we'll need to use the git add command to add it to staging first. To do that, type the following commands:

git add index.html

git commit -m "add more link text"

With two commits done, run the command git log. This shows a history of all of the commits made, including the author of the commit and the message that was provided. The output should resemble this image.

⏰ Important: To "quit" out of the window git log takes you into, simply press the q key on your keyboard!

Can you imagine how useful this will be when you start working on larger apps with other developers? Very useful indeed!

Take a quick assessment to help make this new knowledge stick:

♥ Quiz-1.2 💯

📖 1.1.6. Outline the Page

We'll have a chance to practice Git again before we're done, but let's jump back into building the HTML.

Remember the design mock-up for the landing page that Run Buddy gave you? Let's review it one more time. This image shows the mock-up provided by Run Buddy.

It might feel daunting to turn all of those colors and perfectly positioned titles and images into raw HTML. That's why this step—outlining the page—is hugely important.

As developers, we must resist the urge to start coding without a plan of attack. HTML can easily get out of control if we don't consider how elements fit together. But what's nice about HTML is that it's really just a series of boxes that fit inside of or adjacent to each other.

In this image, consider the code on the left and its visual representation on the right.

We're using <div> elements here, which are like containers, to hold relevant information together. Note that Box 1 and 2 don't overlap; they're two separate areas of content. It makes sense, then, that <div> stands for "content division." Maybe Box 1 is an annoying ad and Box 2 is a navigation bar.

Inside these boxes, we can have additional boxes, like an overall list (Box 3) that contains individual links (Boxes 4 and 5).

Could we have omitted Box 3 in this example, and allowed the link in Boxes 4 and 5 to be inside Box 2? Probably, but it helps to keep similar content grouped together. Thus, Box 3's sole purpose is to better organize smaller pieces of information.

Let's take a piece of the mock-up image and think about how we could break this down into logical boxes or containers. Consider this image.

Note that the purpose of some containers isn't immediately apparent because they do nothing but hold other containers. It's okay if this doesn't feel intuitive yet. The more apps you build, the better you'll get at mapping their layouts.

This is as good a time as any to practice, so grab a pen and paper and sketch out the rest of the mock-up on your own. Take this step seriously! Stepping away from the computer screen and applying a physical touch to the development process can help shed new light on a problem.

This image shows how we sketched out one of the later sections.

Keep your hand-drawn outline close by as you continue. If your outline doesn't 100% match with the code we end up writing, that's fine. There's always more than one way to build a webpage!

We've discussed the <div> element a little bit. With that in mind, you might be tempted to reorganize your code to look like this:

<body>

<div>

<h1>RUN BUDDY</h1>

</div>

</body>

And that's actually a great start. We know the company name and navigation links will sit inside a larger teal box, which can be represented code-wise with a <div>. The problem with the <div> element is that it's a little too generic.

If we had a complex layout with a lot of <div> elements everywhere, it would be hard to know at a glance what the purpose of each one is.

The following code shows an example of what that could look like:

<div>

<div>Search</div>

<div>

<div>John Smith</div>

</div>

<div>

<div>

<div>Message 1</div>

</div>

<div>

<div>Message 2</div>

</div>

With the advent of HTML5, semantic elements were introduced to help provide clarity around what would have traditionally been just another <div>.

Consider this rewritten example using a sample of the current code:

<body>

<h1>RUN BUDDY</h1>

</header>

</body>

♦ Deep Dive: To learn more, refer to the MDN Web Docs on HTML5.

Is there any ambiguity about what this block of code represents? Nope! It's a header, and we defined it as such by using the HTML5 <header> element.

On a technical level, a <header> behaves exactly the same as a <div>. Its purpose is simply to convey meaning, not only to developers reading the code but to search engines that like to know which sections of a webpage are more important than others.

We have another clearly distinct section in the layout at the very bottom: the footer. It's no coincidence that there's a semantic element for that:

<h2>❤️ Made with love by Run Buddy.</h2>

</footer>

Even though there are dozens of semantic elements available to us, it might be harder to find appropriate matches for the rest of the layout. The large image at the top is sometimes referred to as a "jumbotron" or "hero," but there's no <jumbotron> element in HTML.

If none of the existing elements make sense, there's no harm in falling back on a good old <div>. At the very least, though, we can think of the layout as having several key sections.

⏰ Important: Remember to type out every code snippet in this lesson instead of copying and pasting!

Hey, what do you know, there's a <section> element! Let's go ahead and outline all of the sections in the index.html file by making the HTML between the <body> tags look like the following code:

<h1>RUN BUDDY</h1>

</header>

</section>

</section>

</section>

<h2>Meet The Trainers</h2>

</section>

<h2>Reach Out</h2>

</section>

<h2>❤️ Made with love by Run Buddy.</h2>

</footer>

★ Pro Tip: You might have noticed something new here: the  element. This allows us to leave notes, or code comments, in the code. These don't show up in the browser but make the code easier to read.

Save, refresh the browser, and admire your efforts in the browser. You should see something like this image.

Okay, it's still not very pretty, but we've laid some important groundwork that will make the next several steps easier to complete.

Before we move on, let's make sure we understand what we've done so far by taking a quick assessment:

♥ Quiz-1.3 💯

📖 1.1.7. Save Your Progress with Git

As you get into a comfortable workflow, you'll want to commit to Git often. This ensures that you don't accidentally lose any work, and gives you a "save point" that you can potentially revert back to. We just finished an important milestone: outlining the high-level structure of a webpage. This is the perfect time to commit!

Create a Gitignore File

Before we commit, though, let's create another file in the project:

touch .gitignore

We use the .gitignore file to specify any files we don't want Git to track. Developers often get into the habit of running a Git command that will automatically commit all of the untracked or modified files in a project folder. Though this is convenient, it can cause unwanted files to get committed.

For example, on macOS, every directory has a hidden .DS_Store file that can create unnecessary headaches if it is accidentally added to Git. macOS users may have already noticed that Git continually points out this file. Windows users, you can simulate the .DS_Store problem by creating your own .DS_Store file with the touch .DS_Store command (yes, go ahead and do that now!).

⏰ Important: If you have a Windows computer, it's still a good idea to add .DS_Store to your .gitignore file, because you never know when you might work with someone who uses macOS.

Now that everyone has this file in their project, open the .gitignore file in VS Code and add the following line: .DS_Store. Save the file, then run git status, which should display information that resembles this image.

Note that Git has now ignored the .DS_Store file. It also sees one modified file (index.html with the new semantic elements) and one new, untracked file (.gitignore).

Let's add both of these to staging at the same time, using ONE of the following commands:

git add .

git add -A

How do you know which one to use? Here's how they differ:

git add . adds any untracked or modified files in the current directory (the current directory is represented by .) and all subdirectories.
git add -A adds any files in the entire project.

Both are useful when you need to stage multiple files at once but should be used carefully and not without a .gitignore file in place first!

With these changes staged, let's commit now by typing the following command:

git commit -m "html outline and gitignore"

📖 1.1.8. Publish with GitHub Pages

Awesome—all your hard work is now saved to Git! There is one problem, though. These commits only live on your local computer. So if it were to die a tragic death at the hands of spilled coffee or a lightning surge, your work would be lost. The Run Buddy company would be pretty upset if that happened!

Wouldn't it be helpful if we could save this repository in a remote location for safekeeping? That's where GitHub comes in.

GitHub is a website that hosts Git repositories. It's free and very popular among developers, so make sure you have an account!

⏰ Important: A common misconception is that Git and GitHub are the same thing. Git is the version control software that you installed on your computer. GitHub is a service that lets you create Git repositories on the internet. There are other websites that perform the same service as GitHub, but the software on your computer (Git) wouldn't need to change to use them.

So how do we get the fledgling Run Buddy webpage into GitHub? The first step is to create a new, remote repository on GitHub. Then we'll link the local Run Buddy project with it.

After logging in to GitHub, click the "New" button, shown in this image.

This will route you to a page where you'll be able to create a new repository. Give the repository a name (run-buddy) but don't change any other options. Then click the "Create repository" button, shown in this image.

The next page will display a blue Quick Setup banner that includes a link to this repository. The link will look something like git@github.com:username/run-buddy.git if the SSH option is clicked, or https://github.com/username/run-buddy.git if HTTPS is clicked.

We want to use SSH, so select that option. This image shows how it looks with SSH selected.

⏰ Important: If you set up your SSH keys in the prework, you should definitely use the SSH option. If not, we highly recommend getting SSH to work before moving on. You can refer to this set of GitHub tutorials on using SSH.

Now that we've created a remote repository on GitHub, we need to link it with the local project. Copy the link from the website, then open the terminal again in the run-buddy directory and run the following commands, replacing the following link with the link you got from GitHub:

git remote add origin git@github.com:username/run-buddy.git

git remote -v

The second command, git remote -v, shows us which remote links, if any, we've established for the project. We could certainly add others—and later in the coding camp, we will—but the link to GitHub is all we need for now. Take note that we also named this remote link origin. That name is important, because we'll reference it when running the following command:

git push origin main

If you used the SSH link, Git will ask you to enter your SSH passphrase. The first time you try to push code to GitHub, your computer will also want to know if you trust this website, as shown in this image.

Type yes, because we do trust them. If you used the HTTPS link, on the other hand, you'll be asked to enter your GitHub username and password (every time you push to GitHub, which is why SSH is more convenient).

So what exactly did git push origin main do? The git push command sends any local commits to a remote location. In this case, the location is origin (GitHub), and we want to update the origin's main branch. For now, you only have one version of your codebase, and it's called main by default.

🌷Legacy Lore: Historically, the most common name for the main body of a codebase has been master. Recently, however, main has been gaining in popularity. In fact, GitHub now uses main as the default name for its repositories—as do the projects in this course, which is why we set our local Git default branch configuration to main earlier. Be aware that you might see instances of both throughout your development career, or hear experienced coders use the term "master branch" out of habit.

Go back to your GitHub repository in the browser and refresh the page. It should look like this image.

GitHub now has the two files and a record of the three previous commits! This means we could download this repository on another computer and continue working without missing a beat, or we could add other developers to the project and let them commit and push to this same location.

From now on, git push should become part of your normal Git routine to ensure that your changes always make it to GitHub. Try to memorize the following three commands:

git add -A

git commit -m "<message-that-describes-the-commit>"

git push origin main

GitHub comes with a lot of other helpful features like contribution stats, code reviews, and bug tracking. GitHub will also host your HTML projects as live websites, so you don't have to worry about paying for a separate hosting service like GoDaddy.

Let's flip the switch to make the current HTML project live. That way, we can show the project manager of Run Buddy our progress. On your repository's page, click the Settings tab, which is shown in this image.

On the Settings page, scroll down to the Pages tab on the right and click it, as shown in this image.

On the GitHub Pages screen, change the dropdown under Source to say "main branch", as shown in this image.

This tells GitHub to use the contents of your main branch for your live website. Once you do this, GitHub will then display the message: "Your site is ready to be published at https://.github.io/run-buddy/."

It might take a minute for this to actually kick in, so wait a moment before visiting this link (replacing "username" with your GitHub username, of course). When you do open it, though, you'll see that your Run Buddy webpage is now live on the internet!

And as we continue to improve this project and push new commits to GitHub, this live link will automatically update. Thanks, GitHub!

🍕 On the job! GitHub has become a vital resource to recruiters and hiring managers because it helps them see a candidate's recent activity, code samples, and thought process via READMEs. Keep this in mind as you build your GitHub presence.

Let's back up and look at this link again: https://.github.io/run-buddy/. Notice how it loaded the contents of the index.html file without us having to write https://.github.io/run-buddy/index.html, although that shows the same page, too. This happens because the index.html file is defined as a default by the server; this is universal on all webpages.

If you visit something.com/contact.html, for instance, the something.com server knows to send back contact.html because it was explicitly asked for. But if a file isn't specified, the server sends back index.html. Knowing this, make sure every project has an index.html file!

Before you move on to the next lesson, take a quick assessment to test your retention of the new skills you learned:

♥ Quiz-1.4 💯

📖 1.1.9. Reflection

This lesson mostly focused on setting up the foundational Run Buddy files and folders, Git workflow, and GitHub repo. Even though it might not look like much yet, just look at all you've done already:

The HTML structure is in place and ready to be filled in with more detailed content and styling.
You've established a good workflow with Git to continually save your code changes locally and on GitHub.
You have a live website on GitHub Pages that will begin to take shape as you complete the next several lessons.

During this lesson, you learned how to do the following:

Create files and folders by using the touch and mkdir commands.
Move in and out of folders by using cd and cd ..
Set up the HTML structure with <html>, <head>, and <body>.
Organize content with <div>, <section>, <header>, and <footer>.
Stage with Git by using the git add command.
Make commits with git commit -m "" and sending them to GitHub with git push origin main.

Next up, we'll continue to learn more about HTML while applying a much-needed visual makeover to the elements.

Believe or not, by the end of the module, you'll know everything you need to make beautiful websites beyond Run Buddy. But let's finish this landing page first!

Lesson Code Snapshot

Download the code snapshot for this lesson to compare with your own code. It’s okay if your code isn’t exactly the same—use this code snapshot as a starting point for the next lesson.

<<== Previous

Next ==>>

Page updated

Report abuse