Fundamentals 17 min read

Master Git: From Core Concepts to Advanced Branching and Merging

This comprehensive guide explains Git’s fundamental concepts, file states, commit nodes, HEAD, remote repositories, and detailed command usage—including adding, committing, branching, merging, rebasing, cherry‑picking, and reverting—while illustrating each operation with clear examples and diagrams.

Liangxu Linux
Liangxu Linux
Liangxu Linux
Master Git: From Core Concepts to Advanced Branching and Merging

Basic Concepts

Advantages of Git

Git is a distributed version‑control system. Commits are created locally, each identified by a unique SHA‑1 hash, and the full history is stored on every developer’s machine. This makes commits cheap, enables offline work, and simplifies rollback.

Centralized : every commit must contact a central server (e.g., SVN). Distributed : commits are local, automatically backed up, and each clone contains the complete repository.

File States

Modified : files changed in the working directory.

Staged : files added to the index with git add.

Committed : files permanently recorded in the repository.

Commit Nodes

Each commit creates a node identified by a SHA‑1 hash. Nodes form a chain (ignoring merges) where each node stores its hash, parent hash(es), and a snapshot of the project.

Commit chain diagram
Commit chain diagram

HEAD

HEAD is a pointer to the current commit or to a branch. When HEAD points directly to a commit the repository is in a “detached HEAD” state; when it points to a branch it follows the branch’s tip.

Remote Repository

Collaboration uses a remote repository. git clone copies the repository and all references. Remote references are not updated automatically; git fetch must be run to synchronize them.

Always push only code that has passed tests to avoid contaminating the shared history.

Branches

What Is a Branch?

A branch is a lightweight movable pointer to a commit. Multiple branches can coexist, each representing an independent line of development (features, bug‑fixes, releases). Branches do not duplicate file contents; they only store a reference, keeping storage overhead minimal.

Example: after releasing v1.0 , create a hot‑fix branch ft‑1.0 from the v1.0 commit while development of v1.1 continues on master . Merge ft‑1.0 back into master when the fix is complete.

Command Details

Commit‑Related Commands

Add a specific file to the index: git add <file‑path> Add all changes: git add . Discard changes in the working directory: git checkout -- <file‑name> Unstage a file: git reset HEAD <file‑name> Create a commit with a message:

git commit -m "commit description"

Branch‑Related Commands

Create a new branch: git branch <branch‑name> Switch to an existing branch: git checkout <branch‑name> Create and switch in one step: git checkout -b <branch‑name> Delete a branch after it has been merged:

git branch -d <branch‑name>

Merge‑Related Commands

Merge another branch or commit into the current branch: git merge <branch‑name|commit‑hash> Fast‑forward merges occur when the current branch is an ancestor of the target; otherwise a new merge commit is created.

If the same line of code was modified in both branches, a conflict must be resolved manually.

Rebase rewrites history by moving a series of commits onto a new base: git rebase <branch‑name|commit‑hash> Rebase produces a linear history but may require repeated conflict resolution.

Cherry‑pick copies selected commits onto the current branch:

git cherry-pick <commit‑hash>

Revert‑Related Commands

Detach HEAD to point directly at a commit (useful for inspection or amendment):

git checkout <commit‑hash>
# or
git checkout --detach

Relative references simplify moving HEAD:

# Move to the previous commit on a branch
git checkout <branch‑name>/HEAD^
# Move back N commits
git checkout <branch‑name>~N

Amend the most recent commit after fixing issues: git commit --amend Reset the current branch and HEAD to an earlier state (discard later commits):

git reset HEAD~N

Remote‑Related Commands

Clone a repository: git clone <repository‑url> Fetch updates from the remote without merging: git fetch <remote‑url>/<branch> Pull (fetch + merge) the latest changes: git pull <remote‑branch> Pull with rebase instead of merge: git pull --rebase <remote‑branch> Push local commits to the remote: git push <remote‑branch> If the push is rejected due to conflicts, pull first, resolve the conflicts, then push again.

Key Takeaways

HEAD and branches are merely references; together with commit nodes they form Git’s distributed model.

Merge preserves the chronological order of commits, while rebase creates a cleaner linear history. Choose based on workflow needs.

Detaching HEAD allows inspection of any commit without creating new nodes.

Cloning or fetching stores the full remote history locally.

Pull is essentially fetch followed by merge (or rebase with --rebase).

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

GitVersion ControlbranchingMerging
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.