Practicing Basic Git Commands

The GitLab product is built around a separate tool called Git. GitLab makes Git easier to use and gives you a central place to store all the files that Git is looking after, in addition to providing many other non-Git-related features. We like to think of GitLab as a wrapper around Git, making it more pleasant to use and more powerful.

Although GitLab and Git are different tools, GitLab borrows many concepts from Git. This means that to understand GitLab, you need to understand Git. Fortunately, you only need to get to grips with the very basics of Git. We say “fortunately” because Git is an enormous and complicated tool and learning all of its nooks and crannies would take a huge effort. But trust us: if you understand the first 10% of Git, you can use GitLab effectively. That 10% is exactly what we’re going to introduce you to in this chapter.

First, we’ll show you why version control systems such as Git are such a useful...

Technical requirements

For this chapter, you need to have Git installed on your local computer. Git works on Linux, macOS, and Windows, as well as many Unix variants. There are easy-to-follow instructions for installing Git on any of these operating systems at https://git-scm.com/downloads. If you’re asked to set configuration options during installation, it’s safe to accept all the default values.

To type the Git commands that you’ll see in this chapter, use your favorite terminal application on Linux or macOS. If you’re a Windows user, you can type them in Command Shell, PowerShell, or Git Bash. The default configuration options while installing Git on Windows should make Git available on any of these types of Windows terminals, and they should all produce identical results when you run Git commands in them.

The Git examples you’ll see in this book are operating system-agnostic: Git works the same no matter where you run it.

To see if it...

Why use Git?

Just like it was helpful to understand how we built software before automation tools such as GitLab CI/CD pipelines came along (as discussed in Chapter 1), it’s helpful to know how teams coordinated the complicated process of making edits to the same files before Git or similar tools came along.

These tools are designed to solve many problems that developers face, but let’s look at just one. Imagine that you and your teammate Elizabeth are working on the same code base and both of you want to edit some of the same files. Furthermore, imagine that this is a time before the advent of Git or any other version control system (VCS). The only way to write software in this pre-Git era is for you to edit a file and then email it, put it on a shared network drive, or copy it to a portable disk. Then, you must let Elizabeth know that she’s free to edit it. She checks it out in some sense (maybe by adding an entry to a spreadsheet saying that she’s...

Committing code to keep it safe

To benefit from all the advantages described previously, you need to know how to add files to Git. How do you do that?

First, let’s discuss the concept of a repository, which is often shortened to repo A repository is a place where Git stores a project’s files and a history of all the changes made to those files. It’s the bank vault where it puts files to keep them safe.

There are two main ways to create a repository. The first way is to convert an ordinary directory on your Linux, macOS, or Windows filesystem into a Git repository. This is easy: use the git init command from inside the directory, and voilà – it turns into a Git repository. Then, you can use the git status command to prove that it’s a repo.

Let’s use those commands to create a new repository for our Hats for Cats project. First, make a new directory that will become a repository, and move into that directory (the example in this...

Tagging commits to identify versions of code

Now that you understand how and why developers commit code to Git, we can explain tagging. Tagging is simple: it’s a way to add a permanent label to a commit. There are many reasons to tag, but the two most common are to mark the exact version of code that is released to customers and to have a convenient way to return to a particular version of the code if you need to revert a large batch of changes. Let’s look at an example of each.

Imagine that Hats for Cats is ready to release version 0.1-beta to users. Tagging a particular commit with that version number lets you know exactly what features have been deployed into production and are available to your users, which tells you which version of the code to fix as you triage bug reports. Adding this sort of identification via a tag is easy in Git. First, make sure that you have committed all the edits to all the files you want to include in your release. Then, use the git...

Branching code for developing in an isolated space

After commits, branches are probably the most important concept in Git. Strictly speaking, you don’t need to know anything about branches and branching to use Git. This is especially true if you’re a solo developer. But any non-trivial software development effort that involves more than one person will generally make heavy use of branches. Let’s figure out what they are and why we need them.

A branch is just a series of ordered commits. Remember when we said that each commit includes a backward pointer to the previous commit? If you follow those backward pointers from the latest commit back to the first commit ever made to the repository, you’ve just described the branch that your commit is on. Again, a branch is just a series of commits, assembled in a particular order, linked by backward-pointing arrows.

Whenever you’re working on files within a Git repository, you’re on exactly one...

Syncing local and remote copies of repositories

Git can be a useful tool for solo developers, but it’s most often used within a team of developers. As we’ve already discussed, Git’s distributed architecture means that every developer on the team has a complete copy of the project’s repository, including all its commits, commit messages, branches, and all the other data and metadata that is included in a repository. Keeping these repositories synced, so that they all have the same information in them, is critically important. If my copy of the repository and your copy of the repository contain different files or different edits to the same files, then I can’t see what work you’ve done and vice versa. And if my copy of the repository doesn’t contain the branches that you’re adding commits to, I can’t review and approve your work. Synchronizing repositories isn’t an automatic process: it involves active participation...

Additional resources for learning Git

A word of caution is needed at this point. You’ve only seen the most basic usages of the Git commands introduced in this chapter. There are many options available to change the behavior of these commands, and there are many different wrinkles and nuances to using them correctly in different situations. We’ve already mentioned that the important concept of resolving merge conflicts is beyond the scope of this lightning-fast introduction to Git, but some other important concepts and practices are likely to crop up in daily Git usage that we don’t have space to cover here, including rebasing and choosing between fast-forward merges and commit merges. We also can’t describe common troubleshooting processes when you find your files in an unwanted or unfamiliar condition while using Git. What we can do, however, is point you to some other resources that you can use to continue to expand your knowledge of Git and your repertoire...

Summary

Pause, take a deep breath, and pat yourself on the back. You’ve learned a lot about a complicated tool in a very short time.

You now understand how and why programmers use VCSs to handle a wide variety of daily tasks and problems, and why Git’s features and architecture have helped it become the preferred VCS. You also know about the most used Git concepts and commands.

Now that you’ve completed this chapter, you can create new Git repositories using git init and git clone; add file edits with git add and git commit; tag commits for future reference with git tag; list, create, or delete branches with git branch; merge branches with git merge and resolve any merge conflicts that arise; and sync local branches with branches on the golden repo with git push, git fetch, and get pull.

You also know where to look to learn more about Git, whether you need tutorial steps, reference material, or troubleshooting help.

With this background in Git under...