Git Tutorial

We show you the most useful commands you will use daily in software development projects under the open-source distributed version control Git. Sync, compare, merge, and share the source code of your projects.

What is Git

Git is a version control system for file-based projects. It is a distributed system, so each copy of the project contains the entire history of changes. With it, you can add, delete, or modify files in a software project and compare or recover the state of files at any given time. Each set of changes is committed to the git repository, leaving them recorded as an annotation or commit.

Optionally, a remote copy of the project under git control is used at an Internet location, so that one or more programmers can exchange updates to the source files without losing control of the edits that have been made separately. There are many platforms, but one very famous one is Github.

How to install Git

Git is a command-line tool that integrates quite well with major existing code editors. Below, we'll show you how to install it for different operating systems.

Installing Git on Ubuntu

Installing Git on Ubuntu couldn't be easier. Just open a command terminal and run apt to download the package from the official repositories and configure the system to make it available.

To do this, we'll install git and verify that it can run without any issues:

sudo apt install git

# confirmación del comando
git --version

Installing Git for Windows

Git, created by Linus Torvalds, the father of Linux, is an application with distributions prepared for major platforms. You just need to download the corresponding installer from the official Git project page and choose the installer that matches your operating system, taking into account your system's architecture: 32-bit or 64-bit.

The installer for Windows will open a wizard that displays a series of options during the process. You don't need to worry; leaving the default options selected will be sufficient in most situations.

Once the process has completed successfully, verify the installation by running a test git command:

git --version

Installing Git for macOS

Installing Git on macOS has two alternatives. The first one is to use the installer (.dmg file) published on the official Git page for macOS. However, this is not the recommended way because with tool updates, manual installation will be required again, involving redownloading and running the published installer.

In macOS environments, it's recommended to use the Homebrew package manager, which simplifies the installation process and keeps all registered applications up to date. Additionally, most installations using brew are done in the user space without requiring superuser access on the computer.

To install Homebrew on macOS, execute the following command from the command line, taken from the official project page:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Once installed, simply use brew similarly to the Ubuntu package manager apt:

brew install git

After a few seconds, the version control and management application will be available globally in our terminal sessions. You can test it with:

git --version

Git Terminology

Git uses specific terms commonly to refer to all aspects concerning it, so if you are going to work with git, it is convenient to learn all of them:

Obviously, there are many more technical concepts that could be listed, but these here are the basic ones to be able to perform basic operations with git. Let's see how they are applied.

Create an empty repository

To create a git repository, located in the root directory of our project, we will write:

git init

This command initializes the git repository's internal indices and references within the .git directory. From that moment on, we can perform operations such as adding files, synchronizing with other repositories, and more.

Create a copy of an existing repository

Creating an empty repository can be useful at times, but usually, we'll continue the work from an existing one. For this, we need a remote repository that is accessible and from which we can download a complete copy. For example, if we're offered a remote at the location https://host/path/project.git, we should use this URL to make a copy:

git clone https://host/path/project.git

Git will maintain a reference to the remote from which the copy was made to be able to "push" the changes made locally or to download the changes made by other developers on the team. The remote repository will be given the name origin. You can add as many remotes as you want and push or pull changes from the remote specified by its name. If no name is specified, the default origin repository is used.

Synchronize with a remote repository

In the next step, we'll see how to make some annotations. For a moment, imagine that we've already made some annotations locally and that on the other side, a colleague has made other changes and uploaded them to the remote. In this scenario, if we wanted to upload our changes, git requires us to first download the changes from the remote before uploading ours. So, when we try to synchronize with a remote, we should first execute:

git fetch

A snapshot of the server's state is downloaded. At this point, our local repository realizes that it is one change behind the remote. The next step is to transfer the changes to the working directory where our local project is located:

git pull

This last command retrieves the changes from the remote that we don't have locally and applies them to our files. If there are no conflicts, the transfer of changes will be seamless, and we will simply notice that the files have been modified. But if a conflict occurs, the file will be locally modified, waiting for us to perform a manual review and eventually make a commit to resolve the merge.

Following the assumption that we had already made a commit to the repository, if there has been a conflict, we should push two commits to the remote: one for the modification we had made and another to resolve the conflict. If there are no conflicts, we would only push the locally made commit.

Assuming that we have already resolved any conflicts, to push all pending commits to the remote, we should perform the push operation:

git push

This last operation will push all the commits to the server, making them available to the rest of the team.

How to Add Remotes to Git

If we started with an empty repository created with git init, there will be no configured remote repository to push changes to. One can be added easily by executing the following command:

git remote add origin https://host/path/project.git

Note that the remote has been named "origin" because it is the first and only remote assigned to the repository. The fetch and push commands allow specifying the remote to work with.

How to Add Files to Git

Alright, we have a local repository now, and we know how to synchronize it, but how do we record changes in Git? To do this, we simply need to ensure whether the modification we have made is to a file that is under the control of Git, or if it is a new file that Git does not yet know about. If we start with an empty repository, there will be no files under Git's control, so the first step is to add the file(s) to Git.

Let's imagine that we create a file named index.js in the empty repository. To add it to Git, we should invoke the following command:

git add index.js

[git add] accepts wildcards so you don't have to add files one by one. Even advanced programming editors perform this step automatically for us.

At the moment of doing add, the index.js file becomes staged and ready to travel in a commit to the history of changes. If the file is already under the control of Git, adding it is not necessary.

How to Make a Commit

Once you have one or more files staged, it's possible to confirm the changes in the local repository through a commit or annotation. All annotations in Git should be accompanied by a comment:

git commit -m "inclusion of the file index.js"

This command records the project's evolution, and if working with a remote, a push could be performed. The push operation might fail if someone had uploaded changes in the meantime, so we would be forced to first perform a fetch and pull.

How to discard git changes

If we have made local changes that have not yet been committed, we can discard them, leaving the project in the state of the last commit. To do this, simply execute:

git stash

This operation discards all local changes permanently.

How to view the repository's status

When several modifications have been made throughout the source files of the project, it's easy to lose track of which lines have been edited. To view all modified files in the project, we will write:

git status

This operation gives us a general overview of the changed resources, but if we want to see the detail of a specific one, we will ask git to show us the differences:

git diff index.js

Git will display a rather ugly text-based comparison editor. Again and fortunately, integrated programming environments provide a much more attractive visual interface.

How to view the change history with git

To display the change history for the entire project, we will use the log option:

git log

Each commit is identified by a hash [c561ae54d2ccb9de92d1512a74ce2ea5b91acf88], through this identifier we can see what changes were applied in that annotation:

git show c561ae54d2ccb9de92d1512a74ce2ea5b91acf88

This way, we won't miss a single comma that could cause our project not to run correctly.

How to retrieve the project to a git annotation

If we want to retrieve the project as it was after a specific annotation, we can execute the checkout operation:

git checkout c561ae54d2ccb9de92d1512a74ce2ea5b91acf88

To return to the present, we can perform the following operation that jumps in time to the last available annotation:

git switch -

How to ignore files with git

There are files that should not be in the code control repository, for example, those corresponding to build or auto-generated files in the compilation process, such as .class, .exe, .dll, etc. These can be built as needed so there is no point in saving them in the repository, unless there is a compelling reason.

To indicate to git that certain files should be ignored, you must add one (which is under git control) called .gitignore. This is a plain text file located at the root of the project, where specific files, patterns, or directories can be indicated to be ignored by git. For example:

\*.log
target/
hs_error.log

As mentioned, this file should be under git control so that all members of the development team ignore the same files, so we should not forget to add it to the next commit with:

git add .gitignore

How to create a branch with git

As mentioned, branches represent different snapshots of the project that can evolve independently. Although in most cases there is a transfer of commits from one branch to another. The most common use cases for branches include the application of gitflow.

Gitflow is a way to organize branches to have control over the project in all its phases. In a very summarized way, we will say that gitflow states that there should be a branch named master that represents the version of the application in production. And on the other hand, the develop branch includes additional commits compared to master and corresponds to the developments of the new version to be released for the application. Once develop is considered stable, the commits from develop are transferred to master just at the moment of publishing and distributing the new version of the application. Gitflow recommends the use of more branches, but these are sufficient to illustrate the use of git.

By default, the master branch is the initial branch, and it is where commits are made if no other branch is specified. But we can create a new branch from a commit to evolve the project with changes that are experimental and may be discarded or eventually applied to the final version of the software. Whatever the case may be, we can create a branch with:

git switch -c develop

The -c argument indicates that if the branch does not exist, create it. Now, annotations can be made as considered appropriate. If working with a remote, when pushing this branch, an identical one with the same name will automatically be created at the remote location. If we want to return to the original branch, we will press:

git switch master

This new branch maintains the same history as the branch it originates from, but the changes made on this branch will not be in its predecessor, at least not until we merge branches.

How to merge branches with git

To merge two branches, we must be positioned on the target branch, with switch. The operation performs the retrieval of annotations from the specified branch onto the current one. So, if we want to bring the changes from develop to master, we first switch to master and then perform the merge with merge.

git swith master
git merge develop

This operation may result in conflicts if there are modifications on master that have not been made on develop. If this is the case, we will need to manually commit the resolution of the conflict(s). Remember that if working in a team with a remote, the push must be done to provide the changes to the rest.

How to delete branches with git

If a local branch is no longer needed and you want to delete it, you can tell git your intention as follows:

git branch -d develop

However, you may want to delete the branch in the remote repository instead of locally. If so, the command changes slightly.

git push origin --delete develop

Keep in mind that if the rest of the team has pulled the changes from the deleted branch, even if you delete the branch in the reference remote, it will still exist in the other copies distributed among the team.

Conclusion

Git is a powerful tool for managing all changes in the files that make up a project, and it also serves as a good mechanism for backups and synchronization between computers.

In the preceding lines, we have seen the basic fundamentals of git and how to use it from the command line or terminal. Fortunately, integrated development environments (IDEs) typically incorporate the operations we have seen natively through contextual actions or toolbar accesses that simplify and streamline the use of git.

We recommend that you take a look at some of the IDEs you can use for free as they are Open Source and multi-platform.

Feel free to leave your comments below or contact us to share your experience or to improve this content. Regards!