bongoDev

Git becomes much easier when you stop thinking of it as a cloud folder and start thinking of it as a local database of immutable snapshots connected by history.

A normal Git repository gives you three important things at once:

the files you are editing now,
a local history database in .git,
named pointers such as branches and tags that make history usable.

Because Git is distributed, a clone normally contains enough history to inspect commits, create branches, compare versions and make new commits without talking to GitHub. Git is the version-control system. GitHub is a collaboration and hosting platform built around Git repositories.

The snapshot model

A commit points to a project snapshot plus metadata such as author, committer, message and parent commit(s).

Text

A --- B --- C --- D
              ^
             main

main is not a folder. It is a movable reference that points to a commit. When you commit again, the branch reference moves forward.

Content-addressed history

Git objects are identified by content-derived object IDs. That gives Git a strong integrity model: changing a commit's content changes its identity and therefore the identities of descendants that refer to it.

You do not need to memorize Git internals on day one, but this explains why rewriting old history creates new commit IDs instead of editing an old commit in place.

Local-first workflow

A useful daily loop is:

Text

inspect → edit → stage → review → commit → share

Commands:

Bash

git status
git diff
git add <path>
git diff --staged
git commit -m "Explain the change"
git push

The important engineering habit is the review step before commit and push. Git gives you multiple checkpoints where you can verify exactly what is changing.

Git and GitHub responsibilities

Concern	Git	GitHub
Local history	Yes	Hosts copies
Branching/merging	Yes	Adds PR workflow/UI
Commits/tags	Yes	Displays and governs them
Authentication	Transport-dependent	SSH/HTTPS/account controls
Code review	Basic diff tools	Pull requests/reviews/CODEOWNERS
Governance	Hooks/config	Rulesets/branch protection
Issues/projects	No	Yes

The safest Git mindset

Before running a destructive-looking command, ask:

Does this change only my working files?
Does this change the staging area/index?
Does this move a branch/reference?
Does this create new history?
Has the history already been shared with other people?

The last question matters most. Rewriting your own unpublished branch is very different from rewriting a shared branch used by a team.