GIT: what is it? why use it? and how to use it?

What is Git?

Git is a distributed version control system, it is free and open source. It is designed to handle small to very large projects with speed and efficiency. Version control is a system that keeps track of changes to a file or group of files over time, allowing you to get specific versions at any time.

When working with Git you need to create a repository, which is the space where the project will reside. Also branches (branches), which are copies of the repository and that each branch are created commits with changes. A commit is like a snapshot of how the file(s) are at a given point in time.

Why use Git?

Compared to other version control systems, Git has the advantage of being easy to learn with little impact on the performance of a system. In addition, its almost unique feature is the ability to create branches, which means that in the same development environment, for example, you can have multiple lines of work totally independent of each other.

This is very useful because it allows making context changes easily, creating roles for each branch to satisfy the different needs of the project. It also allows you to work on the implementation of more than one functionality at the same time and thus include the work of this one progressively until it is ready to be included in the main development branch. It is also possible to work on something for testing purposes that finally will not be included and simply delete it without consequences for the repository.

When distributed, instead of locking elements in the source code, a local copy of the complete repository is generated. Thus, there are many backups of the source code. Thanks to this feature and the ability to create multiple branches, it is possible to work with different frameworks.

On the other hand, Git also offers data security, as its model ensures the cryptographic integrity of the entire project. A checksum is applied to each file and each commit, and when files and commits are checked back into the repository (whether local or remote), a checksum is also applied to them. This makes it impossible to obtain pieces of information outside of what the repository users have submitted. Another advantage offered by this system is the ability to select which of the total changes that have been made are to be included in a commit.

How to use Git?

Originally Git was intended to be used with the command line, however, it is now possible to integrate graphical interfaces into development environments.

Basic commands

Assuming that you are going to work on a previously created repository, the basic commands needed are:

git config -global user.name "{name}" and git config -global user.email {email}, are used to configure the user to which commits will be attributed .
cd root is used to position itself in a directory, necessary to establish in which directory the repository will be cloned.
git clone {url} is used to clone the repository found at the provided URL.
git checkout {branchName} command used to switch branches, if you add -b before the branch name, creates a branch with that name as long as there is no other branch with the same name. To overwrite an existing branch use -B.
git status this command allows to know the status of the branch, it indicates things like if it is up to date with its remote counterpart, if there are changes in the files, if files have been included to be part of a commit, among other things.
git log allows you to see the history, i.e. the commits that have been made in descending order with the parameter -p parameter shows the changes made in each commit and with -{number} indicates the number of records to be returned.
git add/rm {fileName} adds or removes a file to be part of a commit.
git stash instead of adding the files to the commit this command allows to hide the files so that their changes are not detected, to show the changes the command is git stash pop.
git diff shows the changes in the files that have not been included to be part of a commitIf you want to show the changes for those, you include the parameter -staged.
git commit shows an editor to write a message to indicate what the changes are about, if you do not want to open the editor you can add as parameter -m "{text}" to write the text directly.
git commit -amend allows you to edit the message of a commit and also works like git commit by opening the editor or typing the message directly, also if you run the command git add command after
git commit will also include the most recent commit, the files that were just added.
git restore -staged {fileName} (previously reset HEAD {file}) this command does the opposite of git add and allows you to remove a file from the list of files that are going to be part of the next commit. You can replace HEAD for a specific commit, but this changes the story.
git restore {fileName} (previously git checkout - {file}) undoes changes made to the specified file, as long as the file has not been used with git add, if that was done, then it is necessary to run the above command.
git push <remote> <branch> envía los cambios del branch local al branch remoto indicado
git fetch fetches all changes made in the remote repository that are not found in the local repository, but does not apply them.
git merge command to incorporate changes from one branch into another.
git pull downloads the changes and also, if there are no conflicts, applies them to the files in the current branch, i.e. runs a git fetch followed by a git merge.
git rebase {branchName} retains the commits from the current branch and replaces the previous commits with the branch commits.
git branch with the parameter -m {name} you rename a branchwith the parameter -d {name} deletes a branch branch specified branch.

Solutions to some problems

If several people in a team are working on the same repository performing different tasks, which may or may not be related to each other's tasks, there is a risk of making mistakes in handling branches. In addition, if a clear workflow is not established, the risk is higher. For this Git has three commands that allow you to rewrite the history.

The first scenario occurs when you need todeploy to production changes that are in a branch but you cannot publish the branch in its entirety. In this case you need to create a branch using as a base the last branch that was deployed to production and then bring to this branch the necessary commits. For this you use the command git cherry-pick {commitId} and if there is no conflict, then it will apply the change to the branch.

The second scenario is when commits were mistakenly incorporated into a branch and you need to undo the changes that were applied, in this case git revert {commitId} and this will create a new commit that undoes the changes made to the files by the supplied commit.

The third and last scenario to deal with is the most complex. It consists in that many changes were incorporated in a branch by mistake, for example of other functionalities, these are not ordered, they were made on different dates and/or by different people, leaving a long succession of commits. In this case the solution is to use an interactive rebase. For this, it is first necessary to identify those commits that should be kept and those that should be deleted.

With git rebase -i {commitId} you indicate from which commit you need to fetch the history. An editor will open showing lines in the format pick commitId commitMessageYou must go one by one and change pick to drop for those commits that you want to remove from the branch history, or to edit for those where you want to change the message. Sometimes interactive rebasing is not possible because of the way the commits were made, for example one that you want to keep has as a base one that you want to delete.

Code review

In collaborative work in a repository it is necessary that peers review the code that each member wants to include in the common branches of the project. For example, the branch used for deployment to production must be free of errors. For this it is necessary to create pull requests, depending on the service used the way it is done varies, but essentially it consists of a request where it is indicated to which branch you want to make the merge, automatically the commits that exist in the branch that do not exist in the target branch (base) and the people to whom the review is requested are listed.