In this article, I'll tell you about VCS (Version Control System), about Git itself, why you should learn it, and other cool stuff that even advanced users among you could not know.
In a nutshell, Version Control System is a system that records changes to a file or a set of files over time and allows you to return later to a specific version of your project. It means that even if you or your co-worker made a mistake you can easily return to the latest version of your project and start from there again. It makes everything easier and gives you chances to experiment
- Local (RCS)
- Centralized (CVS, Subversion)
- Distributed (Git, Mercurial, BitKeeper)
Local VCS deployed on one machine and works as a backup of a specific machine. Pictures or diffs (difference between two versions of your project) do not go beyond a certain computer. Just like you made a copy of the folder on your computer.
The centralized VCS is installed on a local server within the same network. And it can store snapshots or diffs from all computers from this network on the server.
And distributed VCS is a vivid example of GitHub, when from anywhere in the world via the Internet you can store your versions in one cloud storage regardless of what network you are in or from what computer. Also, it allows copies to be moved not only from parent to storage and back but also between different parents.
- Simple design.
- Strong support for non-linear development (thousands of parallel branches).
- Fully distributed.
- Able to handle large projects like the Linux kernel efficiently (speed and data size).
- Versions are snapshots, not diff.
- Almost all operations are performed locally
- Integrity. The SHA-1 hash is calculated for everything.
- After adding data to the git, it is hard (but possible) to lose them.
- Full git support is available only in the terminal.
- All files can be in one of the following states - committed, modified, staged
SnapshotsDiffsEach project file in Git/Mercurial indexing process can have one of the three possible states:
modified, but not staged: This is when a project file is modified by the user, but Git/Mercurial has no track of the file changes at the moment. If the file is lost or removed unexpectedly, then Git cannot recover the file.
staged for commit to the repository: When a file is modified it can be added to the Git staging area to be later committed permanently to the repository. The staging area is a file, generally contained in the project's repository ( directory), that stores information about what will go into the next commit to the repository. The staging area is also sometimes referred to as the index. .git
committed to the repository: Once the staged files are committed to the repository, they become a permanent part of it and can be later extracted (checked out) for review or further development.
These three file states comprise an important integral part of Git and Mercurial. The following figure illustrates the three file states.
I tried to describe almost all aspects of VCS and GIT and why you should pay attention to them, the next part will be with the smaller features and I hope will be interesting.
You can add me at Discord: MarkFusion#2903