Git — what it is, how it works, and commands

What is Git?

Git is a distributed version control system (VCS) that tracks changes in files and allows multiple developers to work on the same project simultaneously. Unlike centralized systems, in Git each developer has a complete copy of the repository, including the entire change history, making the system resistant to data loss and not requiring a constant connection to a central server.

Git’s history began in 2005 when Linus Torvalds created a new VCS after BitKeeper revoked its free license for Linux kernel developers. The goals were: speed, simplicity of architecture, support for nonlinear development through branching, and full distribution. In 3 months Torvalds wrote the core of Git, and within a year the project became self-managed under the leadership of Junio Hamano.

According to the Stack Overflow survey (2024), Git is used by 93.9% of professional developers, making it the dominant version control system in the industry. The closest competitor — Subversion (SVN) — is used in only 5.2% of projects, primarily in large corporate environments with centralized processes.

How Git Works: Repository and Commits

Git Repository is a directory where Git tracks changes to all files. Inside the directory there is a hidden folder .git that stores all system objects: commits, trees, blobs, and references. When a developer creates a commit, Git does not copy files entirely — it creates a snapshot and saves a reference to it.

Each commit contains: a unique SHA-1 hash (40 characters), a reference to the previous commit (parent), author, date, commit message, and a reference to a tree that describes the state of files at the time of the commit. The chain of commits forms a directed acyclic graph where each commit points to one or more parents.

# Repository initialization
git init my-project
cd my-project

# Creating a commit
echo "Hello, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Viewing history
git log --oneline --graph --all

Git uses three main areas: working directory (files on disk), staging area (index where prepared files go), and repository (commit history). The git add command moves changes from the working directory to staging, and git commit records the contents of staging into the repository. This separation allows the developer to assemble a meaningful commit from a set of changes without committing each edit separately.

Basic Git Commands

Basic Git commands cover 90% of a developer’s daily operations. The git clone command creates a local copy of a remote repository, git pull fetches changes from the server and merges them with the current branch, and git push sends local commits to the server. These three commands form the main Git workflow cycle.

To view the status, git status is used — it shows which files are modified, which are added to staging, and which are untracked. git diff displays specific changes in files before adding to staging. Below is a table with the most frequently used commands:

To undo changes, Git provides several options. git reset moves the branch pointer to a specified commit and can reset the staging area or working directory. git revert creates a new commit that reverts the changes of the specified commit — this is a safe way to revert for shared branches because history is not rewritten.

Branching in Git: main, feature and release

Branches in Git are lightweight movable pointers to a specific commit. Creating a new branch does not copy files, but merely creates a new pointer, making branching virtually instantaneous. The main branch (formerly master) is the main project branch containing stable, release-ready code.

Standard practice is to use Git Flow or GitHub Flow. Git Flow uses branches: main (release code), develop (integration branch), feature/* (new features), release/* (release preparation), and hotfix/* (urgent fixes). GitHub Flow is simpler: only main and feature branches, and all changes are delivered via Pull Request.

# Creating and switching branches
git branch feature-auth
git checkout feature-auth
# or with a single command:
git checkout -b feature-auth

# List of branches
git branch --list
git branch -a  # all branches, including remote ones

# Deleting a branch
git branch -d feature-auth

An important feature of Git branching is cherry-pick: moving an individual commit from one branch to another using the git cherry-pick <hash> command. This is useful when you need to transfer a bug fix from a feature branch to a release without merging the entire branch. Git also supports rebasing and interactive rebasing (git rebase -i) for squashing, reordering, and editing commits.

Merge and Rebase

Merge creates a special merge commit that has two parents. This commit records the fact of merging two branches and preserves the full history — you can see where and when the merge happened. Merge preserves history as it was created, which simplifies auditing but makes the commit graph more complex.

Rebase instead of creating a merge commit, moves the commits of the current branch onto the tip of the target branch. The history becomes linear — creating the impression that development was sequential. However, rebase rewrites history, changing SHA-1 hashes of commits, making it dangerous for shared branches that other developers have access to.

Recommendation: use merge for public branches where history is visible to other developers (feature → develop), and rebase for local work when you need to apply fresh changes from main to your feature branch before creating a Pull Request. The rule is simple: if a commit has already been pushed to the server — do not rebase it.

Resolving Conflicts

Merge conflict occurs when Git cannot automatically merge changes in a single file. Git marks conflicting sections in the file with special markers: <<<<<<< (our changes), ======= (separator), >>>>>>> (their changes). The developer manually edits the file, choosing the desired option or combining both, and completes the merge with a commit.

Working with Remote Repositories

Remote repository is a copy of a Git repository located on a server. GitHub, GitLab and Bitbucket are the most popular platforms for hosting remote repositories. They provide a web interface for viewing code, access management, code review, and CI/CD integration.

In Git, you can configure multiple remote repositories for one project. By default, the main remote is called origin. The git remote add command adds a new remote, git fetch fetches changes without merging, and git pull is shorthand for git fetch + git merge. To work with code via Pull Request, a developer creates a fork of the repository, clones it, works in a feature branch, and sends a merge request to the original repository.

# Adding a remote repository
git remote add origin https://github.com/user/repo.git

# Viewing remote repositories
git remote -v

# Pushing a branch to the server
git push -u origin feature-auth

# Fetching changes from a remote branch
git pull origin main

Remote repositories support tagging for marking release versions. Tags can be lightweight (just a pointer to a commit) or annotated (contain metadata: author, date, message). Annotated tags are recommended for release versions because they carry full version information and can be signed with a GPG key for verification of authorship.

Git Worktree for Parallel Work

Git Worktree allows you to work with multiple branches simultaneously in different directories without switching between them. The git worktree add ../feature-auth feature-auth command creates a new working directory feature-auth where you can write code without switching branches in the main directory. Worktree is useful for quick fixes in a release branch when the main directory is occupied with long-term development.

Git Submodules for Dependencies

Git Submodules is a mechanism for including one Git repository inside another. A submodule stores a reference to a fixed commit of an external repository, ensuring build reproducibility. The git submodule add https://github.com/example/lib.git command adds an external library as a submodule. When cloning a project with submodules, you need to run git submodule update --init --recursive to download all dependencies.