Working with Git
Say you've started your workday. You have a project with some files, and you need to do a thing (add a new feature, fix a bug, etc.). You also want to keep it under version control.
As a result, some new files will be created, and some existing files will be modified or deleted. Your project's working tree will change.
Oh, by the way, that's Git lingo for project files. Let's take a moment to understand it.
The (also known as the working directory) is the real set of files in your project in their current state. It's the version of the project you see in front of you and work with. When someone talks about changes in the working tree, they mean changes you've made in files but haven't saved to Git yet. That can include new files, modifications, and deletions.
So, you worked on your project, and now you have some changes in the working tree. You're ready to save your progress. But before that, you need to review those changes and decide which ones you want to keep.
At this point, Git can show you which files have changed and which lines in those files were added, removed, or modified. You can review those changes, add the ones you want to the staging area, and discard the ones you don't.
The is Git's short-term memory, where it records which changes you've selected for the next project snapshot (called a commit in Git terms; more on that in a moment).
Say I spent a whole day working on a big change to the project, and now that I'm finished, I want to save these changes permanently in the project history. I want to create a Git , a snapshot of the current state of the project files. Once a commit is created, it becomes part of the project history and cannot be easily changed or deleted.
But before creating it, you need to decide exactly which changes should go into the next commit. Most of the time, that's all the changes you made. But sometimes it's better to split them into several commits to keep the project history organized. In that case, you add only part of the changes to the staging area, make a commit, and then repeat the process for the rest.
Analogy: you washed your car and also topped off the windshield washer fluid. Those are two independent changes, so it's better to commit them separately. Otherwise, the change history for the washer fluid tank will contain a "Washed the car" entry, which doesn't really match what changed and could confuse whoever reads that history later.
Once you have picked and organized the changes you want to keep, all that's left is to create the commit itself. As part of the commit, you can also leave a description that explains exactly what changed and why. This makes the project history easier to understand when you or someone else looks at it later. Once the commit is created, those changes are permanently saved in Git's repository (more Git lingo for "project history").
A is Git's long-term memory. Every commit you make becomes part of the repository.
Some commits may be part of your main project history, some may be part of experimental branches, some may be temporary commits that you later discard, and so on. A commit may be as small as fixing a typo in a single line of code, or as large as adding a whole new feature with hundreds of files changed.
The repository is stored in the .git directory at the root of your project. Keep in mind that this directory is hidden by default. Damaging or deleting this directory will corrupt your local Git repository.
While you can stop here and have a complete local history of your project, pushing and pulling changes to and from a remote repository is a common next step.
If you're working on a team, this is how you share your changes with others and get their updates, too. Your new commits will be uploaded to the remote repository, and you'll download any commits your teammates pushed since you last synced.
If you're working alone, you still get the benefit of not losing your work if something happens to your computer, and you can access your project from any device. You can also share your code with others by giving them access to the remote repository.
-
Return to Step 2 if you have other completed code that is ready to be saved in the project history. Stage and commit more changes. You can also discard any remaining unstaged changes if needed.
-
Return to Step 1 if you want to continue working on your project, making more changes to the working tree.
At first, all of this can feel a bit confusing, especially if you haven't worked with version control before. But over time, this process starts to feel natural, and eventually you'll do most of it almost automatically.
Take the course as it was meant to be taken: bite-sized progression, focused linear order, gradually unlock Gitopedia entries. Continue with real Git in VS Code/Cursor/Antigravity/Windsurf at any time.
but requires sign-in