Articles

What Is Git? Version Control, Explained for Beginners

Git is a distributed version control system that tracks changes to code and enables collaboration. Learn the core concepts and everyday workflow.

The Lycoris Team The Lycoris Team · · 3 min read
A laptop showing a terminal and version control

Git is a distributed version control system — software that tracks every change ever made to a set of files, lets you move between those changes, and makes it possible for many people to work on the same codebase without stepping on each other. It was created by Linus Torvalds in 2005 to manage the Linux kernel, and it is now used by virtually every software project on earth.

The short version: Git is a time machine and collaboration layer for your code.

Core concepts

Repository (repo) — a Git repository is a directory that Git is tracking. It stores all your files plus the complete history of every change ever committed to them. The history lives in a hidden .git folder at the root.

Commit — a snapshot of the repository at a specific point in time. Every commit has a unique ID (a SHA hash), an author, a timestamp, and a message describing the change. Commits are permanent; you never lose history.

Branch — a lightweight pointer to a specific commit. Creating a branch lets you develop a feature or fix a bug without touching the main line of code. When you’re done, you merge the branch back in.

Staging area (index) — a preparation zone between your working files and a commit. You explicitly choose which changed files to include in the next commit using git add. This lets you make several unrelated changes and commit them as separate logical units.

Remote — a copy of the repository hosted somewhere else, typically on a service like GitHub or GitLab. You push your commits to the remote to back them up and share them; you pull from it to get others’ changes.

Merge — combining the history of two branches. When a feature branch is finished, it’s merged into the main branch. Git handles most merges automatically; conflicts arise only when two branches changed the same lines of a file.

The everyday workflow

Most Git usage follows a simple loop:

# Start by getting a copy of the repository
git clone https://github.com/example/project.git

# Create a branch for your work
git checkout -b feature/add-login

# ... edit files ...

# Stage the files you want to include in the commit
git add src/auth.js src/login.html

# Commit with a descriptive message
git commit -m "Add login form and authentication flow"

# Push the branch to the remote
git push origin feature/add-login

# Later, pull down changes others have made
git pull origin main

A few other commands you’ll use constantly:

git status        # see which files have changed
git log           # browse the commit history
git diff          # see what changed line by line
git stash         # temporarily shelve uncommitted changes

Git vs GitHub

This distinction trips up almost everyone at first. Git is the version control software — it runs locally on your machine and has nothing to do with the internet. GitHub is a website that hosts Git repositories in the cloud and adds collaboration features on top: pull requests, code review, issue tracking, and CI/CD workflows.

GitLab and Bitbucket do similar things. You could use Git without any of them — but in practice, teams almost always pair Git with a hosting platform.

Why Git became universal

Before Git, most teams used centralized version control systems like SVN or CVS, where there was a single server and developers checked files in and out. If the server went down, work stopped. Merging was painful.

Git changed the model: every developer has a complete copy of the entire history. You can commit, branch, and browse history without network access. Merging is fast because Git stores relationships between commits, not file diffs. And branching is so cheap — creating one takes milliseconds — that using a branch for every feature or fix became the standard approach.

The pull request workflow, popularized by GitHub, built naturally on top of that: work on a branch, push it, open a PR, get it reviewed, merge it. That workflow is how most professional software development happens today. Understanding how branches and merges work (git rebase vs merge is worth reading once you’re comfortable with the basics) is key to working effectively in a team.

Takeaway

Git tracks changes to your code as a series of commits, lets you work on isolated branches, and syncs with remote repositories so teams can collaborate. The core workflow — clone, branch, add, commit, push, pull — covers the majority of everyday use. Once you’ve internalized those six commands, the rest of Git is just details.

The Lycoris Team The Lycoris Team · · 4 min read

What Is a Git Worktree? Multiple Branches, One Repo

A git worktree lets you check out several branches at once in separate folders, sharing one .git history without cloning the repo again.

#Git #Developer Tools #Version Control
Takina Takina · · 4 min read

What Is Semantic Versioning (SemVer)?

Semantic versioning encodes compatibility into a version number's three parts — major, minor, patch — so dependents know what a version bump might break.

#Developer Tools #Version Control #Software
The Lycoris Team The Lycoris Team · · 5 min read

Git Rebase vs. Merge: A Practical Guide

When should you rebase and when should you merge? A clear, example-driven breakdown of the trade-offs, plus a simple workflow you can adopt today.

#Git #Version Control #Workflow