How Git Work: 02 - Branches Demystified

A Git branch is a pointer to a specific commit in the project's history.

The default branch created by Git when you initialize a new repository. It's often named 'main' (formerly 'master').

A directory in the .git folder that holds references (pointers) to commits, including branch references.

A subdirectory within the 'refs' directory that contains references to branch heads (latest commits on a branch).

A simple file, usually small, that stores a single commit hash, representing the current commit on a specific branch.

It functions as a pointer to the latest commit on a particular branch.

There's no special status assigned to the 'main' branch in Git. It's just a regular branch, although it's conventionally recognized as the main development line.

Branches in Git are lightweight and simply represent pointers to commits. The 'main' branch, while often used as the primary development line, is treated the same as other branches in terms of its technical implementation.

A branch is a pointer to a specific commit in the project's history. It allows you to work on different versions of your code simultaneously.

The 'HEAD' file in the .git folder points to the current branch, indicating which branch is actively being used.

Creating a new branch involves copying the current branch's state and creating a new pointer to that commit.

The 'git branch' command creates a new branch. It does not switch to the new branch.

The 'git switch' (or 'git checkout') command moves the HEAD pointer to the specified branch, making it the current branch.

Committing changes on a branch only affects that branch, not the main branch or other branches. Each branch has its own history.

The 'git merge' command combines changes from one branch into another. This brings changes from the source branch to the target branch.

The 'git checkout' command has multiple uses, including switching branches, but also creating new branches, restoring files, and more.

A 'merge conflict' occurs when multiple branches have changes to the same part of a file. Git cannot automatically decide which changes should prevail, requiring manual resolution.

When a branch is merged into the main branch, the changes from the branch are incorporated into the main branch, forming a single history.

The 'git pull' command fetches changes from a remote repository and merges them into the local branch.

The 'git push' command sends local branch changes to a remote repository, making them available to others.

Remote branches are branches that exist on a remote repository. They are used to collaborate with other developers on the same project.

A local branch is a branch that exists only on your personal computer. These are the branches you work on and commit changes to.

A "HEAD" pointer indicates the current commit in the repository. When you switch branches, you essentially move the "HEAD" pointer.

Merge commits are special commits that have two or more parent commits. They represent the merging of branches and incorporate changes from multiple branches.

Merging branches combines the changes from one branch into another. It's a process for integrating work from different branches.

Git resolves merge conflicts by creating a temporary file that shows the conflicting changes from both branches. This allows the user to manually edit the file and choose which changes to keep.

Blobs are raw data stored by Git, such as a file's content. Trees are directories that contain references to other trees or blobs.

Git uses trees and blobs to create a snapshot of the project's state for each commit. These snapshots can be retrieved to view past versions of files.

Git uses references to connect objects in the database, such as commits to their parents or trees to their blobs. These references help maintain the history and structure of your project.

Git doesn't care about the history of commits when it only cares about the content. It only looks at the tree and blob representations for a specific commit, effectively restoring a snapshot of the project.

Git reuses existing objects, such as blobs and trees, if they are already present in the repository, minimizing storage space. It only creates new objects when necessary.

Git focuses on the history of commits and how they connect to each other, allowing users to track changes, roll back to previous versions, and understand the project's evolution.

Git stores each commit as a snapshot of the entire project, including all files and directories. This allows you to easily jump back to any point in the history.

Git primarily focuses on the history of commits, providing a powerful way to track modifications, explore the evolution of code, and navigate between versions.

Git doesn't rely on your working area. It uses the commit history to reconstruct a project's state, enabling efficient checkout operations.

The working directory is the current state of the project on your local machine, while the Git database stores all the project's history. Git uses references to connect these two realms.

Git prioritizes the object database (containing commits, trees, and blobs) for storing project history. Your working directory, while used for active changes, is less important to Git.

Commits in Git are immutable, meaning they cannot be changed after creation. They exist within the object database.

The working directory contains the most recent files of your project as they exist on your computer. Git doesn't care as much about this area.

Git gives you a warning before overwriting files in your working directory to protect your changes. It's a safety feature before switching branches.

The .git directory contains the entire Git repository, including the object database with commits, trees, and blobs. It's the core of your project in Git.

A fast-forward merge happens when Git can simply move the branch pointer to the latest commit on another branch. It avoids creating unnecessary new commits because all the changes are already contained within the target branch.

In a fast-forward merge, Git doesn't create a new commit because the target branch is already a descendant of the source branch. It just moves the pointer.

A detached HEAD happens when you directly check out (checkout, not switch) a specific commit without being on a branch. This allows you to experiment without affecting your main branches.

You can check out a commit directly using its hash. This is different from switching to a branch. It places you in a detached HEAD state.

Commits that are reachable from a branch (or tag) are considered part of your project's history. However, commits that only have direct hashes and are not connected to any branch are considered unreachable.

Unreachable commits are at risk of being garbage collected by Git because they are no longer accessible from any branch or tag. Essentially, they are no longer useful and are removed to free up space.

A commit is usually reachable from a branch, meaning you can find it by starting from a branch and following its history. However, a detached HEAD can create a situation where commits are only reachable directly by their hashes unless you create branches.

If you abandon your experiment and switch back to the main branch, the detached HEAD commits made during the experiment become unreachable. This can happen when you create commits without being on a branch.

A commit, blob, or tree in Git is considered 'dead' when it cannot be accessed from any branch, HEAD, or tag.

Git's garbage collector automatically removes 'dead' objects to save disk space. It identifies objects that are no longer needed based on how they are referenced.

A reference in Git points to a specific commit. This allows you to easily navigate to particular points in the project's history.

Branches in Git are references that track the latest commits. This allows you to create and manage multiple development lines.

When a commit is created, the current branch moves to point to this new commit. This maintains a linear history on the branch.

Git automatically updates the working directory to match the content of the commit that HEAD points to. This enables switching between different versions of your project seamlessly.

The HEAD moves to the new commit when you create a commit in a detached HEAD state.

A tag is a reference that permanently points to a commit. This allows you to mark specific points in your Git history, preventing accidental deletion of important revisions.

A blob in Git stores the content of a file. This is the basic unit of data that comprises your entire Git repository.