# Learn Git Easily: A Beginner's Guide to Version Control

If you have ever struggled with sharing your code via pen drives or sending endless zip files through email, you are in the right place. It’s time to introduce you to Git.

## Git

In technical terms, Git is a Distributed Version Control System (DVCS).

In simple terms, Git is a time machine for our projects. It tracks every modification you make to our code. If you break something, you can simply "rewind" to a previous state where everything worked.

## Why do we use it?

1. **Collaborations:** Multiple people can work on the same file at the same time without overwriting each other’s work.
    
2. **Distributed Architecture:** Every developer gets their own local version of the repository with the full history and commits. It supports offline work and has no single point of failure.
    
3. Branching and Merging: Developers create a separate branch to work on a feature and can merge it into the main branch.
    

## Terminology Dictionary

Developers love using fancy words for simple things. Here is your translation guide to help you go through the article.

| Term | What it means |
| --- | --- |
| Repository (Repo) | The folder containing all your project files and the entire revision history. |
| Commit | A snapshot of your code at a specific point in time. It has a unique ID (hash). |
| Staging Area | The list of files you are planning to commit next. |
| Local | The version of the repository stored on your personal computer. |
| Remote | The version of the repository stored on the internet (like GitHub/GitLab). |
| Clone | Downloading a remote repository to your computer. |
| Push | Uploading your local commits to the remote server. |
| Pull | Downloading changes from the remote server to your local machine. |
| Merge | Taking code from one branch and combining it into another. |
| Branch | A parallel version of your code. Changes here do not affect the main project until you merge them. |
| HEAD | A pointer to the specific commit you are currently looking at or working on. |
| Origin | The default nickname Git gives to the remote URL (where you cloned from). |
| Pull Request (PR) | A request to merge your branch into the main branch. (Used on GitHub/GitLab). |

## The Core Architecture

Before moving to the commands, we must understand the three stages.

1. Working Directory (The Workbench): This is the actual folder where we type our code.
    
2. Staging Area (The Box): Pick specific files from the workbench and put in the box.
    
3. Local Repository (The Shipping Truck): You seal the box and label it. This is a Commit. It is part of the code history now.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767204512318/9b4de7ab-4c79-4f89-b66d-e2e6c863d657.png align="center")

## How a Repository looks

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767205882617/4b22c1f8-94f1-4618-877c-bc3300f90c43.png align="center")

* `src/`: The folder containing your actual source code, keeping the project organized.
    
* `.gitignore`: A text file listing everything Git should intentionally ignore (like secrets).
    
* `README.md`: The instruction manual that explains what your project is and how to run it.
    
* `LICENSE`: The legal document stating how others are allowed to use or copy your code.
    
* `.git/`: The hidden database where Git stores your entire project history and save points.
    

## The Developer Workflow

### Initialize

Tell Git to watch your folder

```bash
git init
```

### Check Status

Want to check your repo’s status

```bash
git status
```

### Stage

Create a file named `index.html`. Now run `git status` again. You will see the file in **red** (Untracked). Let's move it to the staging area using the command below.

```bash
git add index.html
```

To add all changed files at once, use `git add .`

Run `git status` again. The file is now **green**. It is staged and ready to be saved.

### Commit

Now we permanently save this snapshot to the history. You **must** include a message describing what you did.

```bash
git commit -m "Created the homepage file"
```

`-m`: Stands for "message".

### Lazy Shortcut

Tired of typing `git add` and then `git commit` every single time? We can combine them into one command.

```bash
git commit -am "Updated the style"
```

It will NOT stage new (untracked) files. Only modified/deleted tracked files.

### History

To see a list of all your saves

```bash
git log
```

### Difference

Before you stage or commit, you should always check what you actually changed.

```bash
git diff
```

## Branching

### Create Branch

By default, we are on the `main` (or `master`) branch. Let's create a new timeline:

```bash
git branch dark-mode-feature
```

### Switching Branches

Now we can switch to our new branch.

```bash
git checkout dark-mode-feature
```

Newer Git versions also support `git switch dark-mode-feature`

### Merging

You wrote your code in `dark-mode-feature`, committed it, and tested it. It works! Now you want to merge it back into the `main` branch.

1. Switch back to main: `git checkout main`
    
2. Merge the feature: `git merge dark-mode-feature`
    

## Going Remote

So far, everything has happened on your computer (Local). To share code, we need a Remote repository.

### Clone

Download existing Repo to local

```bash
git clone <url>
```

### Push

Upload local commits to remote Repo

```bash
git push origin main
```

### Pull

Download new changes from cloud to local computer

```bash
git pull
```

## Corporate Kit

### Stash

You are working on a new feature (messy code, half-broken). Suddenly, your boss says, *"Critical bug! Fix it now!"* You can't switch branches because your work isn't done, but you can't commit it yet either. We want to put our changes in a temporary storage drawer.

```bash
git stash
```

### Pop Stash

To get your stash back

```bash
git stash pop
```

### Reset

Sometimes you commit too early and want to go back. `git reset` lets you move back to provided commit, but it comes in two flavors.

**Soft Reset:** Undoes the commit but **keeps your code changes** in the staging area.

```bash
# Go one commit back (keep changes staged)
git reset --soft HEAD~1

# Go one commit back (keep changes unstaged) - mixed reset
git reset HEAD~1

# Go to a specific commit
git reset <commitHash>
```

**Hard Reset:** Undoes the commit and deletes all changes. It reverts everything to exactly how it was before you started working.

```bash
# Go one commit back (delete commit + delete changes)
git reset --hard HEAD~1

# Go to a specific commit (delete all changes)
git reset --hard <commitHash>
```

Warning: This deletes your work permanently. Burning the bridge behind you. There is no going back.

### Revert

You already pushed bad code to the shared `main` branch. You **cannot** use `reset` (because deleting history that others have downloaded will cause conflicts for other developers). Create a *new* commit that does the exact opposite of the bad commit.

```bash
git revert <commit-id>
```

### Git Cherry-Pick

Your teammate is working on a huge Experimental branch with 50 commits. They fixed a tiny bug in *one* of those commits. You want that bug fix, but you *don't* want the rest of their experimental code. Pick just that one commit and apply it to your branch.

```bash
git cherry-pick <commit-id>
```

### Rebase

You are working on a feature branch. Meanwhile, the main team has added 10 new updates. Your branch is now out of date. Instead of a messy merge, you **rebase**. This picks up your work and places it on *top* of the latest code, keeping the history in a straight line.

```bash
git rebase main
```

### Tip

> In case of fire: `git commit`, `git push`, leave building.  
> — Anonymous Developer