Introduction to Git: why version control matters

1. The problem without version control: why simply copying files is a bad idea

Let’s start with a real-life situation. Imagine you are working on your Kotlin project. Everything is going well—until the moment of “experiments” arrives. You decide to change something, but you’re afraid of breaking the working version. What do you do? Of course—copy the project!

As a result, masterpieces like these appear on your disk:

MyProject/
├── Main.kt
├── Main_backup.kt
├── Main_final.kt
├── Main_final2.kt
├── Main_really_final.kt
├── Main_really_really_final.kt

Familiar? Now imagine that another friend has joined the project. They also like copying files—just in their own way. How do you figure out which version is the newest and actually working? How do you know who changed what? How do you restore everything if the experiment failed?

Without version control:

• It’s easy to lose or mix up working code.
• It’s impossible to “roll back” to an older version.
• It’s hard to work in a team of two or three.
• Chaos and fear of experimenting.

These are exactly the problems solved by version control systems—such as Git.

2. Why does a developer need Git?

Git is a powerful version control system used to track changes in source code during software development. It enables developers to save different versions of files and coordinate the work of multiple people on a shared project.

Core Git concepts:

Repository

A repository, or “repo,” is a place where the entire project history is stored, including all changes and versions of files.

Commits

commit is a saved state of the project. Each commit in Git contains information about what changes were made to the project, by whom, and when. Commits form the project history and make it possible to return to any previous version.

        gitGraph
        commit id: "1"
        commit id: "2"
        commit id: "3"
        commit id: "4"
        commit id: "5"
        commit id: "6"
    

Each commit is a “snapshot” of the project that follows the previous one, forming a consistent history of changes.

Branches

branch is an independent line of development. By default, Git creates the main branch. You can create new branches to develop new features or fixes, and then merge them back into the main branch.

        gitGraph
        commit id: "1"
        commit id: "2"
        branch develop
        commit id: "3"
        commit id: "4"
        commit id: "5"
        checkout main
        commit id: "6"
        commit id: "7"
        merge develop
        commit id: "8"
        commit id: "9"
    

From the main branch main, the develop branch “splits off” for parallel development. After the work is completed, changes from develop are merged back into main.

3. Basic Git commands (what’s under the hood)

Below is a list of the basic commands for working with Git via the terminal. It’s important to understand which commands are the foundation of all operations. However, we will follow a GUI approach and learn to do all these actions using the convenient graphical interface in IntelliJ IDEA. Think of these commands as what happens “under the hood.”

These commands are the core tools in Git, allowing you to manage code changes, branches, and merges in projects of any size.

        sequenceDiagram
        participant Working directory
        participant Staging area (Staging)
        participant Local repository
        participant Remote repository

        Working directory ->> Staging area (Staging): git add (Stage)
        Staging area (Staging) ->> Local repository: git commit (Save locally)
        Local repository ->> Remote repository: git push (Send to server)
        Remote repository ->> Working directory: git pull (Download updates)
    

4. Four states (storage locations) of code

When you use a version control system for your code, it will logically pass through four states:

1. Working directory (Working Directory)

The working directory on your computer contains the current project files you are working on right now. This is where you can view and modify files, write code, add new functionality, or fix bugs.

2. Staging area (Staging Area)

This is an intermediate zone between your working folder and the local repository. In terms of the IDE’s GUI, these are the very checkboxes you tick next to changed files before you press the Commit button. You choose which files and changes are ready to go into the next “snapshot” of history.

3. Local repository (Local Repository)

The local repository is your personal copy of the code history stored on your computer. In this repository, you can perform all Git operations (commits, branching, merging) without needing an internet connection.

4. Remote repository (Remote Repository)

This is a centralized place to store your code, usually hosted on services like GitHub, GitLab, or Bitbucket. They provide reliable code storage on servers and are the foundation for collaborative teamwork.

5. GitHub as your portfolio

It’s important to clearly distinguish two concepts: Git and GitHub. Git is a program that runs locally on your computer (even without the internet) and tracks file versions. GitHub is a cloud service (a website) where remote copies of your Git repositories are stored.

GitHub is the leading web platform for hosting source code, using the Git version control system. Founded in 2008, it quickly became one of the key tools for developers worldwide.

GitHub enables users to create repositories for project management, control and track changes in code, and collaborate with other developers. For a modern developer, a GitHub profile is an important part of a portfolio that can be shown to potential employers.

6. Creating your first repository on GitHub

Step 1. Go to https://github.com and sign up.

Step 2. Click the New repository button to create a new repository.

Step 3. Set the repository parameters:

1. Repository name: come up with a meaningful name.
2. Public or private: for learning projects, it’s better to choose “Public” so others can see it.
3. Add a README file: be sure to check this box. The README is the “face” of your project.
4. Add .gitignore: click the dropdown and choose the Kotlin template (or Java). This will protect your repository from heavy build outputs and local IDE settings.
5. Choose a license: you can skip this.
6. Click Create repository.

Step 4. Congratulations—your first remote repository has been created!

7. Installing and configuring Git

Although you can learn the basics of Git through console commands (as shown in the video), in day-to-day work 99% of developers use the convenient tools built into the IDE. Our goal is to teach you to work the way professionals do.

The interface for working with Git in all modern JetBrains IDEs—whether it’s IntelliJ IDEA for Kotlin/Java, Rider for C#, or PyCharm for Python—is almost identical. This means that once you learn Git in one environment, you can easily apply the same skills in any other. That’s why we will use IntelliJ IDEA as a universal example. Everything you see here will look and work exactly the same in your favorite IDE.

To work with Git on your computer, you first need to install Git. If you use IntelliJ IDEA, it will most likely offer to install Git automatically if it is not found on the system. We recommend agreeing—this is the easiest path.

Close the current project by selecting File | Close Project from the top menu. On the Welcome Screen, click Clone Repository (in some UI versions it may be called Get from VCS).

If you want to install it manually, use the official website: https://git-scm.com/downloads.

Important nuance

When you make your first commit in the IDE, IntelliJ IDEA will ask you to introduce yourself—enter a username and email. It is critically important to enter the exact email you used to register your GitHub account.

The reason is that GitHub links the authorship of your commits to your profile using this email address. If the addresses match, your avatar will appear next to your commits, and the coveted green activity squares in your profile—something employers love to look at—will start filling in.

8. A bit of history: main vs master

Previously, the default branch in Git was called master. However, in 2020 the developer community and major platforms, including GitHub, switched to using a more neutral term: main.

This is important to know because in some older articles or projects you may still encounter references to the master branch. In our lectures and in modern projects, the main branch will always be main.

You can learn more about the transition to main at the following links:

• Git Tower: Rename Master to Main
• GitHub: Renaming