How does Git work?

Git is a DVCS (Distributed Version Control System).

What is DVCS?

It means each system will work as a VCS/work station

These systems do not necessarily rely on a central server to store all the versions of a project file.

Every contributor has a local copy or “clone” of the main repository i.e. Everyone maintains a local repository on its own, which is actually the copy or clone of the central repository on their hard drive. They can commit and update their local repository without any interference.

DVCS

Pros:

• All operations (except push & pull) are very fast because the tool only needs to access the hard drive, not a remote server. Hence, you do not always need an internet connection.
• Committing new change-sets can be done locally without manipulating the data on the main repository. Once you have a group of change-sets ready, you can push them all at once.
• Since every contributor has a full copy of the project repository, they can share changes with one another if they want to get some feedback before affecting changes in the main repository.
• If the central server gets crashed at any point of time, the lost data can be easily recovered from any one of the contributor’s local repositories.

How Does Git work?

Git workflow

How to use git?

Install Git on your system and remote system.

Basic operations in Git are:

• Initialize
• Add
• Commit
• Pull
• Push

Advanced Git operations are:

• Branching
• Merging
• Rebasing

Initialize

In order to do that, we use the command git init.

git init creates an empty Git repository or re-initializes an existing one. It basically creates a .git directory with sub directories and template files. Running a git init in an existing repository will not overwrite things that are already there.

Git status

The git status command lists all the modified files which are ready to be added to the local repository.

Add

In order to do that, we use the command git add <file>

This command updates the index using the current content found in the working tree

Use this command , after making changes to the working tree, and before running the commit command.

Commit

In order to do that, we use the command git commit -m “<message>”

It refers to recording snapshots of the repository at a given time. Committed snapshots will never change unless done explicitly.

Git aims to keep commits as lightweight as possible. So, it doesn’t blindly copy the entire directory every time you commit; it only copies the changes made in the repository.

You can commit by using the command below:

git commit

This will commit the staged snapshot and will launch a text editor prompting you for a commit message.

Or you can use:

git commit -m “<message>”

Pull

In order to do that, we use the command git pull

It fetches changes from a remote repository to a local repository. It merges upstream changes in your local repository, which is a common task in Git based collaborations.

But first, you need to set your central repository as origin using the command:

git remote add origin <link of your central repository>

Now that my origin is set, let us extract files from the origin using pull. For that use the command:

git pull origin master

This command will copy all the files from the master branch of remote repository to your local repository.

Since my local repository was already updated with files from master branch, hence the message is Already up-to-date. Refer to the screen shot above.

Note: One can also try pulling files from a different branch using the following command:

git pull origin <branch-name>

Your local Git repository is now updated with all the recent changes. It is time you make changes in the central repository by using the push command.

Push

In order to do that we use command git push <remote>

This command transfers commits from your local repository to your remote repository. It is the opposite of pull operation.

Note : This remote refers to the remote repository which had been set before using the pull command.

e.g. the command git push origin master to reflect these files in the master branch of my central repository.

Now you can see the changes in central repository.

To prevent overwriting, Git does not allow push when it results in a non-fast forward merge in the destination repository.

Note: A non-fast forward merge means an upstream merge i.e. merging with ancestor or parent branches from a child branch.

To enable such merge, use the command below:

git push <remote> –force

The above command forces the push operation even if it results in a non-fast forward merge.