What is Git?

Also known as: what the heck is it?

If you’re new to software development, you might be wondering: “What exactly is Git, and why does everyone keep talking about it?”.

This guide tries to explain version control in plain language, no computer science degree required.

The Simple Explanation#

Git is a version control system - in other words, it is a piece of software that tracks changes to your files over time. Think of it as an unlimited “undo” button for your entire project, combined with the ability to try experimental ideas without breaking what already works.

A Real-World Analogy#

Imagine you’re writing a novel:

Without Version Control:

  • novel.doc
  • novel_final.doc
  • novel_final_FINAL.doc
  • novel_final_FINAL_v2.doc
  • novel_final_FINAL_v2_THIS_ONE.doc
  • novel_final_ACTUALLY_FINAL.doc

You’ve probably seen (or created) something like this! 😅

With Git:

  • novel/ (one directory)
  • Full history of every change
  • Ability to jump back to any version
  • Notes about why you made each change
  • Separate “branches” for experimental chapters
  • Easy collaboration with co-authors

Much cleaner!

Why Version Control Matters#

Version control isn’t just a nice-to-have. It’s essential for modern software development.

Here’s why:

1. History and Accountability#

Git keeps a complete record of:

  • What changed (which lines of code were modified)
  • When it changed (exact timestamp)
  • Who changed it (which developer made the change)
  • Why it changed (commit message explaining the reason)

This “paper trail” is invaluable when tracking down when a bug was introduced or understanding why certain decisions were made in the past for example.

2. Safe Experimentation#

Want to try a new feature without breaking your working code? Git lets you:

  • Create a “branch” to experiment safely
  • Test your changes thoroughly
  • Merge the changes back if they work
  • Discard them if they don’t

Example scenario adding dark mode feature:

gitGraph
    commit id: "Initial commit"
    commit id: "Stable project"
    branch dark-mode-branch
    checkout dark-mode-branch
    commit id: "Start dark mode"
    commit id: "Experiment with colors"
    commit id: "Break things"
    commit id: "Fix issues"
    commit id: "Dark mode complete"
    checkout main
    merge dark-mode-branch tag: "Successful merge"

3. Collaboration Made Possible#

Multiple people can work on the same project simultaneously because each person has their own complete copy of the project. This allows everyone to work independently on their own changes. Git helps merge everyone’s work together and detects conflicts so they can be resolved. This way, no one accidentally overwrites someone else’s work.

Without version control, collaboration is a nightmare of shared drives, locked files, and lost work.

4. Backup and Recovery#

Git acts as a distributed backup system.

Every developer has a complete copy of the project history. If one computer dies, the project lives on. You can recover deleted files or undo bad changes because the entire history is preserved and recoverable.

5. Code Review and Quality#

Git also enables code review workflows since changes can be reviewed before being merged. This allows team members to discuss and improve code standards and quality.

Basic Git Concepts#

Let’s break down the fundamental concepts you’ll encounter:

Repository (Repo)#

A repository is a project tracked by Git. It contains:

  • All your project files (code, images, documentation, etc.)
  • The complete history of all changes
  • Metadata about branches, tags, and more

Think of it as a special folder that remembers everything that ever happened inside it.

Repository Types:

  • Local repository - On your computer
  • Remote repository - On a server like OpenCommit.eu

They sync with each other via git commands.

Commit#

A commit is a snapshot of your project at a specific point in time.

Each commit:

  • Captures the state of all files
  • Includes a message describing the change
  • Has a unique identifier (a long string of numbers/letters called a “hash”)
  • Points to its parent commit (the one before it)

Commit message example:

fix: change allow_din to true

If not set to true, the login form breaks due to a dependency on foo.

Good commit messages explain why the change was made, not just what changed.

Branch#

A branch is a separate line of development.

The default branch is usually called main or master. You can create new branches to:

  • Work on features without affecting the stable code
  • Experiment with ideas
  • Maintain different versions (e.g., stable vs. development)

Branching visualization:

gitGraph
    commit id: "A"
    commit id: "B"
    commit id: "C"
    branch feature
    checkout feature
    commit id: "D"
    commit id: "E"
    checkout main
    merge feature tag: "F"
    commit id: "G"

Here:

  • A, B, C are commits on main
  • At commit C, a new branch (feature) was created
  • D and E are commits on the feature branch
  • At F, the feature branch was merged back into main
  • Development continues on main with commit G

Working Directory#

Your working directory is the folder on your computer where you edit files. It contains the current version of all project files, files Git is tracking but also potentially files Git is ignoring.

This is where you do your actual work: creating, editing, and deleting files.

Staging Area (Index)#

The staging area is like a “pre-commit” zone. Before committing changes, you add them to the staging area.

Why? This lets you:

  • Commit some changes but not others
  • Review what you’re about to commit
  • Organize changes into logical commits

Workflow example:

1. Edit multiple files
2. Stage only the files related to one logical change
3. Commit those staged files
4. Continue working on other logical changes

This keeps your history clean and organized.

Remote#

A remote is a version of your repository hosted on a server (like OpenCommit.eu).

Common operations with remotes:

  • Push - Send your commits to the remote
  • Pull - Get commits from the remote
  • Clone - Make a local copy of a remote repository
  • Fetch - Download changes without merging them

You can have multiple remotes, but most projects have just one, commonly called origin.

The Basic Git Workflow#

Here’s the typical cycle of working with Git:

flowchart LR
    A[Clone/create repository] --> B[Edit files]
    B --> C[Stage changes]
    C --> D[Commit changes]
    D --> E[Push to remote]
    E --> B

Let’s break it down:

Step 1: Start with a Repository#

Either:

  • Clone an existing repository from OpenCommit.eu
  • Create a new repository locally

Step 2: Make Changes#

Edit your files using any text editor or IDE:

  • Add new files
  • Modify existing files
  • Delete files you no longer need

Step 3: Stage Your Changes#

Tell Git which changes you want to commit:

$ git add filename.txt          # Stage a specific file
$ git add .                     # Stage all changes

Step 4: Commit Your Changes#

Create a commit with a descriptive message:

$ git commit -m "Add new feature X"

Step 5: Push to Remote#

Send your commits to OpenCommit.eu (or another remote):

$ git push

Now your changes are backed up and visible to collaborators!

Step 6: Pull from Remote#

Before starting new work, get the latest changes:

$ git pull

This ensures you’re working with the most up-to-date code.

Git vs. OpenCommit.eu (and GitHub, GitLab, etc.)#

This is a common point of confusion for beginners:

Git is the version control software that runs on your computer.

OpenCommit.eu (like GitHub, GitLab, etc.) is a hosting service for Git repositories that adds:

  • Web interface for browsing code
  • Issue tracking
  • Pull request workflows
  • Project management tools
  • Collaboration features
  • Access control

Analogy:

  • Git is like email software (Thunderbird, Outlook)
  • OpenCommit.eu is like an email service (Gmail, ProtonMail)

You use Git locally, and OpenCommit.eu to share and collaborate.

Common Git Terms You’ll Encounter#

TermMeaning
CloneMake a local copy of a remote repository
ForkCreate your own copy of someone else’s repository
Pull RequestPropose changes to a project
MergeCombine changes from one branch into another
ConflictWhen Git can’t automatically merge changes
HEADReference to the current commit you’re on
OriginThe default name for the remote repository
UpstreamThe original repository you forked from
DiffThe differences between two versions

Real-World Git Use Cases#

Git isn’t just for code:

Software Projects#

  • Open source projects with global contributors
  • Team software development
  • Personal coding projects

Documentation#

  • Technical documentation
  • Wikis and knowledge bases
  • Books and long-form writing

Configuration Management#

  • Server configuration files
  • Dotfiles (personal system configurations)
  • Infrastructure as code

Other Uses#

  • Legal documents with tracked revisions
  • Game development and modding
  • Data science and research papers
  • Even some artists use it for tracking project files!

Next Steps#

Now that you understand what Git is and why it matters:

Ready to Install?
Install Git and set it up on your computer for use

Want to Try the Web Interface First?
→ Create your first repository and make commits without installing anything

Further Resources#

Want to dive deeper? Check out:

Remember: Everyone struggles with Git at first. Even experienced developers still look up commands. Don’t let initial confusion discourage you! It gets easier with practice, and the payoff is enormous!