Git Basic Concepts

Version control system (VCS)

The version control system (VCS) is software that helps software developers work together on their job and maintain a complete history.

The following are the VCS targets

1. Allows developers to work synchronously.
2. Do not overwrite each other's changes.
3. Maintain a history of each version.

The following are common VCs

1. Centralized version control system (CVCS)
2. Decentralized/Distributed version control system (DVCS)

In this tutorial, we will introduce a centralized distributed version control system, especially git. Git belongs to the Distributed version control system.

Distributed version control system (DVCS)

The centralized version control system uses all the files stored on the central server and enables team collaboration. But the main disadvantage of CVCs is the single point of failure of the central server. Unfortunately, if the central server goes down for an hour, then no one can cooperate during that time. Even in the worst case, if the central server's disk is damaged and does not take proper backups, then the entire project's history will be lost.

Dvcs customers not only check out the latest snapshot directory, but they also fully reflect the resource pool. If sever is down, then it can be replicated back to the server from any client library to restore it. Each checkout is a full version of the repository backup. Git does not rely on a central server, which is why many operations can be performed when it is offline. You can commit changes, create branch view logs, and perform other operations when you are offline. Just need a network connection, post your changes, and take the latest changes.

Git advantage

Git is released under the GPL open source license. It can be free on the Internet. You can use Git to manage projects without paying a penny. Since it is open source, you can download its source code and make changes as required.

Since most operations are performed locally, it brings great benefits in terms of speed. Git does not rely on a central server, why there is no need for each operation to interact with the remote server. The core part of Git is written in C, which avoids the runtime overhead associated with other high-level languages. Although git reflects the entire repository, the size of the data on the client is small. This shows how efficient it is to compress and store data on the client.

The chance of losing data is very rare when there are multiple replicas. exists in any client's data repository, so it can be used in the event of a crash or disk corruption of the mirror.

Git uses a common cryptographic hash function called a Secure Hash Algorithm (SHA1) to name and determine the objects in its database. Each file and submit a check summary and retrieve its check at checkout time. This means that it is impossible to change the file, date, commit information and any other data from git database without knowing git.

In cvcs cases, the central server needs to be strong enough to require the entire team to serve. For smaller teams, this is not a problem, but as the team grows, the hardware limitations of the server can become a performance bottleneck. In the case of Dvcs development, do not interact with the server unless they need to push or pull changes. All the heavy lifting occurs on the client, so the server hardware can be very simple.

CVCs uses a cheap copy mechanism, which means that if we create a new branch, it will copy all the code to the new branch, so it's time-consuming and inefficient. In addition, the deletion and merging of CVCs branches is complex and time-consuming. However, using GIT branch management is simple. It only takes a few seconds to create, delete, and merge branches.

1. Free and open source
2. Fast and small
3. Implicit back-up
4. Safety
5. No need for powerful hardware
6. A simpler branch

Dvcs Terminology Local Resource library

Each VCS tool provides a working copy of the private workplace. The developer changes in his private workplace and submits these changes to become part of the warehouse. Git needs this step, providing them with a dedicated copy of the entire repository. Users can do many things in this library, such as adding files, deleting files, renaming files, moving files, submitting changes, and more.

Working directory, staging area, or index

The working directory is a local file check out. Other CVCS developers generally do not modify and commit his changes directly to the repository. But git uses a different strategy. Git does not track every file that has been modified. Whenever the commit operation, Git is in the current staging area of the file. Only files that are considered present in the staging area are submitted, not all modified files.

Let's take a look at Git's basic workflow.

1th Step: Modify the working directory of the file.

2nd step: Add these files to the staging area

3rd Step: Perform a commit operation. This will file from the staging area. After the push operation, it permanently stores the changed git repository

Assume that you have modified two files, namely "sort.c" and "search.c", to commit the two different actions separately. You can add a file staging area without committing. Repeat the same steps after the first commit for another file.

git add sort.c  # adds file to the staging area [bash]$ git commit–m "Added sort Operation"

# Second Commit [bash]$ git add search.c  # adds file to the staging area [bash]$ git commit–m ' Added search operation ”

BLOBS

The blob represents a binary large object. To represent each version of the Blob file. A blob saves the file data, but does not contain any metadata about the file. It is a binary file that is named SHA1 hash in the GIT database. In Git, the name is not mentioned in the file. All fixed content addressing.

Tree

A tree is an object that represents a directory. It has blobs and other subdirectories. A tree is a binary file that stores a blob tree and is also named as a reference to the SHA1 hash of the tree object.

Commit

Submits the current state of the owning library. The commit command is also named by the name of the SHA1 hash. You can consider a linked list node for a commit object. Each committed object has a pointer to the parent commit object. From a given commitment can traverse the look-up in the parent pointer to view the history of the commit. If multiple parent commitments are committed, this means that a particular commit is merged by two branches.

BRANCHES

Branching is used to create another line of development. By default, Git's main branch, which is the same as torso subversion. Create a branch with new features that you normally want to work on. Once the feature is complete, it is merged back into the master branch and we delete the branch. Each branch refers to the head, which is the latest commit in the branch. Whenever a commit is made, head is updated to the latest commit.

TAGS

Includes assigning a meaningful name to a label in a particular repository. Tags are very similar branches, but the difference is that the tags are immutable. A branch of means mark, no one intends to modify. Once a tag is created as a specific commit, it will not be updated even if a new commit is created. Typically developers create labels for product launches.

CLONE

Creates an instance of the library for the clone operation . The clone operation not only checks out the working copy, but it also reflects the complete repository. The user can perform many operations on this local repository. Network intervention is the only time when the database instance is synchronizing.

Pull

The pull operation replicates the changes that are local to an instance from the remote repository. A pull operation is used for synchronization between two repository instances. This is the same as the Subversion update operation.

PUSH

Drives a change in the copy of the remote operation from the local repository instance. This is used to store permanent changes in the Git repository. This is the same as the commit operation in subversion.

HEAD

The head pointer always points to the most recent commit of the branch. Whenever you make a commit, head updates to the latest commit. Head branches are stored in the. git/refs/heads/directory.

[centos]$ ls-1. Git/refs/heads/master

[centos]$ Cat. Git/refs/heads/master 570837e7d58fa4bccd86cb575d884502188b0c49

REVISION

The source code for the revised version. The commit of the GIT revision Rep. These commits are determined by the SHA1 secure hash value.

Url

The URL represents the location of the Git repository. The URL of Git is stored in the configuration file.

[Email protected] tom_repo]$ Pwd/home/tom/tom_repo

[email protected] tom_repo]$ cat. Git/config [core] repositoryformatversion = 0 FileMode = True bare = False logallref updates = true [ remote "origin"] URL = [email protected]:p roject.git fetch = +refs/heads/*:refs/remotes/ori gin/*

PS: If you want to communicate with the industry technology Daniel, please add QQ Group (521249302) or pay attention to the public number (askharries), thank you!

Git Basic Concepts