A tutorial for beginners

Sam Barros

Follow

Jun 9, 2019 · 10 min read

Hi guys,

In this article, I'll teach you how to use Git in your projects and how you can get improvement work with this amazing tool.

Hey Sam, first of all, what is this Git guy?

OK, from the beginning.

"Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows."

Ahhh… Now I underst… No, I don't. Could you be more clear?

Sure.

Let's imagine that you and your friend have decided to do a revolutionary project. In this project, you'll work together and you will develop the most disruptive game, with the most innovative features doing the most effective way to solve problems. You've decided to do a chess game, not only a calculator but The Chess Game.

You know that a chess game is composed by a board and the pieces, where the pieces are: Pawns, Rooks, Knights, Bishops, Queen, and King.

You and your friend have decided that you will be responsible to develop the Pawns, the Rooks, and the Knights classes (or functions) and your friend will be responsible to do the Bishops, the Queen, and the King classes. And both of you will work together on the board doing pair programming.

You started doing the pawns and your friend doing the Bishops. OK, you have sent your part by email and your friend has done the same. Cool, the things are working. So, you decide to continue the project and start to develop the Rooks and your friend the Queen. You sent by email and your friend do the same, but when you put the code together…

For any reason, the code is not working. You have searched all the code and hasn't found the problem. You have asked your friend what's happening and he says: "Well… everything was running 🤷‍♂️".

So, both of you has decided to rollback to the last version, but unfortunately, you haven't controlled the version of the project. So, you don't have conditions to do a rollback.

It's a sad story that happens every day, everywhere.

But don't worry. What do you think is the solution to this?

With git, you can control the version of your system. Git basically tracks the changes in the project files, because of this you can work on those files among multiple people since all changes are controlled. Git tracks every kind of file. And, since you keep all the history of your files, you can roll back for a specific part of your project (Normally, to the latest part that was working 🙂)

Ah, now, I got it. So, I've heard about GitHub, GitLab and such a BitBucket. Are they the same? If no, what's the difference among them?

Git is a distributed version control, created and developed by Linus Torvalds, that can help you to manage your project providing a source code history, while GitHub, GitLab, and BitBucket are the hosting service for Git repositories.

Since we know this, let's choose one of these tools to help us how to understand this better. If you read my last article I told you that I prefer learning giving examples.

In this case, I will choose GitHub. There are some reasons to choose GitHub, it's the most git hosting service known, it had 28 million users in 2018, it's free for an unlimited number of public repositories and you just need to pay a little cost to have private repositories, etc. I like the other too, for example, GitLab accepts mermaid and BitBucket provides free private repositories for small teams.

But for now, let's use GitHub together.

Commands

You'll see in this article the most important commands you need for now.

$ git config
$ git clone
$ git status
$ git add 
$ git commit
$ git checkout
$ git status
$ git log
$ git push
$ git pull

Installation

First of all, you should download and install the git on your machine. You can find the file to download on git website. And you need to sing up on GitHub.

Working with Git and GitHub

Let's create our first repository on GitHub. We'll call it the-chess-game.

Then, we need to set up git in our local machine.

$ git config --global user.name "<Your name>"
$ git config --global user.email "<Your email>"

And let's clone the repository that we've created on GitHub. When you've created the repository it provides you a URL containing the link that you need to clone the repository.

$ git clone https://github.com/<your username>/the-chess-game.git

Great! Now, let's start our project. As we know, we need to create files that will compose our project. GitHub has 3 interesting files by default:

• README.md: It's the file where you can write the information about the project. You can use Markdown to write it.
• .gitignore: It's the file where you can put all the other files that you don't want to put in the project. (Yes, there is a dot in the beginning)
• LICENSE: The license of your code/files inside the repository.

So, we can give some information about our project, can we? Let's create and add some text in the README.md file. If you are a windows user, just create a new file instead of *touch*.

$ cd the-chess-game
$ touch README.md

Add the text:

# The Chess GameThe most disruptive game, with the most innovative features doing the most effective way to solve problems.

Save the file and voilà, Git is aware that something is quite different.

Hey Sam, OK, I've done all the stuff that you've told me. But, How Can I know that git is working well?

Elementary, my dear reader. We need to see the status of the directory, just type this.

$ git status

You'll see the results of the project.

To control the version you need to add this to a commit. We can add just a file or all the new or updated files, like this:

$ git add README.md

If we type git status again, look at what happens.

Git recognizes the new file. So, let's commit it:

$ git commit -m "<message>"

OK, now, it's the way that I use to make my commits, it could be not the right way, it's my way. I like to message "This commit does something". We're adding a new read me file, then "This commits adds read me file", so I can summarize: "adds README". Let's do it:

$ git commit -m "adds README.md"

$ git status

Great! Now we should push this information to GitHub.

$ git push

If we go to GitHub, we can see this.

Awesome. It's working very well.

To see the history of the commits.

$ git log

Sam, I understood, but what this name master means?

Master is a branch, the default branch provided by GitHub. Making an analogy, a branch is a parallel world, but it's still in the same world. When you finish the job you can merge both worlds.

A branch allows you to work in a place without making changes in another place.

Branches

Work with branches is a good practice because the Branch operation allows creating another line of development. We can fork off the development process into two or more different ways. For instance, we create a branch to work with the pieces and another branch to work with the board of our chess game.

There are two ways to do this.

$ git branch <branch-name>
$ git checkout <branch-name>or$ git checkout -b <branch-name>

Let’s create the pieces branch.

$ git checkout -b pieces

In this branch, you will develop the pieces if the chess, you're responsible to develop three of them, so let's start developing the Pawns.

I don't know which language you choose to develop, so we won't put the extensions of the file and we won't develop the game because of it is not the goal of this article, we will just simulate it.

So, let's create our file pawns, with the content.

Function that makes the pawns pieces work.

And, let's put in the README.md the developers that will do the job and change game to the tool, so update it to:

# The Chess GameThe most disruptive tool, with the most innovative features doing the most effective way to solve problems.### Developers@me and @my_friend.

And let's see what happens if we type git status.

Git informs us that we have new files, and files updated. But, what's the difference between the old file and the new file.

$ git diff README.md

It shows us what we add and what we change.

Cool! Let's commits change by change, that means, let's inform the changes that we did in each file.

$ git add README.md
$ git commit -m "Adds developers and changes games to tools"
$ git add pawns
$ git commit -m "Includes pawns file"

Now we should push the new information. But…

$ git push

In this case, you need sets up the association between your branch and the one at origin in the same way. So, we need, as it informs:

$ git push --set-upstream origin pieces

$ git log

Now, you are able to merge the current branch (pieces) with the master. But, as a good practice, to request to merge. We do this in GitHub as a Pull Request (PR). To make a pull request you should go in the GitHub and create a new PR.

Sam, why is this a good practice?

Because you can make someone review your code, your team is able to make comments about your code before to merge it on the master.

In our case, we haven't set up to validate if the reviewer is a superuser. But, it's a good practice to do this.

But now, we're able to do this. And, if you prefer you can delete the branch.

So, finally, to get the information from GitHub, we need to pull from it.

$ git checkout master
$ git pull

Conclusion

If you need more information about Git, you can go to the Git documentation and get all the information that you need.

There is something that I'd like to tell you.

Thank you for reading this article.

I hope that I have contributed to your knowledge. Feel free to tell me what I should improve to write better articles.

The complete project you can find in my GitHub and search for the the-chess-game.

About me

Sam Barros is a Brazilian that works in Berlin as a software engineer. He's an enthusiast about technology and he's always helping people with examples with his life.

Connect on:

• LinkedIn
• GitHub
• Medium