Git Branching and Commit History: The Mental Model That Makes Collaboration Easier

Git becomes much easier when you treat commits as immutable snapshots in a graph and branches as names that move as new commits are created. A useful engineering habit is to state the mechanism first and the tool second; tools change, but the problem usually stays recognizably similar.

The core idea

A Git repository is a content-addressed history of commits. Each commit points to earlier commits, and a branch is a movable reference to one commit. Commands change references or create new commits; they do not rewrite time unless you explicitly choose an operation that creates replacement history.

How it works

A normal commit records the project state and points to a parent commit. Creating another commit moves the current branch reference forward while the earlier commit remains part of the history.

Merging combines histories by creating a commit with multiple parents when necessary. Rebasing instead creates new commits whose parent relationships are rewritten on top of another base. The end result can look linear, but the old commits remain different objects until unreachable history is pruned.

The safest collaboration habit is to know which branch you are changing and whether your command creates new commits, moves a reference, or rewrites existing published history.

A concrete example

If a feature branch starts from main and both branches receive commits, Git can see two lines in the graph. A merge preserves that branching history. A rebase copies the feature work onto the newer main and changes the commit identities. Neither operation 'moves the same commits' in the strict sense.

Common mistakes

• Treating branches like folders rather than references.
• Running force-push operations without checking whether other people depend on the published history.
• Memorizing commands without knowing whether they preserve or rewrite commit ancestry.

A student project that makes it stick

Apply the concept to a project you already have. Keep the scope narrow, document assumptions, and make the result reproducible by another student on another machine. This is where a conceptual idea becomes an engineering artifact.

Where it connects

The surrounding systems—version control, containers, CI, networking, databases, security, and observability—share the same engineering pattern: define desired behavior, make state visible, automate repeatable work, and leave enough evidence to debug failures.

What to remember

1. Learn the abstraction before the command sequence.
2. Prefer reproducible workflows over tribal knowledge.
3. Make important state and dependencies visible.
4. Treat operational behavior as part of the software design.
5. Keep the system smaller than your ability to explain it.

Limitations

Tooling and deployment details vary by operating system, provider, project age, and team conventions. The primary documentation linked below is the appropriate reference when a real deployment depends on version-specific behavior.

Related Observatory reads

• open source contribution with pull requests
• code review as a risk reduction system
• secure dependencies and software supply chain

Primary sources

• Git Documentation — Git User Manual
• Pro Git Book