Github Intro

Now we have already taken our first steps in using Git, but for the moment, we have only cloned from a cloud based public repository. On the next steps, we will learn how to connect different local and remote repositories and how to authenticate those connections. For that we will use the most popular code hosting service, Github.

Configure Connection

In order to send information to a repo in Github or being able to access private repositories, we must authenticate our connection. That means we must have the proper credentials so that Github knows the permissions we have. There are two major ways of doing this.

Username and Token

The first way is using your username and token, a speciallized password. The first step in doing this is creating a token on your Github account. You must navigate the menus through Settings -> Developer Settings -> Personal access tokens. You'll then have the oportunity to create a new token.

Follow the instructions on screen to create your token. Make sure to choose the areas you wish the grant the token privileges. Tokens are better than passwords because you can not only give different permissions, but also we can give them different expiration dates and cancel them anytime.

Once you create the token, remember to copy it! There will be no other oportunity to do so.

But don't worry, you will neither need to memorize it or have it written anywhere else. You can set Git on your terminal to store the token for you, so that you don't need to type it everytime. To do so, use the following command before any action that requires verification:

Terminal
git config --global credential.helper store
Copiar

Clone using SSH

The second way of connecting to Github securely is using SSH (Secure Shell), through SSH keys.

• Key Gen

First of all, we must creater a public/private SSH key pair. In order to do that, we will use our terminal to do the following:

Terminal
ssh-keygen -t ed25519 -C "<your_email@example.com>"
Copiar

If you wish to use an existing SSH key, check the documentation link at the end of the section. You can find more information and options on the use of SSH keys on the official Github Documentation

• SSH Add

Then, we will need to add our ssh agent and GitHub. To add it to our SSH agent, use the command:

Terminal
ssh-add ~/.ssh/id_ed25519
Copiar

This will make it so our ssh agent has the key prepared to us. That is the pr¡vate part of the key. The public part must be sent to Github through their webpage. Together, the public-private parir is what will validate our connection.

• Adding Public Key to GitHub

Click on your profile picture, then navigate through:

Setting -> SSH and GPG keys -> New SSH key

As seen on the images bellow, you should be able to navigate easily to the SSH input dialog.

Give it a title and paste the content of the SSH public key. To get the key itself for that, you can use the following command:

Terminal
cat ~/.ssh/id_ed25519.pub
Copiar

Your key should look like this:

Terminal
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXX <your@email.com>
Copiar

Remote repository

As you have probably found out by now, Githubb is a pretty great cloud hosting service, specialized in hosting repositories. You may keep copies of your repo, share it with friends, coworkers or the community in generael, but also find some awesome repos from folks all around the globe which you can then procede to clone (or download) into your computer as seen on the previous session.

If you wish, however, to upload data to Github, you must somehow connect a local repository you have with a Github counterpart, that is, a remote repository.

As with most things, there are several ways in which we can acomplish that:

• Clone an empty repo

One way to go about it is to create a new repo in Github and clone it while it is still empty.

After creating it, you'll simply need to clone it with either the https url, if using username and authentication token or with the SSH url if using public-private key as authentication method.

Doing it this way, your local repo (the one on your computer) will be born empty and connected to its remote from the get go.

• Connect a new remote to an existing repo

If you, however, already have a repository on you local machine, one you initiallized with git init or any other way, you can connect any remote to it. In other to do this, you'll also need to have a repository created in Github, so go ahead and create a new on and copy the URL(HTYTPS os SSH).

In our terminal, we will use a command to link the two repos (local and remote) together:

Terminal
git remote add <name> <url>
Copiar

El principal remoto de un repositorio, por convención suele tener el nombre origin. Haciendo con que el comando anterior sea:

Terminal
git remote add origin <repositorio>
Copiar

• Multiple remotes

There can be multiple remotes connected to a single repository, to check them all out, use:

Terminal
git remote -v
Copiar

Common use scenarios for this is keeping up with someone elses repository while still having your own changes and uploading them as well.

NOTE: All relations between a local repo have two directions:

• Fetch/Pull (Bringing data to Local)
• Push (Sending data from Local to Remote) Depending on how relationships and permisions are setup, both or only one of those may be active. You may think of it as a read-only or read-write relationship.

Pull and Push

As stated previously, there are 2 main operations we may execute between our local and remote repositories.

• Bringing new data to our computer

If someone else changed something on a remote repo, the logic thing to do is that we also incorporate these changes in our local work. In order to do that, we must realize a pull operation, that is:

Terminal
git pull <remote_name> <branch_name>
git pull origin master
Copiar

This command will bring the changes in the specified remote and branch and incorporate them in our local repository.

NOTE: By default, the main branch will be called 'master' our 'main'. More on branches on the next session.

• Sending new data to Github

The opposite would be for us to incorporate new code into our remote repository. To do that, we will need permisions, either it is our own remote repo, or someone allowed us. That is, you can't change any repo whatsoever.

But assuming everything is clear permission-wise, you can use the command:

Terminal
git push <remote> <branch>
git push origin master
Copiar

This will send all the local changes to the specified remote and branch.

IMPORTANT: All changes you wish to send between repos should be added and commited. It is acctually the commits that are sent between machines.

Fork a repository

Here's the deal then. If we cannot push into a repository which is not our own, how is the developer community so supportive and colaborative?

That's where forking and pull requests come handy. You see, you can't push into a strangers public repository, but you can clone it and pull from it. Furthermore, you can also fork it.

On the page for such a repo, you will find the fork button. Upon clicking on it, Github will create a new exact copy of this repository, with the slight difference that it will not belong to the original owner, but to you. And since it is yours, you can do with it as you wish.

NOTE: Changes and commits to the original repo will NOT automatically update your fork, you must do it yourself.

First of all, you should clone it. But make sure to clone your fork and not the original again. Once you have it, add all the improvements you see fit, commit and push them to your fork (your github copy) of the repo. Now it is just a matter of getting the original owners attention.

Pull Request

Find the pull request button on the Github page for the repo and create a new one. This way you can create a comparison between your fork and the original, so that the owner (and reviewers) of the original code can easily see and compare them. You should also leave a descriptive title and informative message. Your pull request means you are asking the original owner to incorporate your fork's changes into the official repo.

They or their team will then analyze and decide whether to accept (merge) or reject (close) those commits. Collaboration is such an inherent part of the developer community that many projects will have documentation specifically on how to contribute. Check it out and you can also learn some great programming pratics from those.