Understand, install, and configure Git

First steps with Git, for practice. We explain in detail how Git is installed and how to launch the first few commands using the version control system.

In this article we explain the first steps with Git and GitHub, from the transcript of some live classes that were broadcast on .com.

Likewise, you will find the videos of each of the blocks of the class along with a summary of the video as a transcript of what was told in this class. They are ideal for getting started with the Git version control system. In this case to understand some basic concepts and create your environment to work with Git.

Quick facts about Git and GitHub

Before we dive deeper into Git and start practicing, we want to cover some of the typical questions you have when starting out with this version control system. This is to see some quick keys about Git features, workflow and some differences with GitHub.

In Git, each developer has a complete repository installed on their machine; it’s something inherent to distributed version control systems, as we saw in the article about . It is an essential condition. All changes to our files throughout development will be kept locally. Optionally, we will send those changes to remote repositories, such as GitHub or any other.

This means that my machine will have everything I need to work. We will have a copy of the complete repository, each of the files of the entire project. With the Git repository local, I’ll then decide which other servers or machines to push my changes to.

GitHub is a hosting of Git repositories, therefore, the use that we will give it is as a remote repository. But it should be clear that I need to have the changes in the local repository first and then I can “push” those changes to the remote repository.

Note: As a convention, we’ll use the verb “push” to refer to the action done with Git’s “push” command, which we’ll cover in a bit. For now, so that everyone can understand us and get a better idea of ​​how Git works, we can limit ourselves to using plain Spanish terms, there will be time to get technical.

Therefore, the first difference between Git and GitHub can already be seen: Git is the version control technology and GitHub is simply hosting Git repositories, with a web interface that offers us some utilities based on version control itself. git.

On GitHub I can have various repositories and if I want to work with any of them, I must first have it local. Be careful, we do not need to have all the repositories that you have published on GitHub locally, only those with which we are going to work. As soon as we have them local, we can make changes, store them in our local repository and when we deem it appropriate, send it (push, push) to as many servers or remote repositories as we want.

Note: Also note that when we refer to GitHub we mean a remote repository in general. In other words, what we say about GitHub in general terms is really useful to understand other Git repository hosting services such as Bitbucket.

To conclude and have a clearer workflow with a Git version control, imagine a work team with several components. Each and every developer will need to have a complete copy of the entire software repository being developed. The team will then decide which server with a remote repository they want to push the changes to.

Each developer will be able to send the changes that they have locally to the remote repository whenever they want and that remote repository will be used by all the components of the team to synchronize and have the newest version of the code whenever they want.

We can consider this scheme as the basis for working with Git, although later in practice things get complicated because there will be conflicts and you will have to resolve them.

Install Git

Having Git installed locally is an essential condition to work with the version control system. The process to install Git is very simple because it is not different from the installation of any other software that you have done.

You have to download the version of your operating system on the official page (or if you use Linux you will download it from the software repositories that you usually use in your distribution).

You install it like any other software. If you are in Windows you will have an assistant to which you will do “next, next” until the process is finished. You can watch this video that clarifies some points about the installation.

For Windows users, Git Bash?

The only place where you may have doubts is in the step that tells you if you want to install it as a command on your console’s command line or if you just want “git bash”.

If you install it in the Windows console itself, the only advantage is that you will have it available from the Windows command line window and you will be able to do the Git commands from there. If you install it only in Git Bash there will be no more problems, just that when you want to use Git you will have to open the specific Git console that they call “git bash”.

The easiest way to find out if Git is installed on your system is through the command:

git version

This will show you the version number of Git you have installed on the screen. If in Windows you installed Git in console (the command line window), you will notice that in any Windows command console you have Git available. If you installed it only in Git Bash, you won’t have that command and Git is not available from the Windows console.

Git Bash is the command line for Git for Windows, which also allows you to run basic Linux commands, “ls -l” to list files, “mkdir” to create directories, etc. It is the most common option for using Git on Windows.

It doesn’t matter if you install Git on the Windows command line or if you install it only in Git Bash. Just choose the one that is most comfortable for you.

First Git setup, first commands to run

First of all, immediately after installing Git, the first thing you should do is run a couple of configuration commands.

git config –global user.name “Your name here” git config –global user.email “your_email_here@example.com”

With these commands you indicate your username (usually use your first and last name) and email. This configuration is used so that when you make commits in the local repository, they are stored with the reference to yourself, merely informative. Thanks to this, later when you obtain information about the changes made in the local “repo” files, this user and email address that you have indicated will appear as responsible for those changes.