Now that you have your keys in place, you're ready to start sharing your code with those third party
services.
In this video, you're going to get your code pushed up to the GitHub servers.
And in the next video, you'll get your code pushed up to Hiroku so your application can be deployed
to start.
Let's head over to GitHub Dotcom now.
You should already be logged into your account, as we did that earlier in the section.
On the left hand side, you'll notice I have a list of repositories.
These are projects that I've been working on for clients and for other classes.
What we want to do is create a new repository.
So we're going to have our local repository on our machine.
It lives in that dot get directory, which we explored earlier in the class.
We're also going to create a repository for the project on GitHub.
That is how GitHub is going to be able to get access to our code so it can show it in the user interface
and so we can do other great things like track issues and collaborate with others.
Now, creating a repository on GitHub dotcom is really easy.
There's a plus icon near the top right of the screen.
We click new repository and then we fill out a very simple form.
The only thing we need to do is pick a repository name.
Now, this does not need to line up in any way with the name you chose for your project locally.
You can pick anything you'd like as long as you're not already using it for a repo name on your account.
I'm going to go ahead and use Node three hyphen weather website.
Once again, you can pick whatever name makes the most sense for you.
Next up, we have an optional description, which I'll leave blank.
And then we have the option to create a public repository where anyone can see the code or a private
one, which you could use for private proprietary projects.
Now, in this case, you can stick with public as private does require you to be on a paid plan.
I'm going to switch mine over to private, though, so I can keep this project hidden from students
so no one will know I'm working on the course until the whole class is ready.
Once again, though, you can just leave yours as public.
Next up, we have an option to initialize our project with various things like a README file.
Again, ignore file or a license.
We're not going to do any of that.
We're going to move on to the next step, which is to create the repository.
So right here, when we do that, it's not going to be able to show us our repo code because there is
none.
GitHub doesn't know what code is associated with this project, so it's simply giving us some instructions
for the various ways we can get started.
We can create a new repository from the command line and send that to get hub.
We can push our existing repository up to get hub, or we can import it from some other version control
system.
In this case, the second option is what we want.
We already have a repository with commits locally on our machine.
We simply want to send it to the GitHub servers.
Now, there are two commands here to get set up, but before we run them, I want to explain what they
do so you can actually understand what you're doing right here.
We have the first command get remote at Origin, followed by a long U.
RL.
So to start, we are indeed using it like we've done from Visual Studio Code plenty of times already
and we're using remote to manipulate our remotes.
A remote is nothing more than a version of your project hosted somewhere else.
So we're going to have a version of our project hosted on GitHub, Dotcom's servers and on her Roku's
servers.
Next up, how are we trying to work with our remotes?
We're trying to add them.
For example, you could also use remove to remove a remote.
In this case, though, we don't have any.
So we're setting up our very first one.
Next up, we choose a name for the remote.
This value could be anything you like, but by default, your first remote should have the name Orjan.
This is a common convention you'll see across the Web.
After that, we have a nice, long, neutral.
This neutral contains two nice pieces of information.
It has our user name right here.
You should see your username and it has the name of the repository that you picked.
So right here I have the name that I chose.
Now, when we run this command, we're not actually sending our code to get Huub.
All this command does is it sets up that channel of communication.
You can think about it like adding a contact in your cell phone.
You pick a name for the contact and then you pick their phone number or in this case, the euro.
But we're not actually sending anything to them.
We're just setting that up so it can be used in the future right here.
We're going to take that command, copy it to the clipboard and from the terminal, we're going to run
it from the Web server directory.
Once again, it's important that you run these commands from the right location.
So I'm going to paste it in.
I'm going to run it.
And now we have a remote called Orjan, which we can push to, and that's going to send our code to
get.
As we add new permits, we will push those new permits up to get Hub, making sure that GitHub has the
latest code, that's where the second command comes into play.
We have get push with the new flag origin master.
So get once again is just the get command followed by push.
Push allows us to push our commits up to a given remote.
Then we provide the remote name Orjan.
Now Master is the default name for what's called the branch and get.
We're not going to get into branching in this course as it's a more advanced concept if you are interested
in diving into the advanced workflows.
And yet I recommend checking out a course on Udemy or checking out that free get book that I talked
about earlier in the class.
Hey, this is Andrew from the Future with a quick update right here.
You might notice that your branch name isn't master.
You're likely seeing Mayne instead.
So GitHub A recently changed the default branch name for a master over to the more descriptive main.
So now the default branch is your main branch.
Now, all that means for us is that when we run the command in just a few moments, we'll want to push
up to the main branch instead of pushing up to the master branch, which isn't going to exist for you.
If you try to push your limits to the master branch, you'll end up getting an error when you run the
command.
So in just a few moments when we run this command, we will instead push up to the main branch and will
continue to push up to the main branch throughout the class as we push our local commits up to GitHub.
And I'll jump back in in just a second to remind you when we run the command for the first time.
So once again, the only thing that's changed is the branch name.
It was Master, now its main.
So when I push to master, you push domain.
All right, let's jump back in.
Now, the EU flag allows us to set the upstream, which is essentially the default, and in this case
we are setting the default to origin, which is where we're going to push to the most.
So in the future, after we run this command, once we could just use get push to send our latest comets
up to get hub.
Sure, we'll be pushing to other remotes like Hiroku, but we're not going to do that nearly as often.
Now, we're not actually ready to run this command yet.
If we tried to run it, it would fail because GitHub isn't sure exactly who's sending it the code.
But we need to do is finalize our configuration.
So to get that done, what we need to do is take the public key file and give that to GitHub dotcom
so it can create that secure connection.
We do this in our settings up top.
I'm going to go to my little profile picture.
We're going to go down to settings and then the left hand side bar.
You should see an option, S.H. and GPG Keys.
In our case, we're trying to set up a new HQ and we can go ahead and do just that by clicking new S.H.
key here.
It's asking for two things.
First, it's asking us for a name to identify this key.
I typically use something like work laptop.
I have other keys like home desktop or home laptop.
It just makes it easy to identify the given key.
And the next thing we need is the contents of that public key file.
That is, I'd underscore RSA Dot pub to get the contents of that file.
We can use the following command from the terminal that's going to be CAT, which simply concatenate
the contents of a file out to the terminal.
So it's going to print the contents of our key file, followed by the file to actually print.
That is Tilde Forward sGot S.H. Forward Slash IDE Underscore RSA Dot pub.
Now when we do that, we're going to get the following.
It's a really long string which starts with S.H. Hyphen RSA and it ends with that value you put for
the comment.
And in our case we put our email.
We have to grab all of that, including the S.H. RSA all the way to the end of the email.
We're going to copy that to the clipboard and we're going to bring that over to this big textfield.
We paste it in, click, add SS, HP, and now that's been added to our account.
Now, right here you can notice it saying it's never been used.
And that's true.
We have this key set up, but we've never used it to communicate with GitHub.
We can test our connection by running the following command from the terminal.
If you were on windows, make sure to use get Basche for this one.
That is S.H. hyphen capital T, then space get at GitHub dot com.
This is going to test our S.H. connection to the GitHub servers.
If it works, then we know our key has been set up successfully and we can push our comments up.
If it doesn't work, then we know we have a problem right here.
I'm going to run it and we're going to get the following message.
This is not an error.
It's simply saying that it can't confirm the identity of the server.
But we can indeed accept that by typing.
Yes, since we can see that things look good.
And once we do that, we can see the final line.
Hi.
Followed by your GitHub username.
You've successfully authenticated, but GitHub doesn't provide shell access.
If you're seeing this, that is a good thing.
This means you are able to correctly authenticate with GitHub and now we're ready to push our code up.
Now, actually creating the SS keys and configuring them with GitHub is something you only have to do
once it's set up and we can use it for all of our future projects.
I'm going to head back over to the dashboard, the homepage, then I'm going to grab that repository
I just created.
I can search for it over here.
Node three weather website, I click it, it brings me back to those instructions and we can run that
second command, this command is actually going to take our commits and it's going to push them up to
whatever's at the following you R-AL from the previous step.
I'll bring that over to the terminal.
I'm going to paste that command in.
This is Andrew from the Future with one last interruption.
As I mentioned previously in the lesson, the default branch name for new GitHub repositories has changed.
Previously it was Master, which is what I'm seeing here, but now it is called main.
Now, if you copied the command directly from GitHub, you should already have exactly what I have right
here.
So this is the new command and almost everything is the same except for the branch name.
So we're still using git push with the EU flag.
We're still pushing to the origin remote.
The only thing that's different is instead of pushing to master, we are now pushing to Maine.
So this is the command you should already have copied.
If you're manually typing it out, make sure to use the main branch instead of the master branch.
All right.
We're going to jump back into the video and actually push our commits up to GitHub.
I'm going to run it, and now our code, it's getting sent off to the servers, we can see various pieces
of output about that and we can see exactly at the end what happened.
It set up a new master branch to coordinate with our local master branch.
This is a good thing.
If we refresh GitHub, dotcom, we're actually going to be able to see our project.
No longer will we see these set up instructions.
I'm going to refresh the page now that there are comets to show.
That is exactly what we see right here.
I have a lot of great stuff.
Obviously, I have the files and folders that make up my project.
If I dive into those, I can see exactly how they've changed.
I can see who's contributed to them.
I can view the history of their changes.
I can also use this service to track issues.
So right here I could set up issues.
I could set up various projects outlining what I'd like to complete.
I could set up a wiki for documentation.
There are all sorts of great features that GitHub provides when you're using their service.
Now, in our case, we're just using them for a basic setup.
We're going to keep our code backed up to GitHub.
So if things do go wrong locally, we always have a backup of our copy.
All right.
That is where we're going to start for this one.
We now have our code up on the GitHub servers.
Don't worry, a little bit later in the section, we'll talk about how we can push our other changes
up to the service.
And there'll also be a challenge.
Will, you'll have to do the same.
For now, though, the goal was just to get that basic configuration set up with the keys in place.
We can now use the same setup with any other projects we end up creating.
The next video is all about pushing up to Heroku and getting our application deployed live to production.
It's the grand finale of sorts.
So let's go ahead and jump right in.