Let's say you write code, or work on a book, or even just want to collect and update a set of text-based documents. You need some method of keeping track of changes, of being able to revert mistakes in the work, or branch in new directions; and you'll probably want some way of remotely backing up your work in case of fire, theft, or acts of a misbehaving computer. This is where version control systems (also known as VCS) come in handy. They save your work at certain points (commits) and can be reverted to earlier states; many VCS offer methods of branching so that you can – for example – work on a specific feature without interrupting someone else's work on another component. There are many version control systems on the market, but the most prominent in the public eye would be Git. Git is a distributed version control system, which means that it has a full copy of all of the code that exists on each user's computer, and users can pass patches and changes directly between each other rather than entirely relying on a centralized server.

Behind the scenes, git is an advanced program that is lightning fast when it comes to performing operations like staging work, committing changes, or swapping between branches. It's efficient at fetching information from remote repositories to help speed up a user's workflow. Unlike most VCS, git doesn't work by storing the changes that happen to each file. Instead, on every commit, git stores a snapshot of the current state of all files. If a file hasn't changed, rather than storing it again, it simply stores a reference to the last saved version of the file.

When you make a commit, git captures the snapshot and also takes a cryptographic hash – a series of complex mathematical operations on the data that produces a unique value – and uses the output of that as a reference to the commit, along with some metadata, such as the author. This snapshot sits on top of the rest of the snapshots/commits that you've taken, and in this way you can think of git snapshots as a series of changesets – operations that add or remove lines – that can be performed on your files to get them to an older or newer state.

We'll cover more on the higher-level use and commands of Git in Chapter 3, GitLab Flow, when we explore the GitLab flow for branching and merging.

GitLab is built on top of git so that users who are contributing work (editing code, writing chapters, and so on) to a project will have a copy of the project downloaded/checked out/cloned on their local computer. It provides a web interface for handling many of git's more advanced workflows, and recommends a workflow for interacting with git for the best in productivity, efficiency, and ease of use. We'll cover this workflow in a lot more detail in Chapter 3, GitLab Flow, and in Chapter 4, Issues to Merge Requests, where we'll explore the merging of branches in the GitLab user interface.

By acting as a single source of truth for your developers, GitLab can help you avoid conflicts and the double handling of work while maintaining uptime by relying on the battle-tested GitLab.com platform or your own installation of it, working with tools including geographic replication, disaster recovery, and automated failover.

GitLab provides a number of ways to view and interact with a git repository. There is the classic file browser that lets you explore the files in your repository:

There's also a branch viewer, which lets you see variations of your work under active development, as well as branches that are considered stale and no longer developed:

Alongside this is a tag viewer that lets you explore specific releases of your work:

There are tools that can be used to analyze and view the commit graph:

Among these tools are charting tools, which are used to get a better understanding of the composition of the repository:

Alongside this is a breakdown of the frequencies of commits and activity:

For users who are not familiar with git commands or those away from their work computer, GitLab also provides a web interface where you can make changes to code and commit it straight from the browser:

Aside from being a web interface for git, GitLab also provides tools for a variety of purposes, including powerful feature planning and issue management tools:

These tools help keep everyone in sync, allowing them to understand the current workload and roadmap and making sure that work isn't double-handled and is correctly prioritized. With things like epics, milestones, and cycle analytics, GitLab can help measure the effectiveness of your development process.

It also includes the necessary tools for code review prior to merging branches to ensure that all work is up to scratch:

Automated testing tools and pipelines are also included to help make sure that code is working perfectly before it's merged back in or released:

Thanks to the powerful, built-in, continuous integration/continuous deployment (CI/CD) platform (explored further in Chapter 5, Continuous Integration And Continuous Deployment), GitLab can not only test your code, but also build and deploy/release it under circumstances that you control.

GitLab can be used in one of two ways: either self-managed, where you host your own instance of GitLab Community Edition/Enterprise Edition, or using the online platform GitLab.com, which comes as a paid or free Software as a Service (SaaS) model.

Using GitLab.com comes with the benefits of no maintenance or infrastructure costs and regular automatic updates without any manual labour. They have an amazing setup with multiple backup strategies, redundancies, and failovers to ensure high uptime and no loss of data in the event of a major incident.

On the other hand, you might not feel comfortable putting all of your work on someone else's infrastructure, which is why GitLab provides an easy-to-install omnibus package that can be installed on your own computer or a server that you host. This can also be handy if you have strict security and firewall requirements that don't allow for externally hosted code. There's also the benefit of easy integration with your own LDAP or Active Directory services for user management, and potential performance gains in larger repositories from not having to shift large amounts of data over external network links.

Lastly, there are multiple tiers of GitLab for both the self-managed and SaaS versions. Please note that both versions can be used for free and provide all of the main features that you'd expect (git hosting, code review, issue management, testing, and deployment). The added tiers provide extra features that are available at different levels of pricing on a per-user, per-month basis. For example, at the lowest paid tier, you get priority and next-business-day support, and with the SaaS version, you also get burndown charts, multiple approval requirements on merge requests, and issue weighting. At the higher levels, more features get added, including the following:

• Service desk mode
• Canary deployments
• Support for multiple Kubernetes clusters
• CI/CD for external repositories
• Disaster recovery
• Epics
• Roadmaps, and much more

We'll cover more of these paid features in Chapter 7, Advanced and Paid Features.

So far, we've discovered what version control is: a method of tracking revisions of work, of creating alternate test branches, and working collaboratively. We know that git is a form of version control system that specializes in working in a distributed network and that GitLab is a platform that is based on git but with a lot of powerful features.

We discussed the features of GitLab, including issue and project management, continuous integration and continuous deployment, code review, and even online code editing. We also looked at self-managed GitLab versus using the online GitLab.com platform. You should also have an idea of the benefits of moving to a paid GitLab subscription.

In the next chapter, we'll discuss setting up GitLab for self-managed users, and go over both the quick omnibus installation and the manual installation method. We'll also look into how to create an account on a GitLab instance, whether a self-managed one or on GitLab.com.