Git Tutorial #6

I've been looking forward to this tutorial since writing the intro Git Tutorials page. Here is where it all comes together, where we learn to backup and share our repositories with a single click. 

It feels a little too good to be true, but it's not. And because of Part #5, we're past all the preparations: not only do we have an ssh-key that will let us interact with GitHub, we also have the account linked to our GHD, so we don't have to mess around with commands inside Bash again.

If we were to describe the process of publishing a repository, it could be broken down to three steps.

1. New empty repository is created on our GitHub account
2. This new repository is set as a remote of our repository
3. Our repository is uploaded (pushed) onto the remote

Remote, or a remote repository, is an address of where our repository is located. Once it is set, we're able to quickly upload or download changes between the remote and our local version.

GHD creates a shortcut for all of these steps, and you can find the option to Publish repository as one of the three main tabs, alongside Current repository and Current branch.

You will be asked for a repository name, for a short description, and whether this repository should be marked as private. GitHub will use the provided information to initialize the empty repository, at an address of the following format:
git@github.com:user_name/repo_name

This address is then automatically set as a remote called origin. origin is the default remote name, the same way that main is the default branch name.
Finally, first upload is executed, and provided no errors were encountered, that's the process finished.

Your repository is now on GitHub! Hooray!

Where the Publish tab was found is now the Fetch option. Fetch is a simple command which checks the given remote to see whether there are changes that are not registered locally.

We can open up our browser and go onto GitHub to check the repository page. Chances are you've already seen a dozen of these, but they can appear very confusing. How exciting is it that you now have one of these of your own?

The main portion of the screen gets taken up by files found in the selected branch. The latest commit is mentioned at the top, and clicking the total number of commits (6 commits here) leads to the history overview. You can also add new files, or view and edit present files.

Many of the tabs both on top and the right side are for huge projects, so don't worry if you don't know what they are - frankly, for some of them, I don't know either. What matters to us the most right now is the green <> Code dropdown button.

Here you can find the repository's address - that's the one we have set as the origin remote. And while there is the option for GHD users to quickly open the repository, it is an another GHD shortcut - let me show you how to properly clone a repository with the address. 

Cloning is the process of copying a remote repository onto your system. To demonstrate, I will now clone our repository into a different folder, so that we effectively have two separate versions of them - it will also be useful later this tutorial.

To clone a repository in GHD, first click Clone repository under the File tab.

In the window that opens, you can select a repository either found on your GitHub account, your GitHub Enterprise account (if you have one), or you can insert an address (URL) directly. 

Insert the copied address of the repository, and choose where to create the files on your computer.

We will be presented with a security warning, which we can ignore for the most part. It tells us that it couldn't verify the repository address being on the official GitHub website, and provides GitHub's key fingerprint which we can look up to confirm this ourselves.

Note: This can be fixed by running the following command from a terminal:
ssh-keygen -R github.com

And that's the cloning done. The cloned repository is automatically opened in GHD, which we can't actually tell, as they are both named example_repository. While the original is inside the example_repository folder however, this one is inside a newly created cloned_example_repo folder.

Now that we're inside the cloned repository, let's create a commit - something that we can upload onto the remote. I've decided to edit original_file.txt once again, this time a bit more than just one line of text.

Once I commit the fittingly named "First GitHub commit.", the Fetch tab will change, and will instead offer us the option to Push into the origin remote.

Number 1 next to the arrow pointing up means that locally, we are currently 1 commit ahead of the origin remote. To upload commits onto a remote, we use the Push action - if possible, this will move all local changes onto GitHub, and sets the repository to track the newest commit once again.

After the push, both local and remote versions are up-to-date, and the tab changes to the Fetch origin option again.

Of course, there's also the opposite of a push: pull. Using it is similarly straightforward, and I can actually show you if I switch to the original version of our repository - the one still found in the example_repository folder.

Switching repositories automatically runs fetch, so GHD already knows that we're 1 commit behind, as symbolized by the number 1 next to the arrow pointing down.
As such, the option to Pull from the origin remote is offered on the tab.

How long pushes and pulls take depends on how different the local version is from the remote one. With something like a single .txt file changed, it is almost instantaneous, and if we now open up the original_file.txt inside the original example_repository folder, we will see that it's updated to the version we last pushed.

You can also see in the background that the pulled commit has naturally joined our History.

And with that, we've reached the end of this tutorial, which might've just been the most useful one so far. Remember, you can never have too many backups of your projects - and having the ability to upload your changes to a safe place with literally zero effort is priceless.

As such, a summary is deserved! Today, we have learned:

• What remotes are, the default being named origin
• How to publish a repository onto GitHub, and what fetch means
• What your repository looks like on GitHub's browser page
• How to clone a repository with its ssh address
• How to push changes when you're ahead of a remote
• How to pull changes when you're behind a remote

We are nearing the end of the Git Tutorials series. The final Part follows, where I show you methods for collaborating with other users - something that GitHub has become known for, and that you can use (not only) with your team to your advantage.