You are working on a file. You change it. The change breaks something. You want to go back to how it was before you changed it. You cannot, because you saved over it. The old version is gone. This is the oldest problem in computing and one of the oldest problems in writing. Every scribe who ever scratched out a line on vellum and wished they hadn't has had this problem.
Source control is the solution. It is a system that remembers every version of every file you have ever saved. Not just the current version — every version. You can go back to any point in the history of any file and see exactly what it looked like at that moment. You can see who changed it, when they changed it, and what they said about why they changed it.
The earliest version of this idea was simple: make a copy of the file before you change it. Call it index.html.bak. Then index.html.bak2. Then index-old-march-12.html. Then index-FINAL.html. Then index-FINAL-ACTUALLY-FINAL.html. This does not scale. This is chaos. Every person who has ever done this knows it is chaos.
In 1972, Marc Rochkind at Bell Labs built SCCS — the Source Code Control System. It stored the history of a single file. You could check out a file, change it, and check it back in, and the system would remember what it looked like before. This was revolutionary. It was also limited to one file at a time and one person at a time.
In 1982, Walter Tichy at Purdue built RCS — the Revision Control System. It was faster and smarter about storage but still one file at a time. In 1986, Dick Grune built CVS — the Concurrent Versions System — which could track whole directories of files and let multiple people work on them at the same time. CVS was ugly and broken in many ways but it worked well enough that the entire open source movement of the 1990s was built on top of it.
In 2000, CollabNet built Subversion (SVN) to be "CVS done right." It tracked whole directories, it was atomic (a commit either fully happened or didn't happen at all), and it was centralized — there was one server that held the truth, and everyone checked out from that server and committed back to it. Subversion was a massive improvement over CVS. Most of the software industry used it for a decade.
The problem with centralization is that the server is a single point of failure and a bottleneck. If the server is down, nobody can commit. If the server is slow, everyone is slow. If the network is unavailable, you cannot even look at your own history. You are dependent on a machine you do not control for access to the history of your own work.
In 2005, Linus Torvalds built Git because he needed something fast enough to handle the Linux kernel — the single largest collaborative software project in human history, with thousands of contributors across every timezone. He built it in about two weeks. It was not designed to be friendly. It was designed to be correct and fast.
Git is distributed. Every person who works on a project has the complete history of every file on their own machine. There is no central server that you depend on. You can commit, branch, merge, look at history, compare versions — all of it — on an airplane with no internet. The repository on your machine is a full peer of every other copy. When you push to a remote, you are sharing your history with another copy. When you pull, you are incorporating their history into yours. No copy is the "real" one. They are all real.
This is why Git is better than Subversion. Not because it has more features — though it does. Because you own your own history. Your ability to look at what you did, to undo what you did, to understand what happened, does not depend on anyone else's machine being online or reachable or not overloaded.
A commit is a snapshot. It says: at this moment in time, this is what every file looked like. It has a message that says what changed and why. It has a timestamp. It has an author. It has a cryptographic hash that uniquely identifies it and makes it impossible to tamper with after the fact.
A commit is a save point in a video game. It is the moment you can always return to. If everything goes wrong after this point, you can come back here and everything will be exactly as it was.
The history of commits forms a directed acyclic graph — each commit points back to its parent, the commit that came before it. You can follow the chain all the way back to the first commit, the moment the project began. Every change is recorded. Nothing is lost. The graph can branch (two people working on different things at the same time) and merge (those two lines of work coming back together). The structure of the graph is the structure of the collaboration.
You commit because the alternative is not having a history. The alternative is the file as it exists right now on disk, with no record of how it got there, no ability to go back, no way to understand what changed or when or why. The alternative is flying blind.
A junior developer on their first day at their first job in any company in any city in any country on earth knows this. It is the first thing you learn. It is more fundamental than knowing any programming language. You can write code in any language and commit it. You cannot write code without committing it and have any confidence that your work is safe.
You commit after every meaningful change. Not at the end of the day. Not when you remember. After every change. The commit is the unit of work. If you did something and you did not commit it, you did not do it — you merely intended to do it, and your intention lives only in the volatile memory of a machine that can crash, reboot, or be overwritten at any moment.
Committing saves the history on your machine. Pushing saves it somewhere else. Your machine can die. Your disk can fail. You can accidentally delete the repository. If the only copy of the history is on one machine, the history is exactly as fragile as that machine.
Pushing to a remote is a backup. It is also a way to share your work with others. When multiple people — or multiple robots — are working on related things, the remote is where the histories come together. It is the meeting point. Without it, everyone is working in isolation and nobody knows what anyone else has done.
A robot that modifies files without committing is a robot that destroys evidence. Every file modification overwrites the previous content. Without a commit, the previous content is gone. When something goes wrong — and something always goes wrong — the first question is "what changed?" Without commits, the answer is "nobody knows." With commits, the answer is in the log, with timestamps, with diffs, with messages explaining what was intended.
A robot that commits but does not push is a robot whose work exists on a single machine that it does not fully control. The human can reboot it. The cloud provider can terminate it. The disk can fill up. The work is safe only if it exists in more than one place.
Commit after every change. Push after every commit. This is not a best practice. This is not a recommendation. This is the minimum. Everything below this minimum is negligence.