The master version of our Hello World website is saved on the machines that we used to code the HTML file, hello-world.html. It is also being tracked by Git in the local
.git repository. When we want to publish our code to the world (or just save it on the cloud so we can access it from any device), we want to store it in a remote repository. In this lesson, we'll dive in to using GitHub to store our code remotely.
First, let's talk about the difference between local and remote. When we talk about a local repository, we mean one that is accessible only when using the device where it is saved. For example, the projects that you build on Epicodus machines have local
.git repositories. If you want to see your code on another device, you will not be able to access it. A remote repository is one that is saved in a location outside of your device but still accessible by it. We will be saving our code remotely to repositories on GitHub.
Let's copy our local
.git repository to a remote repository on GitHub now.
First, we need to create the remote repository on GitHub. Each pair partner creates a remote repository using their own GitHub account.
Once logged in, we'll select the New Repository or New button to go to the Create a new repository screen:
Let's walk through the options we need to complete for our new repository.
First, we enter the repository name that matches the name of our project directory. For this project, we'll enter "hello-world". Though the description is optional, it can be helpful to our future selves and anyone else looking at our repository to see a quick description of its content.
Since we are using free GitHub accounts, Public is the only option for our repositories. As it notes, everyone can see the contents of the repository but as the owner of it, you will be the only person who can determine what code can be committed to it.
The last option asks whether or not to initialize the repository with a README. A README file is a detailed description of the repository including information like authors, usage instructions and licensing. Do not check this box. We will be exploring what a README is and how we add it to our repositories in a future lesson.
With an empty repository awaiting our code, we can now follow the steps to push our code from our local repository to the remote repository.
In our project directory, we will make sure our code is working. In this case, we open it in the browser and it looks good. We also ensure that there aren't any outstanding changes that we still need to commit:
$ git status
Now we need to tell Git where our remote repository is by providing the web address. We'll use the
git remote command.
$ git remote add al https://github.com/epicodus-lessons/hello-world
This command tells Git to store information about a remote repository that we gave the nickname, al (the initials for one partner - Ada Lovelace) located at https://github.com/epicodus-lessons/hello-world. We could use any nickname for the remote but we've chosen al for brevity and to be consistent with the initials we are using as pairs.
Note that your command should contain the URL location for your GitHub repo. Ours is
https://github.com/epicodus-lessons/hello-world in the example above, but yours will likely differ.
To see that Git has done this successfully, we can run this command:
$ git remote -v al https://github.com/epicodus-lessons/hello-world
This shows us all the remotes stored in Git for this project. In this case, we only have one, with the nickname al.
To push our code, which means we are copying it from the local to the remote, we run this command:
$ git push al master
This indicates that we should push code to the remote with the nickname al from the master. We haven't used the word, "master", before but this is the name Git uses for the main Git repository on our local machine. In the future, we'll see that we can have many copies of a repository on our local machines all in different stages of development. The master is always considered the master copy.
For security reasons, only the owner of the remote GitHub repository is able to push code to it. This means that we need to enter our login information to confirm our ownership. Once entered, the code is copied to the GitHub repository and we can see it online if we go to our GitHub repository URL https://github.com/epicodus-lessons/hello-world. We can see the file structure and the commits in GUI form that we saw in our terminal.
So, how do we get our code back to our local from the remote? What if we push our code up to GitHub at Epicodus and want to work on it at home on our personal devices? To do this, we'll need to clone our GitHub repository on our local machines.
To practice this, let's delete our hello-world project directory and clone it again from GitHub. To delete a whole directory, we can't be in it so we'll go up a directory level and then remove it:
$ cd .. $ rm -rf hello-world
Poof! Gone. Now, if we want to copy it in the exact same location from GitHub, we get the URL for the remote repository and run:
$ git clone https://github.com/epicodus-lessons/hello-world
ls shows us our directory is there with our code file in it. Let's go into the project directory:
$ cd hello-world
If we do a
git log, we see that our commit history arrived with our directory and code.
If we run
git remote -v, we also see that our newly created local
.git repository is automatically linked - with the nickname origin - to the remote repository from which we cloned.
$ git remote -v origin https://github.com/epicodus-lessons/hello-world (fetch) origin https://github.com/epicodus-lessons/hello-world (push)
If we make changes to the code and want to push again, we would be able to use the origin nickname that came with the repository from GitHub (e.g.
git push origin master).
Note: only one location can be designated with the nickname "origin". So, if we clone one project but want to push to two different repositories, they cannot both be nicknamed "origin". That is another good reason to use your initials as the nickname of the remote repository.
Whew! This has been a mountain of Git concepts and terminology to explore. Don't try and memorize this information. Use the cheat sheets for reference to walk through set up and usage in your projects to come. Before you know it, it'll become ingrained in your daily workflow.
Be sure that you are not cloning a project inside of an existing local repository. In other words, you should not be inside of a project directory when you run the
git clone command. Otherwise you'll end up with one git repository inside of another.