You may not use these technologies for a while, but once the software volume becomes larger and the number of developers increases, this will bring about qualitative changes, and you need some tools or technologies to complete these complex projects.
You can think from the simplest case. You can version control any type of file, such as a ppt. After you modify it, you are not satisfied and want to return to the state at a previous point in time. The most primitive approach is to store previously unmodified files locally. Then people encountered a problem, how to make developers on different systems work together? Therefore, the centralized version control system (Centralized Version Control Systems, referred to as CVCS) came into being
This approach brings many benefits, especially compared to the old-fashioned on-premises VCS. Now everyone can see to some extent what other people in the project are doing. The administrator can also easily control the permissions of each developer, and each developer can perform their own duties and complete software development collaboratively, and managing a CVCS is far easier than maintaining a local database on each client. There are two sides to things, good and bad. The most obvious disadvantage of doing this is the single point of failure of the central server.
So the distributed version control system (Distributed Version Control System, DVCS for short) came out. In such systems, such as Git, Mercurial, Bazaar, and Darcs, the client does not just take a snapshot of the latest version of the file, but mirrors the entire code repository. In this way, any server used for collaborative work fails, and it can be recovered with any mirrored local warehouse afterwards. Because each clone operation is actually a complete backup of the code repository.
Git has three states, and your files may be in one of them: committed, modified, and staged. Submitted means that the data has been safely stored in the local database. Modified means that the file has been modified but not yet saved to the database. Staged means that the current version of a modified file is marked for inclusion in the next committed snapshot.
This introduces the concept of three working areas of a Git project: the Git repository, the working directory, and the staging area. The working directory, staging area, and Git repository are shown below −