How Git works
The functionality of Git revolves around efficiently managing project files and tracking their changes over time. Unlike traditional version control systems that track changes to each file, Git considers your codebase as a series of snapshots of a miniature filesystem. Let's break down how Git operates.
Three main states of files in Git
-
Working tree (also known as the working directory). These are your actual working files in their current state. It's the version of your project that you see and work on.
-
Staging area (also known as the index). When you're finished with your work, it's time to "snapshot" the changes and store this snapshot in the repository permanently. In Git terms, such a snapshot is called a commit. The staging area is where you prepare your changes for the next commit. It exists because you might not want to commit all the changes you've made since the last commit. The staging area lets you group related changes into a single commit.
For example, if you developed a simple feature, but in the process you also fixed a typo in a comment, you can commit these changes separately, because these changes are unrelated. Otherwise, if you commit them together, and later need to revert the feature, you'll also revert the typo fix.
-
Repository. Once you commit your changes, they become a part of the Git repository. You can think of the repository as a database of all the changes you've made to your project over time. It's the complete history of your project, and it's where Git stores all the snapshots of your project.
The repository is stored in the
.gitdirectory in your project's root directory. Keep in mind that this directory is hidden by default. Damaging or deleting this directory will corrupt your local repository.
Git workflow
The typical Git workflow involves:
-
Work on your project (add a feature, fix a bug, etc).
In the end, some of the files will be added, changed or removed.
-
Review the changes and decide what you'd like to keep.
At this point, Git can show you what files were changed, and what lines inside those files were added, removed or modified. You can browse these changes and add the ones you want to the Git staging area.
-
Commit staged changes to the repository.
Once you're satisfied with the changes you've staged, you can create a commit that stores a snapshot of these changes permanently in the repository. You can easily discard any remaining unstaged changes if you don't need them.
-
(optionally) Sync your local repository with a remote repository, such as GitHub.
If you're working in a team, this is how you share your changes with others and get their updates as well. Your new commits will be uploaded to the remote repository, and you'll download any commits your teammates pushed since you last synced.
-
Repeat from step 1 as needed.
While Git is not involved in writing your code on step 1, once you have your repository set up, you can get even more benefits from using Git. You can compare your files with previous versions, revert parts of them to earlier state, create branches to experiment with new ideas without affecting the main codebase, etc.
If you're new to Git, this might seem a bit overwhelming at first, but once you get the hang of it, it becomes second nature.