You can ask an AI to generate a feature in seconds, but if you cannot commit, diff, or revert that code, you cannot work on a real team. Git and GitHub solve that: Git records the history of your project, and GitHub hosts it in the cloud for collaboration.
What are Git and GitHub, and why do developers still need them?
Git is a distributed version control system created by Linus Torvalds in 2005, and GitHub is the most widely used cloud hosting platform for Git repositories. Versioning is the practice of creating, tracking, and managing different points in a project's history so teams can see who changed what, navigate to earlier versions, and reverse problematic changes instantly.
The official Git documentation describes the same workflow covered in a recent Rocketseat course taught by instructor Bruno Mestanza: snapshots, commits, change history, error recovery, and collaborative work through branches. None of that becomes obsolete when an AI writes the code. When a model or a teammate produces a change you did not fully review, a clear commit history is what lets you inspect it, compare it, and undo it.
The main reasons version control matters in daily work are:
- Collaboration: 5, 10, or 20 developers can work on the same codebase without overwriting each other, and every addition is attributed to a person.
- Full history: you can find exactly when a feature landed or a bug was introduced.
- Error recovery: if a release breaks production, you roll back to a point where the bug did not exist, fix the problem, and ship a new version.
- Safe experimentation: parallel branches let you test new features without touching the code running in production.
What is the difference between Git and GitHub?
Git is the version control tool that runs on your machine; GitHub is a hosting service that puts Git repositories in the cloud. The two are often confused, but they are different layers: Git works entirely offline, while GitHub adds remote storage, collaboration, and sharing on top of Git. GitHub is the most famous option, but GitLab and Bitbucket are comparable platforms that also run on Git.
In practice, the Rocketseat course frames it simply: GitHub is the way to put a Git project in the cloud so other people can see and contribute to it. A local repository on your laptop is invisible to teammates until you connect it to a remote host. The video cites more than 100 million repositories hosted on GitHub, a figure GitHub's own marketing has also used to describe its scale.
Where did version control come from before Git?
Before Git, version control evolved through several generations, each with limits the transcript walks through chronologically.
- 1980s, RCS: the Revision Control System versioned each file individually, so a 1,000-file project carried 1,000 separate histories. It did not scale and it was slow.
- 1990s, centralized systems: tools like CVS added team collaboration, but everything depended on one server, so saving and browsing history was slow.
- 2000s, distributed systems: BitKeeper introduced distributed versioning to the market, though it was cumbersome to use.
- 2005, Git: Torvalds built Git in a matter of weeks to manage Linux kernel development, after the kernel community lost free use of BitKeeper.
Why did Linus Torvalds build Git, and why did it take over?
Linus Torvalds, the creator and longtime lead maintainer of the Linux kernel, built Git because existing tools were too slow and awkward for a project of Linux's size. His stated goals were speed, a simple design, strong support for non-linear development through branches, a distributed workflow, and the ability to manage very large projects without degradation. The Git project's own history page records the same motivations.
The transcript gives a concrete performance contrast from that era: under older distributed systems, releasing a new version of a very large project could take 20 to 30 minutes, while Git brought that down to roughly 15 to 20 seconds. Take those numbers as the speaker's account of the period, not a reproducible benchmark. Git's integrity model also helps explain its adoption: every commit carries a SHA-1 hash, so if repository data is corrupted, Git detects it instead of silently storing a broken version.
How do snapshots, commits, and the three states work?
Git stores your project as a series of snapshots, like photographs in an album. Each snapshot, called a commit, records what changed since the previous one: files created, files modified, files deleted. Git does not copy the whole project every time; it references the unchanged files and stores only the differences, which is why large repositories stay fast.
Files in a Git repository move through three states. Understanding this flow is the core of daily Git use:
- Working directory: where you edit code in your editor. Changes here are not yet tracked for the next version.
- Staging area: files you mark with
git addas ready for the next commit. You can stage some changes and leave others out. - Commits: the permanent history. Each commit has a unique hash, a message written by the author, and metadata such as author and date that Git captures automatically.
One detail worth knowing: Git identifies files by name and location. If you rename a file or move it to another folder, Git records the old file as deleted and the new one as created. Seeing a file flagged as deleted after a simple rename is normal, not data loss.
How do you install and configure Git on each operating system?
Installation differs per platform, but verification and first-time configuration are identical everywhere. After installing, run git --version in any terminal; a version number confirms success. Then set your identity globally, because every commit records the name and email you configure.
| OS | Install method | Notes |
|---|---|---|
| Windows | Official installer (64-bit, ARM64, or 32-bit) | Includes Git Bash; check your architecture in System Information |
| macOS | Xcode, binary download, or Homebrew (brew install git) | Homebrew is the route shown in the course; Xcode bundles Git but is heavy if you do not build Apple apps |
| Linux | Distro package manager (sudo apt install git on Debian/Ubuntu, dnf on Fedora) | The Git download page lists commands for many distros |
Configure your identity with git config --global user.name "Your Name" and git config --global user.email "[email]". The --global flag applies the setting to every project on the machine; omit it and run the command inside a repository to set a per-project identity. Once installed, Git works from any terminal and any editor integration, including VS Code.
To start versioning a project, run git init inside its folder. Before that, Git commands like git commit fail with a "not a git repository" error; after it, Git creates a hidden .git folder that stores all version data. Never edit files inside .git by hand; corrupting it can cost you the entire history.
How do you undo changes safely with restore, reset, and revert?
Git offers three undo tools, and choosing between them is the decision beginners get wrong most often. All of them compare against a commit; if you pass none, Git uses HEAD, the pointer that normally marks your most recent commit.
| Command | What it does | Typical use |
|---|---|---|
git restore | Rewrites working-directory files to match a commit | Discard uncommitted changes, such as code written against the wrong API |
git reset --soft / --mixed / --hard | Moves HEAD back, undoing the commit locally | Remove your last commit; --soft keeps changes staged, --mixed unstages them, --hard deletes them |
git revert | Creates a new commit that reverses an old one | Undo a commit that is several steps back while preserving history |
The course illustrates restore with a realistic scenario: you build a feature against one AI provider's SDK, the team switches providers, and you discard the uncommitted work with git restore . instead of manually uninstalling packages. For reset, prefer undoing only your most recent commit; resetting many commits back destroys history and makes testing harder. --hard permanently deletes the changes on your machine, so use it only when you are certain the code is disposable.
revert is the team-safe option for shared history. Instead of erasing a commit, it adds a new commit that removes the earlier change, with a default message naming the reverted hash. The course example: a feature letting users pick expensive AI models gets reverted with an explicit commit explaining why, so the record shows the decision rather than a silent disappearance.
What is git diff for in the age of AI-written code?
git diff shows the differences between two states of a project: working directory versus the last commit, staged changes versus the last commit (with --staged), or commit A versus commit B by hash. It is the command for inspecting code before it becomes history.
The Rocketseat course singles out one use case that has grown with AI assistants: reviewing generated code before committing. A model asked for a new feature often produces changes directly, and git diff (together with git blame, which shows who last modified each line) lets you or a reviewer see exactly what will enter the repository. Diffing is also the standard way to review a colleague's pull request code and to investigate which change introduced a bug.
Frequently asked questions
- Are Git and GitHub the same thing? No. Git is the version control system that runs locally on your machine; GitHub is a cloud hosting platform for Git repositories. GitLab and Bitbucket are alternatives that also host Git projects.
- Do I still need Git if AI writes my code? Yes. AI can generate code, but committing, reviewing diffs, branching, and reverting remain human workflow responsibilities, and Git is the standard tooling for all of them.
- What is a commit? A commit is a snapshot of your project at a moment in time. It stores the differences since the previous commit, a unique hash, an author, a date, and a descriptive message.
- What is the difference between git reset and git revert?
git resetmoves HEAD backward and rewrites local history, optionally deleting changes with--hard.git revertkeeps history intact by creating a new commit that undoes an older one, which is the safe choice on shared branches.
- Why does Git show a renamed file as deleted and new? Git identifies files by name and path. A rename or a move registers as a deletion of the old path plus the creation of the new one.
Turn your own video lessons into readable articles
This article followed the same path a good commit does: capture what exists, organize it, and make it easy to revisit later. If you have teaching material, walkthroughs, or recorded talks sitting in YouTube videos, that knowledge deserves the same treatment: a written version people can search, skim, and quote.
Skala Blog handles that flow: paste a YouTube URL, get a transcription, and generate a structured article from it. The lessons in your videos become pages your audience can actually read.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits