Imagine you're writing a long research paper. You save your first draft as paper_v1.docx. After some edits, you save it again as paper_v2.docx. A week later, you have paper_final.docx, then paper_really_final_this_time.docx.

This system is messy and confusing. It's hard to remember what changed between versions or to go back to an older idea you deleted. Version control systems (VCS) solve this problem. They are tools that track changes to files over time, creating a clear history of a project. You can review specific changes, revert to previous versions, and see who changed what.

Git is the most popular version control system in the world. It's a distributed version control system, which means that every developer working on a project has a full copy of its history on their own computer. This makes it fast and allows people to work offline.

A project managed by Git is called a repository, or "repo" for short. To get started, you first need a folder for your project. Once you've created one, you can tell Git to start tracking it.

Open your terminal or command prompt, navigate into your project folder, and run this command:

This command initializes an empty Git repository. It creates a hidden subfolder named .git where Git stores all the history and tracking information for your project. You almost never need to touch the files in this folder directly.

Git doesn't automatically save every change you make. Instead, you tell it precisely which changes you want to save in a snapshot. This involves a three-step process that moves files between different states or areas.

1. Working Directory: This is your project folder where you create, edit, and delete files.
2. Staging Area: This is an intermediate area where you gather the changes you want to include in your next snapshot. Think of it like a shopping cart; you add items you want to buy before heading to checkout.
3. Repository: This is where Git permanently stores your snapshots, called "commits."

This flow gives you fine-grained control over your project's history.

Let's see this in action. First, create a new file in your project folder. Now, let's ask Git for a status update.

Git will tell you there's an "untracked file." This means the file exists in your working directory, but Git isn't tracking it yet. To start tracking it, you need to add it to the staging area.

This command tells Git you want to include the changes in README.md in your next commit. If you run git status again, you'll see the file is now listed under "Changes to be committed."

Now, you can create the snapshot, or commit. Each commit must have a message describing the changes you made. This is crucial for understanding the project history later.

You've just made your first commit! The file's changes are now safely stored in the repository's history. If you run git status one more time, Git will report that your working directory is clean, meaning there are no new changes since your last commit.

A branch in Git is like a parallel timeline for your project. It allows you to work on a new feature or experiment with an idea without affecting the main, stable version of your code. By default, your first branch is named main or master.

You can create a new branch to work on something new. Once you're happy with the changes in that branch, you can merge them back into your main branch, integrating the new feature into the main project.

To create a new branch and switch to it, you can use the checkout command:

Now, any commits you make will be on the new-feature branch. When you're ready to combine your work, you'll switch back to the main branch and merge new-feature into it. This process keeps your main line of development clean and organized.

Ready to test your knowledge?