1. Git is a Version Control System (VCS). VCS are used for source code management.
2. Git keeps track of the changes in files and directories. It does a good job of keeping track of text changes.
If we have a text file that has been changed over a period of time, GIT helps us to view different versions of the file edit them and also compare the different versions of the same file.
3. GIT was created in April 2005 and was created by Linus Torvalds.
4. GIT is a distributed control system.
5. GIT is open source and free software.
6. It is compactable with Linux, MacOS, Windows.
Central Version Control System and Distributed Version Control system
Central Version Control System:
1. SCSS, RCS, CVS, and SVN uses the above model.
2. In this model, we keep the code in the central repository, the programmer has to download the code from the central repository, make changes and then update the same in the central repository.
3. If there are other programmers, then they will also have to update those recent changes from the central repository.
4. If the central repository is down, work cannot be continued until that server is up.
Distributed Version Control System:
1. Git is a distributed Version control system.
2. Here each programmer maintains their own repository i.e. local repository instead of working from the main repository.
3. If the server gets corrupted then any of the client repositories can be restored to the server.
4. From the time where the server got crashed to the time it is restored back, programmers can continue to work with their local copy.
5. It helps in “forking” of the projects, the developers can work independently.
GIT uses 3 tree architecture.
2. Staging Index
Here We have a working repository where we work locally. Then those files that are changed locally are moved to the staging area. Then the files from stating area are moved to the Master Repository.
For some programmers, it might be difficult to understand the concept of “Staging”. Staging is a concept where the files that are changed locally are ready to be moved [commit] to the master repository. For example, if we have changed 10 files locally, but we want to commit only 5 of the files for the first commit set, then we can move only those files into the staging area then commit to master repository, then next 5 files.
It is possible, to skip the staging then directly commit to the repository.
Below is the GIT Workflow example:
1. We have a “new file”.
2. We added this “new file” to a working directory.
3. We use “git add” command to move the file to the staging area.
4. We use “git commit” command to move the file from staging to the master repository.
5. When we change the file in the local repository, we repeat step 3, 4 to update the changed files to the repository.
6. We use “git log” command to get the logs of the changes done.
GIT referring to Commits:
1. GIT refers the changes or snapshots with the help of a checksum. When we commit to the repository GIT creates a checksum for each changeset. The checksum is a process of converting a piece of data into a simple number with the help of the algorithm. When the same number is input to the algorithm it will return the checksum. Hence we can check for data integrity in GIT.
2. GIT generates the checksum with the help of an SHA-1 hash algorithm. It always generates a 40-character hexadecimal string.
GIT HEAD pointer:
GIT maintains a variable called as “HEAD” pointer. Its job is to point to the latest commit.
If we commit a new snapshot, then the HEAD pointer will move to the new commit. It always points to the “tip” of the current branch repository or always points to the starting of the next commit.