Code management – GIT y DevOps. Part 1

This article consists of two parts: the first one, more theoretical, where we will explore various concepts, and a second part, where we will focus on putting everything from the first part into practice.

GIT

GIT is a distributed version control system, which means that instead of having a single space to store the entire version history, each developer’s copy of the work can contain the complete history of all changes.

GIT is able to detect changes made in the code since the last saved version and maintain a history of all saved changes.

Main features:

• Performance: uses algorithms for change detection and tracking, along with its distributed architecture. .
• Security: designed to ensure the integrity of the source code.
• Flexibility: allows simultaneous execution of different workflows, making it useful for both large and small projects, as well as for various systems and protocols.

Actions in GIT are carried out with commands in the terminal. Although we typically don’t use them directly because we work in an integrated way within the IDE, it’s important to know about them in case they need to be used.

For example:

• Commit: git commit -m “commit message”
• Add: git add <file>

Terminology

Repository:
A repository in GIT is a storage space for the source code, the files needed for the project, and a record of all changes made to the repository. We will have as many repositories as projects we are working on or have worked on, keeping each project separate.
Repositories can be local or remote. This stems from GIT being a distributed version control system, allowing the same code to exist in multiple locations.
Work is done with both remote and local branches. Remote branches are on the server, where all collaborators’ projects are uploaded and where all final changes will be stored. When starting a new project, a developer will create a local copy of the remote branch to work with.
The difference between GIT and other version control systems lies in how data is managed. Typically, version control systems store a list of changes made to each file in each version. However, GIT saves snapshots of the files at the moment changes in a version are committed. This approach helps ensure data integrity.
GIT secures all committed changes with a Checksum, a verification sum generated from the content of the files, preventing any file modification without GIT detecting it and requiring confirmation and documentation of the change.

Add, Stage, Commit:

These are the different states that our files go through.

• Untracked: the initial state of all files. The objects we create in our local repository will be untracked until we add them to GIT’s change tracking.
• Unmodified: when a file has already been added to the repository and committed at some previous point, and no changes have been made to it since the last version.
• Modified: when a file has been changed since the last committed version.
• Staged: when a modified file is added to the next commit. Essentially, it is added to the list of files that will be committed when the commit is made.

Rollback:
What happens if we commit something we shouldn’t, and everything starts failing?

We have two options to undo:

• Revert: a new commit is created that undoes the change we want, thus preserving the change history.
• Reset: rewrites the commit history by undoing the changes we specify.

If we haven’t committed the changes yet and want to undo what we’re doing, we have the checkout option, which returns the object to the state it was in before we made our changes.

Branch, Merge:
As mentioned, in GIT we work with branches.

The main branch is called Main (originally Master), and from this branch, new branches are created. These are the branches we work on; this would be the branch concept.

Once our work is done, we will have to merge it to include it in the main branch.

On the other hand, we have the concept of stash, which is used to save changes in one branch while working on another.

Fetch, Pull, Push, Pull Request:
In a development team, it is essential to have a place where all the project code is stored. Typically, this storage is done remotely, meaning on a server that all collaborators have access to. On this server, the working branches are defined, known as remote branches.

To work locally with these remote branches, we use local branches, which are copies of the remote branches stored on the developers’ machines.

When we copy a remote branch to our local environment (through a fetch), we obtain the current version of that branch at that moment. However, other developers may make changes to the remote branch, which are not automatically synchronized with our local branches. To stay updated, we need to bring the changes from the remote branch to our local branch periodically. This can be done in two ways:

• Fetch: brings the changes from the remote branch that are not yet in the local branch but doesn’t merge them.
• Pull: brings the changes from the remote branch that are not in the local branch and then merges them with the local branch.

To protect the code added to remote branches, there are Pull Requests. These are change review requests that are created when attempting to merge remote branches, helping to ensure that not just any code is added to critical branches, such as Main, which typically contains the code deployed to production. Each request is assigned a reviewer, who is another collaborator in the repository responsible for validating and approving the proposed changes before the merge is completed.