Getting Started with Git: A Complete Beginner's Guide

Instead of an introduction

Hello, future Senior Software Engineer. Today we will talk about the version control system, namely Git (read as GIT, not JIT, as it might seem from the grammar of the English language). Yes, yes, I know that there is also Mercurial, SVN ... But let's be honest: their time has already passed, and I'm not going to waste your precious time on them. In order for you to understand the importance of knowing the git in our time, I will say this: without knowing / understanding this, you have nothing to do in programming. But the beauty is that for constant work you do not need to keep all the commands and possibilities in your head. You need to know a set of commands that will help you understand everything that is happening.

Git Basics

Git is a distributed version control system for our code. Why is she to us? For distributed teams, some kind of work management system is needed. Needed to keep track of changes that occur over time. That is, step by step, we see which files have changed and how. This is especially important when you analyze what was done within the framework of one task: this makes it possible to go back. Imagine a situation: there was a working code, everything was fine in it, but we decided to improve something, fix it here, fix it here. Everything is fine, but such an improvement broke half of the functionality, made it impossible to work. So, what is next? Without Git, one would have to sit for hours and remember how everything was originally. And so we just roll back a commit back - and that's it. Or what if there are two developers, who make their changes to the code at the same time? Without Git, it looks like this: they copied the code from the original, did what they needed. The moment comes and both want to add their changes to the main folder. And what to do in this situation?.. I don't even undertake to estimate the time to do this work. There will be no such problems at all if you use Git.

Installing Git

Install git on your computer. I understand that everyone has different OS, so I will try to describe for several cases.

Installation for Windows

As usual, you need to download the exe file and run it. Everything is simple here: click on the first Google link , install and that's it. For work, we will use the bash console that they provide. To work on Windows, you need to run Git Bash. Here's how it looks in the start menu: And this is the console in which you can work. In order not to go every time to the project folder to open the git there, you can open the console in the folder with the right mouse button with the path we need:

Installation for Linux

Usually git is already installed and included in Linux distributions, as it is a tool originally written for developing the Linux kernel. But there are situations when it is not. To check this, you need to open a terminal and type: git --version. If there is an intelligible answer, nothing needs to be installed. Open terminal and install. I work on Ubuntu, so I can tell you what to write for it: sudo apt-get install git. And that's it: now you can use the git in any terminal.

Installation on macOS

Here, too, you first need to check if there is already a git (see above, as on Linux). If not, the easiest way is to download the latest version from here . If XCode is installed, then git will already be automatically installed.

Git setup

The git has a user setting from which the work will go. This is a reasonable and necessary thing, because when a commit is created, git takes exactly this information for the Author field. To set up a username and password for all projects, you need to write the following commands:

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com

If there is a need to change the author for a specific project (for a personal project, for example), you can remove --global, and it will turn out like this:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

A little theory...

To be in the subject, it is advisable to add a few new words and actions to your appeal ... Otherwise, there will be nothing to talk about. Of course, this is some kind of jargon and tracing paper from English, so I will add meanings in English. What are the words and actions?

• git repository (git repository);
• commit (commit);
• branch
• merge (merge);
• conflicts;
• spool (pull);
• push (push);
• how to ignore some files (.gitignore).

And so on.

States in Git

The Gita has several states to understand and remember:

• untracked (untracked);
• modified (modified);
• prepared (staged);
• committed.

What does it mean?

These are the states that the files from our code are in. That is, their life path usually looks like this:

1. A file that is created and not added to the repository will be in the untracked state.
2. We make changes to files that have already been added to the git repository - they are in the modified state.
3. Of those files that we have changed, we select only those (or all) that we need (for example, we do not need compiled classes), and these classes with changes fall into the staged state.
4. A commit is created from the prepared files from the staged state and goes into the git repository. After that, the staged state is empty. But modified can still contain something.

It looks like this (the picture is from the official docks, so you can trust it)):

What is a commit

A commit is the main object in source control. It contains all the changes since that commit. The commits are linked together as a singly linked list. Namely: There is a first commit. When a second commit is created, it (the second one) knows what comes after the first one. And in this way you can track the information. The commit also has its own information, the so-called metadata:

• a unique commit identifier by which it can be found;
• the name of the author of the commit who created it;
• the date the commit was created;
• a comment that describes what was done during that commit.

Here's what it looks like:

What is a branch

A branch is a pointer to a commit. Since a commit knows which commit came before it, when a branch points to a commit, all previous commits are included in that commit. Based on this, we can say that there can be as many branches pointing to the same commit as you like. Work happens in branches, so when a new commit is created, the branch moves its pointer to the newer commit.

Getting started with Git

You can work only with a local repository, and with a remote one. To work out the necessary commands, you can use only the local repository. It stores all information only locally in the project in the .git folder. If we talk about the remote, then all the information is stored somewhere on the remote server: only a copy of the project is stored locally, the changes of which can be pushed (git push) to the remote repository. Here and below we will discuss working with the git in the console. Of course, you can use some graphical solutions (for example, in Intellij IDEA), but first you need to figure out what commands are happening and what they mean.

Working with git in a local repository

Next, I suggest that you follow all the steps that I did while you read the article. This will improve your understanding and assimilation of the material. So bon appetit :) To create a local repository, you need to write:

git init

This will create a .git folder in the location where the console is located. .git is a folder that stores all information about the git repository. You don't need to delete it ;) Next, files are added to this project, and their state becomes Untracked. To see what the status of the work is at the moment, we write:

git status

We are in the master branch, and until we move to another, everything will remain so. This way you can see which files have been modified but not yet added to the staged state. To add them to the staged state, you need to write git add. There may be several options here, for example:

• git add -A - add all files from the state to staged;
• git add . - add all files from this folder and all internal ones. Essentially the same as the previous one;
• git add <filename> - adds only a specific file. Here you can use regular expressions to add according to some pattern. For example, git add *.java: this means that you need to add only files with a java extension.

It is clear that the first two options are simple, but with the addition it will be more interesting, so we write:

git add *.txt

To check the status, we use the command we already know:

git status

This shows that the regular expression worked correctly, and now test_resource.txt is in a staged state. And finally, the last step (with a local repository, there will be one more with a remote one;)) - commit and create a new commit:

git commit -m “all txt files were added to the project”

Next, there is a great command to look at the history of commits on a branch. Let's use it:

git log

Here you can already see that our first commit has appeared with the text that we transferred. It is very important to understand that the text that we pass should define as accurately as possible what has been done for this commit. This will help many times in the future. An inquisitive reader who has not yet fallen asleep may say: what happened to the GitTest.java file? Now we learn, we use for this:

git status

As you can see, he has remained in the untracked state and is waiting in the wings. Or maybe we do not want to add it to the project at all? Sometimes it happens. Next, to make it more interesting, let's try to change our test_resource.txt text file. Let's add some text there and check the status:

git status

Here you can clearly see the difference between the two states - untracked and modified. GitTest.java is in untracked state and test_resource.txt is in modified state. Now that we already have files in the modified state, we can look at the changes that have been made to them. You can do this with the command:

git diff

That is, here you can clearly see what I added to our text file hello world! Add changes to the text file and commit:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”

To see all commits, we write:

git log

As you can see, there are already two commits. In the same way, we add GitTest.java. Now without comments, just commands:

git add GitTest.java
git commit -m “added GitTest.java”
git status

Working with .gitignore

Clearly, we only want to keep the source code and nothing else in the repository. What else could there be? At a minimum, compiled classes and/or files that create development environments. To make git ignore them, there is a special file that needs to be created. We do this: we create a file at the root of the project called .gitignore, and in this file each line will be a pattern to ignore. In this example, git ignore would look like this:

```
*.class
target/
*.iml
.idea/
```

Let's look now:

• the first line is to ignore all files with a .class extension;
• the second line is ignoring the target folder and everything it contains;
• the third line is ignoring all files with the .iml extension;
• the fourth line is ignoring the .idea folder.

Let's try with an example. To see how it works, let's add the compiled GitTest.class to the project and check the status of the project:

git status

Clearly, we don't want to accidentally (using git add -A) add a compiled class to the project. To do this, create a .gitignore file and add everything that was described earlier: Now let's add a new commit git ignore to the project:

git add .gitignore
git commit -m “added .gitignore file”

And now the moment of truth: we have an untracked compiled GitTest.class that we didn't want to add to the git repository. This is where git ignore should work:

git status

Everything is clean) Git ignore +1)

Working with branches and others

Of course, it is inconvenient to work in one branch alone and impossible when there is more than one person in the team. There is branching for this. As I said before, a branch is just a movable pointer to commits. In this part, we will look at work in different branches: how to merge changes from one branch to another, what conflicts can arise, and much more. To see a list of all branches in the repository and understand which one you are on, you need to write:

git branch -a

It can be seen that we have only one master branch, and the asterisk in front of it says that we are on it. By the way, to find out which branch we are on, you can also use the status check (git status). Next, there are several options for creating branches (there may be more, I use these):

• create a new branch based on the one we are on (99% of cases);
• create a branch based on a specific commit (1%).

Create a branch based on a specific commit

We will rely on the unique commit identifier. To find it, we write:

git log

I highlighted the commit with the comment “added hello world…”. It has a unique identifier - "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". I want to create a development branch starting from this commit. For this I will write:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

A branch is created that will only have the first two commits from the master branch. To test this, we first make sure we have moved to another branch and look at the number of commits on that branch:

git status
git log

And it’s true: it turned out that we have two commits. By the way, an interesting point: this branch does not yet have a .gitignore file, so our compiled file (GitTest.class) is now highlighted in an untracked state. Now we can revise our branches again by writing:

git branch -a

It can be seen that there are two branches - master and development - and now we are standing on development.

Create a branch based on the current one

The second way to create a branch is to create from another. I want to create a branch based on the master branch, so I need to switch to it first, and the next step is to create a new one. We look:

• git checkout master - go to the master branch;
• git status - check if it's on the master.

Here you can see that we switched to the master branch, git ignore is already working here, and the compiled class no longer glows as untracked. Now create a new branch based on the master branch:

git checkout -b feature/update-txt-files

If there is any doubt that this branch will not be the same as master, you can easily check this by writing git log and look at all the commits. There should be four of them.

Resolving conflicts

Before dealing with what a conflict is, we need to talk about merging (merging) one branch into another. This picture can show the process when one branch is merged into another: That is, there is a main branch. At some point, a secondary one is created from it, in which changes occur. Once the work is done, you need to merge one branch into another. I will not describe the different features: I want to convey only an understanding within the framework of this article, and you will find out the details yourself, if necessary. So, in our example, we created the feature/update-txt-files branch. As written in the branch name, update the text. Now you need to create a new commit for this case:

git add *.txt 
git commit -m “updated txt files”
git log

Now, if we want to merge the feature/update-txt-files branch into master, we need to go to master and write git merge feature/update-txt-files:

git checkout master
git merge feature/update-txt-files
git log

As a result, now the master branch also has a commit that was added to feature/update-txt-files. This functionality has been added, so you can delete the feature branch. To do this, we write:

git branch -D feature/update-txt-files

As long as it's clear, right? We complicate the situation: now let's say that we again need to change the txt file. But now also in the wizard this file will be changed as well. That is, it will change in parallel, and git will not be able to understand what needs to be done in a situation where we want to merge new code into the master branch. Go! We create a new branch based on master, make changes to text_resource.txt and create a commit for this case:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

Switch to the master branch and also update this text file on the same line as the feature branch:

git checkout master
… обновor test_resource.txt

git add test_resource.txt
git commit -m “added master header to txt”

And now the most interesting point: you need to merge the changes from the feature/add-header branch to master. We are on the master branch, so all we have to do is write:

git merge feature/add-header

But we will get the result with a conflict in the test_resource.txt file: And here we can see that git could not decide on its own how to merge this code and says that you need to resolve the conflict first, and only then make a commit. Ok, open the file in which the conflict is in a text editor, and see: To understand what git did here, you need to remember what we wrote where and compare:

1. between “<<<<<<< HEAD” and “=======” are the master changes that were on that line in the master branch.
2. between “=======” and “>>>>>>> feature/add-header” are the changes that were in the feature/add-header branch.

Thus git shows that at this point he could not figure out how to merge this file together, he divided this section into two parts from different branches and suggested that we decide for ourselves. Well, with a firm will, I decide to remove everything, leaving only the word header: Let's look at the status of the changes, the description will be somewhat different. The state will not be modified, but Unmerged. So it was safe to add a fifth state ... But I think it's redundant, let's see:

git status

Convinced that this is a different case, unusual. We continue:

git add *.txt

In the description, you can see that they suggest writing only git commit. Listening and writing:

git commit

And that's it: this is how we did it - we resolved the conflict in the console. Of course, in development environments, you can do this a little easier, for example, in Intellij IDEA everything is set up so well that you can perform all the necessary actions in it. But the development environment does a lot of things “under the hood”, and we often do not understand what exactly happened there. And when there is no understanding, then problems can arise.

Working with remote repositories

The last step is to deal with a few more commands that are needed to work with the remote repository. As I said, a remote repository is some place where the repository is stored and from where you can clone it. What are remote repositories? Examples of darkness:

• GitHub is the largest repository for repositories and collaborative development. I have already described it in previous articles.
  Follow my github account . I often exhibit my work there in the areas that I study during my work.

• GitLab is an open source web- based DevOps lifecycle tool that provides a code repository management system for Git with its own wiki, issue tracking system , CI/CD pipeline, and other features. After the news that Microsoft bought GitHub, some developers duplicated their work in GitLab.
  

• BitBucket is a project hosting and collaborative web service based on Mercurial and Git version control. At one time had a big advantage over GitHub in that it had free private repositories. Last year, GitHub also opened up this feature to everyone for free.

• And so on…

The first thing to do when working with a remote repository is to clone the project into your local one. For this case, I exported a project that we made locally, and now everyone can clone it for themselves by writing:

git clone https://github.com/romankh3/git-demo

You now have a complete copy of the project locally. To be sure that the latest copy of the project is locally, you need to, as they say, spool the data by writing:

git pull

In our case, nothing has changed remotely now, so the answer is: Already up to date. But if I make any changes in the remote repository, the local one will be updated after we spool them. And finally, the last command is to push the data to the remote repository. When we have done something locally and want to commit it to a remote repository, we first need to create a new commit locally. To do this, let's add something else to our text file: Now the thing that is already common for us is to create a commit for this case:

git add test_resource.txt
git commit -m “prepated txt for pushing”

And now the command to push this to the remote repository:

git push

That's all I wanted to tell. Thank you for your attention. Follow my GitHub account where I post cool sample projects from what I learn and use at work.

useful links

• The official dock on the git, is in Russian . Recommended as a reference.
• git