Understanding
Git
Version control keeps every version of a project and lets you return to any of them. It is what makes it safe to let anyone, or anything, change your code.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
When you save a file, the previous version stops existing.
That is the default behavior of a computer. For a letter it does not matter. For anything a business runs on it does: the version that worked on Tuesday is gone, and nobody can say what changed between then and the failure on Friday.
Git keeps every version, with a record of who changed what and why.
A backup holds the latest copy. Git holds every version.
A commit is a version you can return to.
You make changes, then commit them. Git takes a snapshot of every file as it stands, records your name and the time, and asks for one line explaining the change.
The message matters. The files show what changed. The message is the only record of why.
A repository is the project plus every commit ever made to it.
Copying the repository copies the history with it. Any commit can be restored exactly: the project as it stood at a specific moment, not an approximation reconstructed from a backup.
A branch is a copy of the project you can change without affecting the working version.
Make your changes on the branch. If they work, merge them back in. If they do not, delete the branch and the working version is unchanged.
Teams usually run several branches at once, one per change in progress, and merge each as it is finished.
The version customers depend on stays untouched while work is going on.
Git is the system. GitHub is a company that hosts it.
Git runs on your own machine and needs nothing else. GitHub, GitLab and Bitbucket are hosting services built around it. They hold a shared copy so a team can work against one history, and they add review, permissions, discussion and automation on top.
Git works without any of them. Most companies use one, because the shared copy is what makes team work possible.
A repository is also how software is published and collected.
When a company or an individual makes code available to other people, they do it by publishing the repository. Anyone who wants a copy runs one command and receives the project with its full history, rather than a zip file of the current state.
Almost all open source works this way. So does most of what your team installs: a package on a public registry is nearly always built from a repository that anyone can read.
The system that stores the history is also the system that distributes it.
Most systems now release from the repository.
Push a commit to the main branch and hosting services build it and put it live, with nobody copying files onto a server. The repository is not only the record of the work. It is the source of what is actually running.
Two things follow from that. What is in the repository is what your customers get, so a mistake merged is a mistake shipped. And access to the repository is access to production, which makes it a permissions question rather than a developer preference.
Who can merge is a business decision.
Version control is what makes it safe to let an AI change your code.
An AI can rewrite twelve files in ninety seconds. Without version control there is no reliable way to undo that. With it, one command returns the project to its previous state, and the history shows exactly what changed.
This is why version control is a requirement for AI-assisted work rather than an optional developer practice.
Commit before the AI runs, so there is a point to return to.
Git is built for text, and it keeps everything.
It tracks code, configuration and notes well. It handles large binary files such as video, images and datasets poorly. Those belong in storage, with the repository holding a reference to them.
Because nothing is removed from the history, a password committed once is still in the history after it is deleted from the file. Removing it properly is difficult. Keep credentials out from the start, as covered in lesson seven.
Anything committed is permanent and visible to everyone with access.
Keep every version, record the reason, branch to experiment.
Commit small and often. Write a message that says why. Use a branch for anything uncertain. Keep credentials and large files out. The repository is also where the code is published from and released from, so treat access to it as access to the product.