Git:

There are many words to define git, but it is an open-source distributed version control
system in simpler words.

Why is git needed?

When a team works on real-life projects, git helps ensure no code conflicts between the
developers. Furthermore, the project requirements change often. So a git manages all
the versions. If needed, we can also go back to the original code. The concept of
branching allows several projects to run in the same codebase.

Difference Between GitLab and GitHub

Below is a table of differences between GitLab and GitHub:

Parameters GitLab GitHub

GitLab is open-source for

Open-sourced GitHub is not open source.
community edition.

Public It allows users to make It allows users to have

Repository public repository. unlimited free repository.

GitHub allows users to have

Private GitLab also provides free free private repository but with
Repository private repository. a maximum of three
collaborators.

GitHub doesn’t have this

Project GitLab provides user to see
feature yet but they can check
Analysis project development charts.
the commit history.
 ● GitLab is freely
● It helps us create an
available and open is
organized document for
source for community
the project.
Advantages editiona
● It is used for sharing the
● It is a cloud-native
work in front of the
application and is
public.
highly secure.

● GitLab is available
with many bugs and
it makes the user ● There is a limited
Disadvantage experience sloppy. private repository.
s ● It is difficult to ● It supports only Git
manage code version control.
reviews for
first-timers.

It is owned by Microsoft
Company It is owned by GitLab Inc.
Corporation.
Git Ignore:
Git ignore files is a file that can be any file or a folder that contains all the files that we
want to ignore. The developers ignore files that are not necessary to execute the project.
Git itself creates many system-generated ignored files. Usually, these files are hidden
files. There are several ways to specify the ignore files. The ignored files can be tracked
on a .gitignore file that is placed on the root folder of the repository. No explicit
command is used to ignore the file.

Some commonly ignored files are as follows:

● dependency caches

● compiled code

● build output directories, like /bin, /out, or /target

● runtime file generated, like .log, .lock, or .tmp

● Hidden system files, like Thumbs.db or.DS_Store

● Personal IDE config files, such as .idea/workspace.xml

$ git add .gitignore

$ git commit -m "ignored directory created."

Git Revert
In Git, the term revert is used to revert some changes. The git revert command is

used to apply revert operation. It is an undo type command. However, it is not a

traditional undo alternative. It does not delete any data in this process; instead, it will

create a new change with the opposite effect and thereby undo the specified commit.

Generally, git revert is a commit.

It can be useful for tracking bugs in the project. If you want to remove something

from history then git revert is a wrong choice.

Moreover, we can say that git revert records some new changes that are just

opposite to previously made commits. To undo the changes, run the below

command:

Syntax:

$ git revert

<commit>: The commit option is used to revert a commit. To revert a commit, we

need the commit reference id. The git log command can access it.

$ git revert <commit>

Git Revert to Previous Commit

Suppose you have made a change to a file say newfile2.txt of your project. And later,

you remind that you have made a wrong commit in the wrong file or wrong branch.

Now, you want to undo the changes you can do so. Git allows you to correct your

mistakes. Consider the below image:

As you can see from the above output that I have made changes in newfile2.txt. We

can undo it by git revert command. To undo the changes, we will need the

commit-ish. To check the commit-ish, run the below command:

$ git log

Consider the below output:

In the above output, I have copied the most recent commit-ish to revert. Now, I will

perform the revert operation on this commit. It will operate as:

$ git revert 099a8b4c8d92f4e4f1ecb5d52e09906747420814

The above command will revert my last commit. Consider the below output:

As you can see from the above output, the changes made on the repository have

been reverted.
Git Cherry-pick
Cherry-picking in Git stands for applying some commit from one branch into another

branch. In case you made a mistake and committed a change into the wrong branch,

but do not want to merge the whole branch. You can revert the commit and apply it

on another branch.

The main motive of a cherry-pick is to apply the changes introduced by some existing

commit. A cherry-pick looks at a previous commit in the repository history and

update the changes that were part of that last commit to the current working tree.

The definition is straight forward, yet it is more complicated when someone tries to

cherry-pick a commit, or even cherry-pick from another branch.

Cherry-pick is a useful tool, but always it is not a good option. It can cause duplicate

commits and some other scenarios where other merges are preferred instead of

cherry-picking. It is a useful tool for a few situations. It is in contrast with different

ways such as merge and rebase command. Merge and rebase can usually apply

many commits in another branch.

Why Cherry-Pick
Suppose you are working with a team of developers on a medium to large-sized

project. Some changes proposed by another team member and you want to apply

some of them to your main project, not all. Since managing the changes between

several Git branches can become a complex task, and you don't want to merge a

whole branch into another branch. You only need to pick one or two specific
commits. To pick some changes into your main project branch from other branches

is called cherry-picking.

Scenerio1: Accidently make a commit in a wrong branch.

Git cherry-pick is helpful to apply the changes that are accidentally made in the

wrong branch. Suppose I want to make a commit in the master branch, but by

mistake, we made it in any other branch. See the below commit.

In the above example, I want to make a commit for the master branch, but

accidentally I made it in the new branch. To make all the changes of the new branch

into the master branch, we will use the git pull, but for this particular commit, we will

use git cherry-pick command. See the below output:

In the given output, I have used the git log command to check the commit history.

Copy the particular commit id that you want to make on the master branch. Now

switch to master branch and cherry-pick it there. See the below output:

Syntax:

$ git cherry-pick <commit id>

From the given output, you can see that I have pasted the commit id with git

cherry-pick command and made that commit into my master branch. You can check

it by git log command.

Git Merge and Merge Conflict

It joins two or more development history together. The git merge command

facilitates you to take the data created by git branch and integrate them into a single

branch. Git merge will associate a series of commits into one unified history.

Generally, git merge is used to combine two branches.

The "git merge" command

The git merge command is used to merge the branches

The syntax for the git merge command is as:

$ git merge <query>

It can be used in various context. Some are as follows:

Scenario1: To merge the specified commit to currently active branch:

Use the below command to merge the specified commit to currently active branch.

$ git merge <commit>

The above command will merge the specified commit to the currently active branch.

You can also merge the specified commit to a specified branch by passing in the

branch name in <commit>. Let's see how to commit to a currently active branch.

See the below example. I have made some changes in my project's file newfile1.txt

and committed it in my test branch.

Copy the particular commit you want to merge on an active branch and perform the

merge operation. See the below output:

In the above output, we have merged the previous commit in the active branch test2.

Scenario2: To merge commits into the master branch:

To merge a specified commit into master, first discover its commit id. Use the log

command to find the particular commit id.

$git log

To merge the commits into the master branch, switch over to the master branch.

$ git checkout master

Now, Switch to branch 'master' to perform merging operation on a commit. Use the

git merge command along with master branch name. The syntax for this is as

follows:

$ git merge master

As shown in the above output, the commit for the commit id

2852e020909dfe705707695fd6d715cd723f9540 has merged into the master branch.

Two files have changed in master branch. However, we have made this commit in the

test branch. So, it is possible to merge any commit in any of the branches.

Open new files, and you will notice that the new line that we have committed to the

test branch is now copied on the master branch.

Scenario 3: Git merge branch.

Git allows merging the whole branch in another branch. Suppose you have made

many changes on a branch and want to merge all of that at a time. Git allows you to

do so. See the below example:

In the given output, I have made changes in newfile1 on the test branch. Now, I have

committed this change in the test branch.

Now, switch to the desired branch you want to merge. In the given example, I have

switched to the master branch. Perform the below command to merge the whole

branch in the active branch.

$ git merge <branchname>

As you can see from the given output, the whole commits of branch test2 have

merged to branch master.’

Git Merge Conflict

When two branches are trying to merge, and both are edited at the same time and in

the same file, Git won't be able to identify which version is to take for changes. Such

a situation is called merge conflict. If such a situation occurs, it stops just before the

merge commit so that you can resolve the conflicts manually.

Let's understand it by an example.

Suppose my remote repository has cloned by two of my team member user1 and

user2. The user1 made changes as below in my projects index file.

Update it in the local repository with the help of git add command.

Now commit the changes and update it with the remote repository. See the below

output:

Now, my remote repository will look like this:

It will show the status of the file like edited by whom and when.

Now, at the same time, user2 also update the index file as follows.

User2 has added and committed the changes in the local repository. But when he

tries to push it to remote server, it will throw errors. See the below output:
In the above output, the server knows that the file is already updated and not merged

with other branches. So, the push request was rejected by the remote server. It will

throw an error message like [rejected] failed to push some refs to <remote URL>. It

will suggest you to pull the repository first before the push. See the below command:

In the given output, git rebase command is used to pull the repository from the

remote URL. Here, it will show the error message like merge conflict in <filename>.

Resolve Conflict:
To resolve the conflict, it is necessary to know whether the conflict occurs and why it

occurs. Git merge tool command is used to resolve the conflict. The merge

command is used as follows:

$ git mergetool

In my repository, it will result in:

The above output shows the status of the conflicted file. To resolve the conflict, enter

in the insert mode by merely pressing I key and make changes as you want. Press

the Esc key, to come out from insert mode. Type the: w! at the bottom of the editor to

save and exit the changes. To accept the changes, use the rebase command. It will

be used as follows:

$ git rebase --continue

Hence, the conflict has resolved. See the below output:

In the above output, the conflict has been resolved, and the local repository is

synchronized with a remote repository.

Git Rebase
In Git, the term rebase is referred to as the process of moving or combining a

sequence of commits to a new base commit. Rebasing is very beneficial and it

visualized the process in the environment of a feature branching workflow.

It is good to rebase your branch before merging it.

Generally, it is an alternative of git merge command. Merge is always a forward

changing record. Comparatively, rebase is a compelling history rewriting tool in git. It

merges the different commits one by one.

Suppose you have made three commits in your master branch and three in your other

branch named test. If you merge this, then it will merge all commits in a time. But if

you rebase it, then it will be merged in a linear manner. Consider the below image:

The above image describes how git rebase works. The three commits of the master

branch are merged linearly with the commits of the test branch.

Merging is the most straightforward way to integrate the branches. It performs a

three-way merge between the two latest branch commits.

How to Rebase
When you made some commits on a feature branch (test branch) and some in the

master branch. You can rebase any of these branches. Use the git log command to

track the changes (commit history). Checkout to the desired branch you want to

rebase. Now perform the rebase command as follows:

Syntax:

$git rebase <branch name>

If there are some conflicts in the branch, resolve them, and perform below

commands to continue changes:

$ git status

It is used to check the status,

$git rebase --continue

The above command is used to continue with the changes you made. If you want to

skip the change, you can skip as follows:

$ git rebase --skip

When the rebasing is completed. Push the repository to the origin. Consider the

below example to understand the git merge command.

Suppose that you have a branch say test2 on which you are working. You are now on

the test2 branch and made some changes in the project's file newfile1.txt.

Add this file to repository:

$ git add newfile1.txt

Now, commit the changes. Use the below command:

$ git commit -m "new commit for test2 branch." [test2 a835504] new commitfor
test2

[test2 a835504] new commitfor test2 branch

1 file changed, 1 insertion(+)

Switch the branch to master:

$ git checkout master to branch 'master.'branch is up to date with 'origin/master.'

Switched to branch 'master.'

Your branch is up to date with 'origin/master.'

Now you are on the master branch. I have added the changes to my file, says

newfile.txt. The below command is used to add the file in the repository.

$ git add newfile.txt

Now commit the file for changes:

$ git commit -m " new commit made on the master branch."

[master 7fe5e7a] new commit made on master

1 file changed, 1 insertion(+)

HiMaNshU@HiMaNshU-PC MINGW64 ~/Desktop/GitExample2 (master)

To check the log history, perform the below command.

$ git log --oneline

As we can see in the log history, there is a new commit in the master branch. If I want

to rebase my test2 branch, what should I do? See the below rebase branch scenario:

Rebase Branch
If we have many commits from distinct branches and want to merge it in one. To do

so, we have two choices either we can merge it or rebase it. It is good to rebase your

branch.

From the above example, we have committed to the master branch and want to

rebase it on the test2 branch. Let's see the below commands:

$ git checkout test2

This command will switch you on the test2 branch from the master.

Switched to branch 'test2.'

Now you are on the test2 branch. Hence, you can rebase the test2 branch with the

master branch. See the below command:

$ git rebase master

This command will rebase the test2 branch and will show as Applying: new commit

on test2 branch. Consider the below output:

GitMerge vs. Rebase

It is a most common puzzling question for the git user's that when to use merge

command and when to use rebase. Both commands are similar, and both are used to

merge the commits made by the different branches of a repository.

Rebasing is not recommended in a shared branch because the rebasing process will

create inconsistent repositories. For individuals, rebasing can be more useful than

merging. If you want to see the complete history, you should use the merge. Merge

tracks the entire history of commits, while rebase rewrites a new one.

Git rebase commands said as an alternative of git merge. However, they have some

key differences:

Git Merge Git Rebase

Merging creates a final commit at merging. Git rebase does not
create any commit at
rebasing.

It merges all commits as a single commit. It creates a linear track

of commits.

It creates a graphical history that might be a bit complex It creates a linear

to understand. history that can be
easily understood.

It is safe to merge two branches. Git "rebase" deals with

the severe operation.

Merging can be performed on both public and private It is the wrong choice to
branches. use rebasing on public
branches.

Merging integrates the content of the feature branch Rebasing of the master
with the master branch. So, the master branch is branch may affect the
changed, and feature branch history remains feature branch.
consistence.

Merging preserves history. Rebasing rewrites

history.

Git merge presents all conflicts at once. Git rebase presents

conflicts one by one.
Git Blame
With git blame you can see who changed what in a specific file, line by line, which is
useful if you work in a team, instead of alone. For example, if a line of code makes
you
wonder why it is there, you can use git blame and you will know who you must ask.

Usage
You use git blame like this: git blame NAME_OF_THE_FILE

For example: git blame triple_welcome.rb

You will see an output like this:

0292b580 (Jane Doe 2018-06-18 00:17:23 -0500 1) 3.times do

e483daf0 (John Doe 2018-06-18 23:50:40 -0500 2) print 'Welcome '

0292b580 (Jane Doe 2018-06-18 00:17:23 -0500 3) end

Each line is annotated with the SHA, name of the author and date of the last commit.
Git Version Control System
A version control system is a software that tracks changes to a file or set of files over

time so that you can recall specific versions later. It also allows you to work together

with other programmers.

The version control system is a collection of software tools that help a team to

manage changes in a source code. It uses a special kind of database to keep track of

every modification to the code.

Developers can compare earlier versions of the code with an older version to fix the

mistakes.

Benefits of the Version Control System

The Version Control System is very helpful and beneficial in software development;

developing software without using version control is unsafe. It provides backups for

uncertainty. Version control systems offer a speedy interface to developers. It also

allows software teams to preserve efficiency and agility according to the team scales

to include more developers.

Some key benefits of having a version control system are as follows.

● Complete change history of the file

● Simultaneously working

● Branching and merging

● Traceability
Just like an app has different updates due to bugs and additional feature addition,
version changes, git also supports this feature. Many developers can add their code
in parallel. So the version control system easily manages all the updates that are
done previously.

Git provides the feature of branching in which the updated code can be done, and
then it can be merged with the main branch to make it available to the users.