© Mariot Tsitoara  2020
M. TsitoaraBeginning Git and GitHubhttps://doi.org/10.1007/978-1-4842-5313-7_9

9. Quick Start with GitHub

Mariot Tsitoara1 
(1)
Antananarivo, Madagascar
 

So far, we only talked about what is GitHub and who needs it. Now, we are going to see what it can do exactly and what its main features are. The most important features of GitHub are its Project Management tools; combined with the right development workflow, it is a sure way to get a project moving.

For this section of the book, nothing better than good old-fashioned exercises! I could tell you all the advantages of GitHub, but you’ll understand better if you are doing the exploration yourself. Let’s begin by creating a GitHub account and starting a project.

Project management

The ability to manage a project while following a well-established path is one of the most admired features of GitHub. You are going to follow along with me in this section. It’s very important that you do so because you’ll have a better understanding of the features.

Since we are going to manage our project with Git and GitHub, our very first step is to create an account. It’s very straightforward, and you don’t need any more information more than your name and email just like in Figure 9-1.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig1_HTML.jpg
Figure 9-1

GitHub signup page

After signing up, you’ll receive a confirmation link in your email client and following the provided link will conclude the inscription. You will then arrive at the main GitHub page which should look like in Figure 9-2.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig2_HTML.jpg
Figure 9-2

GitHub homepage

You GitHub homepage is pretty empty but we’re working on filling it with cool projects. At the right side of the page, you’ll see some trending repositories or news story; but we won’t go there yet.

As you can see in Figure 9-2, there are three links that you can follow to create a new repository: one on the left side, one in the middle, and the last one in the navigation bar. Click one of them so we can create our repository.

The repository creation form is also very simple, as you can see in Figure 9-3. You only need to fill out the form with a name and a short description of the project. That description is optional, but you should try to make it as simple as possible so that users who visit your repository know what’s up.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig3_HTML.jpg
Figure 9-3

Creation of a new repository

You can choose to make the repository private, if you like; nobody but you will have access to it. A public repository doesn’t mean that anyone can edit it; it just means that anyone can read it and logged in users can propose changes to it. You will still be the maintainer of the project and the owner of the repository.

Then, you have the choice to initialize the repository with a README file. Ignore this for now because we are aiming to create a repository from scratch; and we will add README, .gitignore, and license files later.

After all is done, click the Submit button to create your first GitHub repository! It’s that simple! You will then be redirected to your project page, which is a unique link to your repository. The link looks like this: https://github.com/your_username/your_repository; for example, the new repository I created is accessible through the following link: https://github.com/mtsitoara/todo-list. Thus, you can’t create two repositories with the same name. Your project page should be similar to the one shown in Figure 9-4.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig4_HTML.jpg
Figure 9-4

Your brand-new repository

As you can see in Figure 9-4, there are some instructions on how to get started whether you want to create a new repository or push an existing one. Since we are building our repository from scratch, we will go with the first option. The second option would have worked for us too because we already have a local repository, but we are going to ignore that from now.

So, we created our first repository and are ready to push our project on it. But let’s look into the magic box and see what exactly has just happened.

How remote repositories work

Remember Chapter 7 about remote Git and how we decided to use GitHub as a remote repository store? This section is a logical extension of that chapter because we are going to learn how remote repositories managed with GitHub works.

When we created our repository using the GitHub web site, we were giving instructions to GitHub servers and asked them to initialize an empty repository. And if you remember Chapter 2, initializing a repository is very simple: go to any directory and execute git init. That’s exactly what happened here, except not on your computer but to a server hosted by GitHub.

So, it’s as if we executed the following commands on a faraway server which has git installed
$ mkdir todo-list
$ cd todo-list
$ git init

It’s the same commands that we will use to create our local repository. So now, there is a remote repository in GitHub’s servers that we will use to share our project.

Remote repositories are used so you don’t have to use your own computer to share your project. In the case of GitHub, the remote repositories are accessible by anyone but only the owner can edit them. We will discuss teamwork in a later section.

The main takeaway is that a remote repository is where you can publish your project to make it available to everyone. And anyone can clone your repository, so they can follow your advancements to get the latest changes.

Publishing your local repository to a remote one is called “pushing,” and getting the latest commits from a remote repository to a local one is called “pulling.” Push and pull are maybe the most used commands you’ll use in Git.

But how can I tell GitHub which remote repository I want to be linked with my local one? That’s where the unique link to your repository is needed. You’ll use the link to push your local changes or pull the commits you don’t already have.

In conclusion, GitHub created an empty remote repository which can only be modified by you but can be seen by everyone. What we need to do now is create a local repository and link it to the remote one.

Linking repositories

Now that GitHub has created the remote repository for us, it’s time to create our own local repository and link it to the remote one.

As we’ve done in the previous chapters, we’re going to create a repository with the git init command. The repository names can differ between local and remote, but it would be a good idea to use a unique name so you don’t get confused. For this particular project, the commands will be
$ mkdir todo-list
$ cd todo-list
$ git init

Note

If you prefer to work with the repository that you created earlier in this chapter instead of a new one, you can just skip the initialization part and go straight to linking.

Nothing new here; and you should get the same result as shown in Figure 9-5.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig5_HTML.jpg
Figure 9-5

Initialization of a Git repository

Now that we have our local repository, it’s time to link it to the remote! To list, add, or remove remotes, we will use the git remote command. For example, let’s link our current remotes using this command:
$ git remote

You shouldn’t get any result because it’s a brand-new repository and we haven’t linked any remote to it. Let’s add one now.

Note

If you see remotes in your results, you can remove them by using git remote rm [remote_name]. Anyway, you shouldn’t see any remote if it’s a new repository.

You will need the unique link to your repository to be able to link a local repository to it; so, grab yours from the previous section. Mine is https://github.com/mtsitoara/todo-list.git. Don’t forget the .git at the end!

You will also need to create a name for your remote repository. That way, you can have multiple remotes within a single project. It may be necessary in the case where the test and production remotes are different for each other. The default name is “origin” per convention. Although you can choose any name, it is recommended to use origin as the name of the remote where teammates share their work.

The command to add a link to a remote is simple. It’s
git remote add [name] [link]
So, to add a link to the newly created repository, you’ll have to execute this command:
$ git remote add origin https://github.com/mtsitoara/todo-list.git
That’s it! You can check if the remote has been added by executing git remote or git remote -v to get more information. You should get a result similar to the screen shown in Figure 9-6.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig6_HTML.jpg
Figure 9-6

Adding a new remote

And that’s it! Adding a new remote is a simple, straightforward task. Now that we got that cleared, let’s push the project to GitHub!

Pushing to remote repositories

We finally got our local and remote repositories linked. It’s time to push our project to GitHub so we can share our work.

Pushing commits to a remote repository is very simple; but first, let’s create some commits to push. In your working directory, create a file called README.md and put in the description of your project in Markdown. For example, here is my README.md file:
# TODO list
A simple app to manage your daily tasks
## Features
* List of daily tasks
Now, let’s add the newly created file to the staging area by using git add.
$ git add README.md
Now is the time to commit our project with git commit. As commit message, many developers choose “Initial commit” when it’s the first. It’s not a rule and you can change it if you want to.
$ git commit
Since we’ve done these many times already, you should be comfortable with staging and committing by now. After the commit, you should have a result similar to Figure 9-7.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig7_HTML.jpg
Figure 9-7

Creating, staging of a new file

So, we have our first commit! Now, we can push those changes to the remote repository. The command to push changes to remote is simple; you just need the name of the remote repository and the branch to be pushed. Since we haven’t created any branch yet (we’ll learn about branches in a later section), our only branch is called “master.” The git push command is
git push <remote_name> <branch_name>
So, in our case, the command will be
$ git push origin master
With a little bit of luck, everything goes well; but it’s not always the case. If you use a password manager or used different configs (name and email) from the ones you provided to GitHub, you’ll get an authentication problem. For example, I am denied access to my repository because I used a password manager and it tried to log me in with my old credentials. You can check an example of authentication error in Figure 9-8.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig8_HTML.jpg
Figure 9-8

Authentication error

To resolve these kinds of problems, we have to configure Git again, with the correct information. You can see in Figure 9-9 that I changed my email in the global configs, that is, on every repository on my computer.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig9_HTML.jpg
Figure 9-9

Reconfiguration of Git

Now, we have to make sure to remove any link to a password manager in this repository. For my case, I use credential helpers (password managers) in other repositories on this computer; so I will not set a global config but a local one.
$ git config --local credential.helper ""
This should resolve our problem and we can resume our push. After you execute the git push command, you will be asked for your username and password. Then, you’ll get a result similar to Figure 9-10.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig10_HTML.jpg
Figure 9-10

Successful git push

Tip

Since we are using HTTPS to push and pull changes, we will need to provide our username and password each time. It gets tiring real fast, so if you want to use a password manager or stop using passwords altogether, check the lessons in the Appendix of this book.

Now, our project is visible on GitHub by everyone! Let’s check it out on its project page. If we refresh the project page, we should get a page like the one shown in Figure 9-11.
../images/484631_1_En_9_Chapter/484631_1_En_9_Fig11_HTML.jpg
Figure 9-11

The updated project page

As you can see in Figure 9-11, the repository page now displays many intel:

  • The number of commits

  • The last commit name and its committer

  • A list of all project files

  • A preview of README.md

What we just did is the basis of code sharing: pushing changes. You will be using this command over and over again when working with remote repositories. It is a very simple feature, but it is imperative that you understand completely what it does. Pushing just means to copy all your current commits (in a specific branch) to a remote branch in a remote repository. All history logs are also copied.

Before you go to the next chapter, ask yourself these questions: where are the remote repositories stored? Who has a read-only access to them? Who can edit them? Also make sure to understand the basis of remote and local repositories linking and why is it necessary.

Summary

In this chapter, we had our very first interaction with remote Git repositories. As we’ve already established, they are just normal repositories that are stored in a remote server instead of your local machine. We saw how to create and link local and remote repositories, a feature that we will use a lot of times. And the main command we learned was git push, which copies the state of your local repository to a distant one.

In the next chapter, we are going to dive deep into Project Management and see what other features GitHub has to offer. We will also learn to pull changes from the remote repository as well as resolve push and pull issues. Let’s go!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.151.141