Overview
You modify several files.
Something stops working.
And that slightly unpleasant question comes up:
what has changed since everything was still fine?
Git exists precisely so that this question has an answer.
A regular folder shows the current state of a project.
Git adds its history.
Each important step can be recorded in a commit.
Commits gradually form a series of states that can be compared, browsed, shared, or used to retrieve an earlier version.
Git turns a set of files into a navigable history.
This idea becomes even more powerful with branches.
The project can explore several directions without immediately overwriting its main line.
A feature, a fix, or an experiment can live separately until the moment we decide to merge them together.
Git is also distributed.
When you clone a repository, you don't just recover the visible files.
A large part of the history also exists locally.
Commits, branches, comparison, and creation of new versions can therefore continue without a permanent connection to a central server.
The remote repository becomes mainly a point of exchange.
This property explains the difference with GitHub.
Git knows how to version.
GitHub, GitLab, Codeberg, or another forge can host and organize collaboration around the repository.
Git can work with them, with a personal server, or simply locally.
Originally created for the development of the Linux kernel, Git remains free and open source.
Its power comes with a sometimes confusing mental model.
Working tree, staging, commits, branches, remotes, and history rewriting don't always match the intuitions built with a simple file system.
But you don't need to know all of Git's commands to understand what makes it valuable.
Its fundamental logic fits in a few verbs:
record → compare → isolate → merge → share.
Features
Commits: building the project's memory
The commit records an identifiable state along with a message.
It then makes it possible to find out when a modification appeared, which files changed, or what the project used to look like.
A good history therefore doesn't just preserve files.
It preserves part of the development reasoning.
This difference becomes especially visible several months later.
A clear commit can explain why a strange condition still exists in the code or why an architecture was changed.
Version control then becomes a form of technical memory.
Staging: choosing what belongs to the next commit
Git places a step between the modified files and the commit.
This staging area makes it possible to select the changes that should be recorded together.
The feature sometimes seems useless at first.
It becomes valuable when several tasks have been mixed during the same session.
A bug fix, a piece of documentation, and an experiment don't necessarily need to become the same commit.
Staging allows reconstructing more coherent units.
It turns a messy session into a more readable history.
Branches: exploring multiple futures
A branch allows pursuing a separate line of work.
A feature, a fix, or an experiment can evolve without immediately disrupting the main branch.
This lightness encourages experimentation.
An architecture can be tested and then abandoned without destroying the stable state of the project.
Branches therefore make possible a rather important idea:
the project can have multiple futures before choosing one.
Merge and rebase
When several branches diverge, their changes sometimes need to be brought together.
The merge explicitly preserves the encounter between several lines of work.
The rebase can reposition a series of commits on a new base to obtain a more linear history.
Neither approach is universally superior.
The important thing is to understand that Git can represent or reshape history.
This power requires more caution when a commit has already been shared.
Rewriting a personal branch is one thing.
Rewriting the history used by several collaborators is another.
Remotes: exchanging between multiple repositories
Remotes allow exchanging commits with other repositories.
This mechanism doesn't impose any particular platform.
GitHub, GitLab, Codeberg, Gitea, or a simple SSH server can all play this role.
The remote is therefore not "the real repository."
It constitutes another copy with which the project can communicate.
This architecture explains why Git continues to work offline and why several servers can coexist around the same project.
Exploring and understanding history
Git makes it possible to compare versions, browse commits, and find the origin of a modification.
Diff, log, show, or blame answer different questions:
- what changed?
- when?
- in which commit?
- why does this line exist?
The real interest is not to find a culprit.
It is to recover the intention behind a change that has outlasted its own explanation.
More specialized tools like bisect can also help identify the moment when a regression appeared.
Putting work aside temporarily
Mechanisms like stash or worktree respond to a very ordinary reality: development doesn't always follow the planned order.
A task can be interrupted by an urgent fix.
A project may need several branches open simultaneously.
These tools aren't necessary to understand Git.
They mainly show that the system was designed to manipulate multiple work states without having to manually copy folders.
Tags, hooks, and workflow extensions
Tags are notably used to identify important commits or versions.
Hooks make it possible to trigger scripts at different stages.
Git can also be integrated with CI tools, IDEs, agents, and many automations.
These features extend its role.
They don't change its fundamental identity:
Git preserves and circulates the project's history.
Use Cases
Experimenting without fear
A branch allows attempting a major overhaul while keeping a stable path to the previous state.
Finding the origin of a bug
The history helps identify when a behavior appeared and which modifications accompanied it.
Working cleanly alone
Git remains useful even without a team.
It gives the project a memory and avoids the multiplication of folders named final, final2, and final_really.
Collaborating
Several people can work on different branches, then exchange and merge their modifications.
Versioning documentation or configuration
Git isn't reserved for code.
Any set of textual files whose evolution needs to be followed can benefit from its history.
Preparing releases
Tags and history make it possible to clearly identify the states corresponding to distributed versions.
Working on several branches simultaneously
Worktrees can isolate multiple workspaces without duplicating the entire repository.
PANACHES Review
Its true strength isn't GitHub
Git is often discovered through GitHub.
Its most important idea remains independent of any platform.
This independence gives the project a memory that can change servers without changing versioning system.
In a world full of cloud services and subscriptions, this separation remains extremely valuable.
Git transforms experimentation
The ability to return to a known state reduces the psychological cost of a major modification.
You can try more because the past is no longer destroyed at each save.
Git thus becomes a safety net for technical creation.
It doesn't decide the workflow
Git provides commits, branches, and merging mechanisms.
It doesn't impose a single way to use them.
A team can prefer long branches, short branches, trunk-based development, or other conventions.
The technique stays the same.
The organization belongs to the project.
The learning curve comes mainly from the mental model
Git distinguishes what is in the working directory, what is prepared for the next commit, what already belongs to local history, and what exists on a remote.
These states explain much of the messages that seem mysterious at first.
The difficulties therefore don't only come from the commands.
They come from the fact that Git has several layers of reality at the same time.
Once commits, staging, branches, and remotes are understood, many operations stop seeming arbitrary.
The command line isn't a religion.
Graphical interfaces make branches, diffs, and commits much more visible.
They can be better for certain tasks.
Understanding a few fundamental concepts remains useful nonetheless when something goes outside the expected workflow.
The goal isn't to memorize two hundred commands.
It is to know what the tool is actually modifying.
Text remains its natural territory
Git is extremely effective at comparing textual files.
Large binary files, heavy media, or 3D assets require more strategy.
Git LFS can help in some cases.
Specialized systems may be more suitable for very heavy artistic productions.
Points of Attention
- Git isn't a complete backup on its own: a single local repository can disappear with its disk.
- Untracked files are not part of the history.
- Secrets must never be committed, even in a private repository.
- Rewriting shared history can disrupt other collaborators.
- Conflicts aren't Git errors: they signal that a human decision is needed.
- Large binary files are poorly suited to classic Git storage.
- Git LFS adds its own infrastructure and must be thought through from the start for large assets.
- Branch and commit conventions must remain proportionate to the project.
- A useful history also depends on understandable commit messages.
- Graphical interfaces make Git easier without removing the value of understanding its concepts.
- Git is open source, but that doesn't determine the license of projects versioned with it.