GIT - Tutorial

1. Git is a distributed revision control and source code management software.

2. Git is a free software distributed under the terms of the GNU General Public License version 2.

Version Control System

Version Control System (VCS) is a software that helps software developers to work together and maintain a complete history of their work.

Listed below are the functions of a VCS −

• Allows developers to work simultaneously.
• Does not allow overwriting each other’s changes.
• Maintains a history of every version.

Following are the types of VCS −

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

Distributed Version Control System

Centralized version control system (CVCS) uses a central server to store all files and enables team collaboration. But the major drawback of CVCS is its single point of failure, i.e., failure of the central server. Unfortunately, if the central server goes down for an hour, then during that hour, no one can collaborate at all. And even in a worst case, if the disk of the central server gets corrupted and proper backup has not been taken, then you will lose the entire history of the project. Here, distributed version control system (DVCS) comes into picture.

DVCS clients not only check out the latest snapshot of the directory but they also fully mirror the repository. If the server goes down, then the repository from any client can be copied back to the server to restore it. Every checkout is a full backup of the repository. Git does not rely on the central server and that is why you can perform many operations when you are offline. You can commit changes, create branches, view logs, and perform other operations when you are offline. You require network connection only to publish your changes and take the latest changes.

DVCS Terminologies

Local Repository

Every VCS tool provides a private workplace as a working copy. Developers make changes in their private workplace and after commit, these changes become a part of the repository. Git takes it one step further by providing them a private copy of the whole repository. Users can perform many operations with this repository such as add file, remove file, rename file, move file, commit changes, and many more.

Working Directory and Staging Area or Index

The working directory is the place where files are checked out. In other CVCS, developers generally make modifications and commit their changes directly to the repository. But Git uses a different strategy. Git doesn’t track each and every modified file. Whenever you do commit an operation, Git looks for the files present in the staging area. Only those files present in the staging area are considered for commit and not all the modified files.

Let us see the basic workflow of Git.

Step 1 − You modify a file from the working directory.

Step 2 − You add these files to the staging area.

Step 3 − You perform commit operation that moves the files from the staging area. After push operation, it stores the changes permanently to the Git repository.

Suppose you modified two files, namely “sort.c” and “search.c” and you want two different commits for each operation. You can add one file in the staging area and do commit. After the first commit, repeat the same procedure for another file.

Blobs

Blob stands for Binary Large Object. Each version of a file is represented by blob. A blob holds the file data but doesn’t contain any metadata about the file. It is a binary file, and in Git database, it is named as SHA1 hash of that file. In Git, files are not addressed by names. Everything is content-addressed.

Trees

Tree is an object, which represents a directory. It holds blobs as well as other sub-directories. A tree is a binary file that stores references to blobs and trees which are also named as SHA1 hash of the tree object.

Commits

Commit holds the current state of the repository. A commit is also named by SHA1hash. You can consider a commit object as a node of the linked list. Every commit object has a pointer to the parent commit object. From a given commit, you can traverse back by looking at the parent pointer to view the history of the commit. If a commit has multiple parent commits, then that particular commit has been created by merging two branches.

Branches

Branches are used to create another line of development. By default, Git has a master branch, which is same as trunk in Subversion. Usually, a branch is created to work on a new feature. Once the feature is completed, it is merged back with the master branch and we delete the branch. Every branch is referenced by HEAD, which points to the latest commit in the branch. Whenever you make a commit, HEAD is updated with the latest commit.

Tags

Tag assigns a meaningful name with a specific version in the repository. Tags are very similar to branches, but the difference is that tags are immutable. It means, tag is a branch, which nobody intends to modify. Once a tag is created for a particular commit, even if you create a new commit, it will not be updated. Usually, developers create tags for product releases.

Clone

Clone operation creates the instance of the repository. Clone operation not only checks out the working copy, but it also mirrors the complete repository. Users can perform many operations with this local repository. The only time networking gets involved is when the repository instances are being synchronized.

Pull

Pull operation copies the changes from a remote repository instance to a local one. The pull operation is used for synchronization between two repository instances. This is same as the update operation in Subversion.

Push

Push operation copies changes from a local repository instance to a remote one. This is used to store the changes permanently into the Git repository. This is same as the commit operation in Subversion.

HEAD

HEAD is a pointer, which always points to the latest commit in the branch. Whenever you make a commit, HEAD is updated with the latest commit. The heads of the branches are stored in .git/refs/heads/ directory.

Revision

Revision represents the version of the source code. Revisions in Git are represented by commits. These commits are identified by SHA1 secure hashes.

URL

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

Advantages of Git

1. Free and open source
2. Implicit backup
3. Security
4. Easier branching

Git - Life Cycle

General workflow is as follows −

• You clone the Git repository as a working copy.
• You modify the working copy by adding/editing files.
• If necessary, you also update the working copy by taking other developer's changes.
• You review the changes before commit.
• You commit changes. If everything is fine, then you push the changes to the repository.
• After committing, if you realize something is wrong, then you correct the last commit and push the changes to the repository.

Shown below is the pictorial representation of the work-flow.

Git Pull

git pull, in contrast, is used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server. This means that pull not only downloads new data; it also directly integrates it into your current working copy files. This has a couple of consequences:

• Since "git pull" tries to merge remote changes with your local ones, a so-called "merge conflict" can occur. Check out our in-depth tutorial on How to deal with merge conflictsfor more information.
• Like for many other actions, it's highly recommended to start a "git pull" only with a clean working copy. This means that you should not have any uncommitted local changes before you pull. Use Git's Stash feature to save your local changes temporarily.

git pull origin master

https://git-scm.com/docs/git-pull

Git Fetch
git fetch really only downloads new data from a remote repository - but it doesn't integrate any of this new data into your working files. Fetch is great for getting a fresh view on all the things that happened in a remote repository.
Due to it's "harmless" nature, you can rest assured: fetch will never manipulate, destroy, or screw up anything. This means you can never fetch often enough.

git fetch origin

Git - Managing Branches

Create Branch

Tom creates a new branch using the git branch <branch name> command. We can create a new branch from an existing one. We can use a specific commit or tag as the starting point. If any specific commit ID is not provided, then the branch will be created with HEAD as its starting point.

git branch new_branch

git branch
* master
new_branch

A new branch is created; Tom used the git branch command to list the available branches. Git shows an asterisk mark before currently checked out branch.

The pictorial representation of create branch operation is shown below −

Switch between Branches

git checkout new_branch

Shortcut to Create and Switch Branch

In the above example, we have used two commands to create and switch branches, respectively. Git provides –b option with the checkout command; this operation creates a new branch and immediately switches to the new branch.

git checkout -b test_branch

Switched to a new branch 'test_branch'
git branch
master
new_branch
* test_branch

Delete a Branch

A branch can be deleted by providing –D option with git branch command. But before deleting the existing branch, switch to the other branch.

Jerry is currently on test_branch and he wants to remove that branch. So he switches branch and deletes branch as shown below.

git branch
master
new_branch
* test_branch

git checkout master
Switched to branch 'master'
git branch -D test_branch
Deleted branch test_branch (was 5776472).


Now, Git will show only two branches.
git branch
* master
new_branch

Rename a Branch

Jerry decides to add support for wide characters in his string operations project. He has already created a new branch, but the branch name is not appropriate. So he changes the branch name by using –m option followed by the old branch nameand the new branch name.

git branch -m new_branch wchar_support

git branch
* master
wchar_support

Question and Answer

What's the difference between git fetch and git pull?

git clone https://SG0308640@git.sabre.com/scm/qa/ux-e2e-test-platform.git

git clone https://git.prod.sabre.com/scm/qa/ngp-base-framework.git

git branch postfulfillment_fix

git checkout postfulfillment_fix

git push --set-upstream origin postfulfillment_fix

git push --set-upstream origin IET_WIXC_Update

************************************************************************************************************************

git checkout -b postfulfillment_fix

************************************************************************************************************************

git clone -b tn_enhancements ssh://git@git.sabre.com/qa/ux-e2e-test-platform.git

git clone -b ticketingenhancements_nirbhay ssh://git@git.sabre.com/qa/ux-e2e-test-platform.git

git clone --branch feature_mofl_pricing_qualifier ssh://git@git.sabre.com/qa/ux-e2e-test-platform.git

git clone --branch feature_MVP1 https://SG0308640@git.sabre.com/scm/qa/ux-e2e-data.git

git clone https://SG0308640@git.sabre.com/scm/qa/ux-e2e-data.git

git clone -b wtdb_fit_fixes https://SG0308640@git.sabre.com/scm/qa/ux-e2e-data.git

************************************************************************************************************************

git pull origin master

git pull origin tn_enhancements

git pull origin ticketingenhancements_nirbhay

************************************************************************************************************************

git push --set-upstream origin tourcode_sac_fixes_pricing

git push --set-upstream origin WTDB_display_deepak

*************************************************Delete branch locally/remotely ****************************************

git branch -D feature_mvpo_tkt_qualifiers_santosh

git push origin --delete feature_mvpo_tkt_qualifiers_santosh

git push --set-upstream origin Commercial_HOT_file_upgrade

Read More»