Pro Git

1. Git is a distributed, snapshot-based version control system.

Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem.

Snapshot-based approach. Unlike older systems that track changes as deltas, Git records the state of your entire project at each commit. When you save the state of your project, Git takes a picture of all your files at that moment and stores a reference to that snapshot. This fundamental difference makes Git incredibly fast and efficient, especially for operations like branching and comparing versions.

Distributed nature. In Git, clients don't just check out the latest version; they mirror the entire repository history. This means every clone is a full backup, and most operations are local, requiring no network connection. This distributed model offers significant advantages:

• Offline work is seamless.
• Operations like browsing history or comparing versions are nearly instantaneous.
• Recovery from server failure is easier, as any clone can restore the data.

Designed for speed and scale. Git was created by Linus Torvalds for managing the Linux kernel, a massive, fast-moving project. Its design prioritizes speed, simple design, strong support for non-linear development (branching), and efficient handling of large projects. This makes it suitable for projects of any size, from small personal scripts to large enterprise applications.

2. Master the three fundamental states: Modified, Staged, and Committed.

Git has three main states that your files can reside in: modified, staged, and committed.

The core workflow. Understanding Git revolves around the lifecycle of your files through three states: Modified (changes made but not yet saved to Git), Staged (marked changes to be included in the next commit), and Committed (changes safely stored in the local database). This corresponds to three sections of a Git project: the working tree (your files), the staging area (the index), and the Git directory (the database).

Staging area's power. The staging area is a unique and powerful feature. It allows you to selectively choose which changes from your working directory will be part of your next commit. You can stage parts of files or changes across multiple files, crafting precise, logical commits. This granular control helps maintain a clean and understandable project history.

Basic workflow cycle:

• Modify files in the working tree.
• Stage desired changes using git add.
• Commit staged changes using git commit.
• Repeat.

Files can be tracked (Git knows about them) or untracked (new files Git doesn't yet track). git status is your primary tool to see which files are in which state.

3. Git's lightweight branching is a core strength, enabling flexible workflows.

A branch in Git is simply a lightweight movable pointer to one of these commits.

Branches are just pointers. Unlike other VCSs where branching can involve copying files, Git branches are incredibly cheap. Creating a branch simply creates a new pointer to an existing commit. Switching branches (git checkout or git switch) is fast because Git only needs to update the HEAD pointer and efficiently change files in your working directory to match the target commit's snapshot.

Encourages frequent branching. Because branching is so fast and easy, Git encourages workflows where developers create branches for every new feature or bug fix (topic branches). This isolates work, makes context switching simple, and keeps the main branch stable. Branches can be short-lived, merged quickly, and then deleted.

Branching benefits:

• Isolate new development from stable code.
• Experiment freely without affecting the main project.
• Facilitate code review via comparing branches.
• Simplify collaboration on specific features.

Git's branching model is often cited as its "killer feature" due to its speed and flexibility, fundamentally changing how developers can manage parallel lines of development.

4. Collaborate effectively by managing remote repositories and sharing changes.

To be able to collaborate on any Git project, you need to know how to manage your remote repositories.

Remotes are shared repositories. Remote repositories are versions of your project hosted elsewhere (internet, network). They serve as central points for collaboration. You can have multiple remotes, each with its own set of branches and tags. Cloning a repository automatically sets up a default remote named origin.

Fetching and pulling. To get data from a remote, use git fetch <remote>. This downloads data and updates remote-tracking branches (like origin/master) but doesn't modify your local work. git pull is a shortcut that typically runs git fetch followed by git merge (or git rebase if configured), integrating remote changes into your current branch.

Pushing changes. To share your local commits, use git push <remote> <branch>. This uploads your branch and its commits to the specified remote. You need write access to the remote repository for this to succeed. If others have pushed changes since your last pull, your push may be rejected, requiring you to pull and integrate their work first.

5. Integrate work using merging or rebasing, understanding their implications.

In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase.

Merging preserves history. git merge integrates changes from one branch into another by creating a new "merge commit". This commit has multiple parents, explicitly showing where divergent lines of development were joined. Merging is generally non-destructive to history and is the default integration method. Conflicts are marked in files for manual resolution.

Rebasing rewrites history. git rebase integrates changes by moving your commits to the tip of another branch. It reapplies your commits one by one on top of the target branch, creating new commit objects with different SHA-1 hashes. This results in a cleaner, linear history, making it look like work happened sequentially.

Key differences:

• Merge: Creates a new commit, preserves original history structure.
• Rebase: Rewrites commits, creates a linear history.

Caution with rebasing. Never rebase commits that have already been pushed to a shared repository and that others may have based their work on. Rewriting shared history can cause significant problems for collaborators, requiring them to re-integrate changes and potentially leading to duplicated commits.

6. Utilize powerful tools to inspect, search, and rewrite your project's history.

Many times, when working with Git, you may want to revise your local commit history.

Inspecting history. git log is the primary tool for viewing commit history, with numerous options for formatting (--pretty), filtering (--author, --grep, -S), and visualizing branches (--graph). git show displays details of a specific commit or object. git diff compares changes between commits, the staging area, and the working directory.

Searching content. git grep allows searching for strings or patterns within any version of your project's files. git log -S (the "pickaxe" option) finds commits that introduced or removed a specific string. git log -L shows the history of a specific function or line of code.

Rewriting history. Git provides tools to modify past commits before sharing them. git commit --amend changes the last commit. git rebase -i (interactive rebase) allows reordering, editing, squashing, or dropping commits in a series. git filter-branch (or the newer git-filter-repo) can rewrite large parts of history scriptably, useful for tasks like removing a file from all commits. Use caution with rewriting shared history.

7. Customize Git's behavior with configuration settings and automated hooks.

Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur.

Configuration levels. Git settings can be applied at three levels: system (--system), user (--global), and repository (--local). These settings control everything from your name/email (user.name, user.email) and preferred editor (core.editor) to whitespace handling (core.autocrlf, core.whitespace) and external tools (merge.tool, diff.external).

Git attributes. .gitattributes files allow path-specific settings. You can tell Git how to handle line endings (text), identify binary files (binary), use custom diff filters (diff), or even prevent files from being archived (export-ignore). These settings apply only to the specified files or directories.

Hooks automate actions. Git hooks are custom scripts triggered by specific events. Client-side hooks run on local operations (committing, merging, rebasing), useful for enforcing commit message formats or running tests before committing. Server-side hooks run on network operations (receiving pushes), ideal for enforcing project policies like access control or triggering continuous integration builds. Hooks are powerful but must be distributed manually for client-side use.

8. Git's object database is a content-addressable filesystem storing blobs, trees, and commits.

Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.

Core data structure. At its heart, Git is a simple key-value store where content is addressed by its SHA-1 hash. There are four main object types:

• Blob: Stores file content.
• Tree: Represents a directory snapshot, containing pointers to blobs and other trees, along with filenames and modes.
• Commit: Points to a top-level tree, its parent commit(s), author/committer info, and a message.
• Tag: Points to a commit (usually), with tagger info and a message (annotated tags).

Content-addressing. When you add content, Git calculates its SHA-1 hash and uses that as the key to store the object. This ensures data integrity; any change to the content would result in a different hash. Objects are initially stored as compressed "loose" files in .git/objects.

Object graph. Commits form a directed acyclic graph (DAG) through parent pointers, representing the project's history. Trees and blobs form the snapshots referenced by commits. Understanding this underlying structure helps demystify many Git operations and allows for low-level manipulation using "plumbing" commands like git cat-file and git hash-object.

9. References (refs) provide human-readable pointers to specific commits.

In Git, these simple names are called “references” or “refs”; you can find the files that contain those SHA-1 values in the .git/refs directory.

Naming commits. Remembering 40-character SHA-1 hashes is impractical. References provide user-friendly names for specific commits. These are simple files in the .git/refs directory containing a commit's SHA-1. Common types include branches (refs/heads/), tags (refs/tags/), and remote-tracking branches (refs/remotes/).

HEAD pointer. The HEAD file is a special reference, usually a symbolic pointer (ref:) to the branch you're currently working on. When you commit, Git creates a new commit object whose parent is the commit HEAD points to, and then updates the reference HEAD points to to the new commit. In a "detached HEAD" state (checking out a tag or specific commit), HEAD directly contains a commit SHA-1.

Refspecs define mappings. Refspecs specify how local and remote references relate, particularly during fetch and push operations. They use the format [+]<src>:<dst>, mapping references from the source side (<src>) to the destination side (<dst>). This allows flexible control over which branches are fetched or pushed and where they are stored locally or remotely.

10. Data recovery is often possible even after seemingly destructive actions.

Assuming this happens, how can you get your commits back?

Git adds data. Nearly every operation in Git adds data to the database, making it difficult to permanently lose committed work. Even actions like hard resets or force-deleting branches don't immediately remove the underlying commit objects. They simply remove the references (pointers) that make those commits easily reachable.

Reflog saves history. Git maintains a "reflog" (.git/logs/) which records where your HEAD and branch pointers have been recently. This log is local to your repository and tracks changes over the last few months. You can use git reflog or git log -g to view this history and find the SHA-1 of a seemingly lost commit.

Finding dangling objects. If a commit is no longer reachable by any reference (including the reflog), it becomes a "dangling" object. git fsck --full can scan the object database and list these dangling objects, including commits. Once you find the SHA-1 of the lost commit, you can recover it by creating a new branch or tag pointing to it (git branch <new-branch> <sha-1>). Objects not reachable by any reference after a certain period are eventually removed by garbage collection (git gc).

Last updated: June 13, 2025