Git Fundamentals: Repositories, Commits, Branches, and Remotes

What is Git?

First, it's important to distinguish between Git and GitHub.

• Git is a version control system (VCS). It's a tool that runs on your local computer to track changes in your code.
• GitHub is a web-based hosting service for Git repositories. It's a platform where you can store your projects and collaborate with others.

Think of it this way: Git is the tool you use to write and save different versions of a novel on your computer. GitHub is the cloud-based library where you can publish your novel, share it with editors, and work on it with co-authors.

To get a clear picture of this distinction and the power of version control, let's start with a short video.

As the video explained, Git allows you to save "snapshots" of your project over time, so you never lose previous work and can always go back. This is fundamental to managing complex projects, especially in a collaborative environment like open source.

The Git Workflow: Where Your Code Lives

To work effectively with Git, you need a mental model of where your code resides at different stages. There are four key areas.

Let's break down these four areas:

1. Working Directory: This is your project folder on your computer. It contains the actual files you are currently editing.
2. Staging Area (or Index): This is an intermediate area. When you're happy with a set of changes, you add them to the staging area. Think of it as a draft of your next saved version. It lets you group related changes into a single snapshot, even if you made them at different times.
3. Local Repository: This is Git's database, stored in a hidden .git folder within your project directory. When you "commit," Git takes the files from the staging area and stores a permanent snapshot of them in your local repository.
4. Remote Repository: This is a version of your repository hosted on a server, typically on a platform like GitHub. It's the central point for you and other developers to share changes.

This flow is the heartbeat of Git. You make changes in your working directory, stage the changes you want to save, commit them to your local repository, and then push them to a remote repository to share them.

The following diagram illustrates this entire process.

Repositories and Commits: The Building Blocks

Now that you have the basic workflow, let's formalize the first two core concepts: repository and commit.

To summarize and build on that reading:

• A Repository (or "repo") is the entire collection of your project's files and its full history. This history is stored in the .git directory.
• A Commit is a snapshot of your staged changes at a specific point in time. Each commit has a unique ID (a SHA-1 hash) and contains metadata like the author, timestamp, and a message describing the changes.

Given your CS background, it's interesting to note that commits form a directed acyclic graph (DAG), but for a simple linear history, you can think of it as a linked list. Each commit points to its "parent" commit, creating a chain of history that Git can trace back to the very beginning of the project. This data structure is what makes Git so powerful and efficient.

Remotes: Collaborating with Others

So far, we've focused on your local machine. But open source is all about collaboration. This is where the concept of a remote comes in.

A remote is a shared repository that all team members use to exchange their changes. When you start working on an open-source project, you'll typically first clone it. This command creates a local copy of the remote repository on your machine.

Once you have made and committed your changes locally, you push them to the remote repository to share them. If other people have made changes, you pull their changes from the remote repository into your local copy to stay up-to-date.

Branches: Managing Parallel Universes

The final core concept is perhaps Git's most powerful feature: branching.

Imagine you're writing a story and you have an idea for a new plot twist, but you're not sure if it will work. You wouldn't want to overwrite your main manuscript. Instead, you'd save a copy and explore the new idea there. In Git, this "copy" is a branch.

A branch is an independent line of development. It allows you to work on a new feature or a bug fix in isolation without affecting the main codebase (which is often on a branch named main or master).

This is crucial in open source. You will never push your changes directly to the main branch of a project. Instead, you will:

1. Create a new branch for your task.
2. Make all your commits on that branch.
3. When you're ready, you'll push your branch to the remote and open a "Pull Request" (we'll cover this later), asking the project maintainers to merge your branch into their main branch.

The key takeaways are:

• A branch in Git is just a lightweight, movable pointer to a specific commit.
• Creating a branch is extremely fast and cheap because Git doesn't copy all the files; it just creates a new 41-byte pointer file.
• Git uses a special pointer called HEAD to know which branch you are currently working on. When you make a new commit, the branch that HEAD points to moves forward to the new commit.

This lightweight branching model encourages developers to use branches for everything, from tiny fixes to large features, which keeps the main codebase stable and organized.

Conclusion

Congratulations on completing your first lesson! We've covered the conceptual bedrock of Git. Let's quickly recap the key takeaways:

• Repository: The database of your project, containing all files and their history of changes. It exists both locally on your machine and often as a remote on a server like GitHub for collaboration.
• Commit: A snapshot of your project at a single point in time. Commits are the basic units of your project's history.
• Branch: An independent line of development, allowing you to work on features or fixes in isolation. It's simply a pointer to a commit.
• Core Workflow: The process generally involves modifying files in your working directory, adding them to the staging area, saving them with a commit to your local repository, and then sharing them via a remote repository.

You now have the mental model needed to understand the practical Git commands that we'll explore in the upcoming lessons.

Preview of the next lesson: In our next session, we'll move from theory to practice. You will learn how to configure Git with your personal identity (username and email), which is the first practical step you need to take before you can create your own commits.