At 4:40 on a Friday afternoon, support reports that some customers are being charged the wrong delivery fee.
Engineering finds the cause quickly: a condition in the pricing logic was changed during a release earlier that week. The correction itself is only a few lines.
The difficult questions come next.
What exactly changed in the original release? Was the faulty condition part of a larger change? Has anyone modified the same code since then? Can the team isolate the correction, review it and undo it cleanly if the hotfix causes another problem?
Without reliable version history, answering those questions becomes a mixture of memory, old file copies and production archaeology.
With Git, the team can inspect the commit that introduced the behavior, compare the previous and current versions, create an isolated branch for the fix, review exactly what changed and preserve another known point in the application's history. If the change later proves harmful, Git also provides a controlled way to reverse its effect.
That is why Git is much more than a place to keep source code.
Git makes application maintenance safer by turning software changes into identifiable, traceable and reversible units of history.
The official Git documentation describes commits as snapshots linked to earlier commits, creating a history from which previous project states and individual changes can be examined.
For Levelworks, this maps directly to Version Controlled App Health. It also supports Explainable & Debuggable, Tested and Seamlessly Updatable, because maintaining software safely depends on knowing what changed, understanding why it changed and being able to move between application states deliberately.
Imagine maintaining an application using folders such as:
app-final
app-final-new
app-final-new-fixed
app-final-new-fixed-2
app-working-backup
You may have several historical copies, but you do not have useful change history.
Which files changed between app-final-new and app-final-new-fixed? Who made the change? Why? Was another unrelated change included at the same time?
Git replaces that ambiguity with commits.
A well-formed commit captures a particular state of the project and links it into the application's previous history. Git's log tooling can then show commits over time, while options such as -p, --stat, file filters and date or author filters help teams inspect what individual commits introduced.
During maintenance, this changes the investigation from:
“Does anyone remember why this code looks like this?”
to:
“Which change introduced this code, what else changed with it, and what reason was recorded?”
That difference becomes increasingly valuable as an application grows older and the people maintaining it are no longer the people who originally built every part.
Git cannot make maintenance changes small automatically.
Teams still have to structure their work well.
Suppose a developer fixes an invoice-calculation bug, updates twelve dependencies, reformats 80 files and changes a reporting screen in one commit.
Six days later, invoice totals are wrong again.
Git has preserved the change, but the maintenance history is unnecessarily difficult to interpret because unrelated work has been bundled together.
Compare that with three focused commits:
Fix tax calculation for refunded line items
Update reporting component
Upgrade payment SDK
Now the tax regression has a much smaller investigation surface.
The useful maintenance principle is:
A commit should represent a coherent change that another engineer can understand and evaluate independently.
This makes diffs easier to review, regressions easier to locate and reversals less destructive.
Commit messages matter for the same reason. “Fix stuff” records very little useful maintenance knowledge; “Prevent duplicate invoice creation when payment callback is retried” explains both the intended behavior and the context future maintainers are likely to need.
Git preserves history, but its value depends heavily on the quality of the history your team creates.
Maintenance frequently involves several kinds of work happening simultaneously.
One engineer may be fixing a production defect while another upgrades a library and a third works on a feature.
Editing all of those changes directly on the same main line creates unnecessary risk.
Git branches allow development to diverge temporarily from the main history so changes can be worked on separately and merged when ready. The Git documentation describes branches as lightweight pointers to commits and specifically emphasizes that branches let developers work away from the main line without disturbing it.
For maintenance, that means a bug fix can have its own short-lived branch:
main
├── fix/payment-timeout
├── update/database-driver
└── fix/mobile-login
The payment change can be tested without including the unfinished database-driver update.
Once the fix is ready, it can be integrated into the main branch deliberately.
This separation does not guarantee correctness, but it gives teams a safer workspace in which each maintenance change can be understood before it alters the version intended for release.
Git itself records branches and commits. Repository platforms built around Git—such as GitHub, GitLab and others—commonly add pull-request or merge-request workflows on top of that history.
The distinction matters: Git provides the version-control foundation; the hosting platform typically provides review gates and repository policy.
That combination is particularly valuable in maintenance.
Instead of another developer reviewing an entire file and trying to spot what changed, they can review the exact diff produced by the maintenance branch.
A reviewer can ask:
Does the fix address the intended failure?
Did it change anything unrelated?
Is an edge case missing?
Should a regression test accompany it?
On GitHub, protected-branch rules can require pull-request reviews and passing status checks before changes are merged into important branches. They can also restrict direct pushes or require other repository conditions.
Those protections are not inherent features of Git, but Git's change history makes them possible.
For a business-critical application, allowing every maintainer to push directly to the production branch removes an important opportunity to catch mistakes before they become operational incidents.
A maintenance change can pass review and testing and still behave unexpectedly in production.
Perhaps the environment contains data that was not represented in testing, or the change interacts with another component in an unexpected way.
At that point, the team may need to reverse it.
Git's revert command creates a new commit that reverses the changes introduced by an earlier commit, rather than simply erasing the previous history.
Conceptually:
A → B → C → D
↑
bad change
A → B → C → D → E
↑
revert D
The problematic change remains visible in history, as does the decision to reverse it.
That is preferable to manually opening several files and trying to remember how they looked before the release.
There is an important limitation, however.
Git rollback is not the same as application rollback.
If a deployment also changed a database schema, migrated data, triggered external transactions or altered infrastructure, reverting the source commit may not return the entire system to its previous state.
Git makes code changes reversible. The application architecture and deployment process must determine whether the broader production change is reversible too.
[Internal Link: “CI/CD for App Maintenance: How Automated Releases Reduce Risk”]
Some of the hardest maintenance bugs are not discovered immediately.
A report may say:
CSV exports stopped including cancelled orders sometime in the last six weeks.
There may have been hundreds of commits during that period.
Git provides several ways to narrow the history.
git log can filter changes by file, date, author or content. git blame can identify which revision last changed particular lines of a file, providing a useful route from current code back to the relevant commit history.
Used properly, blame is not about assigning personal blame. It is an investigation tool.
The useful question is:
“What change introduced this line, and what was that change trying to accomplish?”
The associated commit may reveal that the line appeared during a pricing change, data migration or performance optimization. That context often matters much more than the developer's name.
When you know an application worked at one point and is broken at another, Git has an especially useful maintenance tool: git bisect.
The official documentation describes git bisect as using binary search to find the commit that introduced a bug. You identify one known-good commit and one known-bad commit, then Git repeatedly checks a midpoint in the history until the responsible change is isolated.
Suppose 128 commits were made between the last known working release and the broken one.
Testing them one by one could require dozens of checks.
Binary search dramatically narrows that investigation.
Conceptually:
Known good ----------------------------- Known bad
↓
Test middle
good ---------------------------- bad
↓
Test middle
...
offending commit
If there is an automated test or script capable of determining whether a revision is good or bad, git bisect can even run that check automatically.
This is one of Git's strongest maintenance advantages: history is not merely stored for reference. It can become an active debugging tool.
[Internal Link: “Why the Same Bugs Keep Coming Back and How to Stop Them”]
Suppose a customer finds a calculation bug.
Engineering corrects the code, but nobody records the exact reason for the unusual condition that was added.
A year later, another developer refactors the same function and removes what appears to be unnecessary complexity.
The bug returns.
Good Git history cannot prevent that outcome by itself, but it can preserve the reasoning behind the fix.
A focused commit with an explanation such as:
Handle legacy invoices where adjustment rows have no tax category. Fixes incorrect totals for records created before the 2024 migration.
gives a future maintainer evidence that the apparently unusual condition is intentional.
Pair that with a regression test and the application retains both:
historical explanation — why the code exists;
executable protection — what behavior must continue working.
That combination is far stronger than either one alone.
[Internal Link: “Regression Testing: How to Update an App Without Breaking Existing Features”]
Maintenance becomes harder when teams cannot answer a simple question:
Which source code is actually running in production?
Git tags can mark significant points in history, such as releases.
A repository might contain:
v4.8.0
v4.8.1
v4.9.0
When deployment processes associate releases with specific commits or tags, an incident can be investigated against the exact source state that produced the deployed artifact.
This avoids situations where engineers inspect today's main branch even though production is running code from three weeks earlier.
Version control becomes substantially more valuable operationally when source history, release artifacts and deployed versions can be connected reliably.
Git is the record of code history; the surrounding release process should preserve the relationship between that history and what was actually deployed.
Applications with several maintainers often have changes occurring in the same area at the same time.
One developer modifies authentication to fix a session timeout problem. Another updates the login screen. A third changes identity-provider configuration.
Git does not magically decide which behavior is correct when those changes collide.
What it does provide is an explicit merge process.
When changes affect different areas, Git can often combine them automatically. When they conflict, Git surfaces the conflict so a developer has to decide how the competing versions should be reconciled.
That is safer than the classic shared-folder alternative where one person's saved file can silently overwrite another's work.
The Git book explains that branches preserve divergent histories until they are deliberately merged, allowing separate streams of work to remain isolated until integration is appropriate.
Merge conflicts can be inconvenient, but the conflict is useful information: two changes disagree about the same area of the application, and a human decision may be required.
A maintainable application needs institutional memory that survives team changes.
Commit history captures information such as what changed, when it changed, which commit preceded it and who authored or committed the work. Git's history tools can then filter and inspect that record.
This creates accountability, but it should not be confused with dependence on individuals.
The goal is not:
“Sarah changed this, so only Sarah can understand it.”
The healthier outcome is:
“This change was made for this documented reason, here is the diff, here is the related test, and here is the surrounding history.”
Good version control converts personal memory into shared engineering evidence.
That is especially important for long-lived applications maintained by several teams, outsourced partners or engineers who were not involved in the original build.
Git makes maintenance safer only if the repository workflow preserves the integrity of important history.
A team that uses Git but routinely force-pushes shared branches, bypasses reviews and commits directly to production branches receives far less safety from version control.
Repository-hosting platforms can add controls around this.
For example, GitHub branch protection can require pull requests, approvals and successful checks, prevent unauthorized force pushes, restrict who can push, and require signed commits where appropriate.
GitHub also describes protected deployment branches as a mechanism for ensuring required status checks and reviews are satisfied before code reaches important release branches.
The appropriate controls depend on application criticality.
A small internal prototype does not necessarily need the same governance as a payment platform, but important production branches should rarely be treated as unrestricted shared folders.
Version control can create false confidence if teams assume that everything can always be undone.
Several risks remain outside Git's control.
A commit can contain a logically incorrect change. A review can miss a defect. A secret committed to repository history can remain sensitive even after the visible file is removed. A source rollback cannot automatically reverse external payments or restore mutated production data.
GitHub's software-supply-chain guidance emphasizes protecting both repository access and the code stored there because malicious or unauthorized repository changes can flow into the software distributed to users.
Version control is therefore a safety foundation, not a substitute for testing, access control, backups or disciplined deployment.
Its main contribution is that those practices can operate against a clear, stable history of software changes.
A practical maintenance workflow can be summarized as follows:
This workflow is intentionally simpler than a complete delivery process. Git's role is to make each maintenance change identifiable and controllable; testing and deployment automation build further safety around that foundation.
The difference between maintaining an application with Git and merely keeping source-code copies is not convenience.
It is control over change.
With useful Git history, a team can determine what the application looked like before a maintenance task, isolate a proposed fix from unrelated development, inspect the exact difference, ask another engineer to review it, connect production behavior to a particular revision and investigate which historical change introduced a regression.
If necessary, it can also create a new commit that reverses an earlier one while retaining the evidence of what happened.
For Levelworks, this is why Version Controlled is a distinct App Health aspect rather than an administrative detail.
It supports Explainable & Debuggable because application behavior can be traced back through change history. It reinforces Tested when fixes and regression tests move together, and it contributes to Seamlessly Updatable because releases are safer when their contents are clearly defined and recoverable.
Git does not stop developers from making mistakes.
What it changes is what happens after and around those mistakes.
Instead of an application being a collection of files whose history lives mostly in people's memories, Git gives maintenance teams a navigable record of how the software reached its current state—and controlled ways to decide where it should go next.
