GIT

(Global Information Tracker)

1
 Git is a free and open-source distributed version control system. Designed
to handle everything from small to very large file projects with speed and
efficiency.
Git is a distributed version control system that means every clone of a git
repository is a complete repository with a full copy of the project’s history. This
makes it easy to collaborate with other, as each developer can work on their own
branch of the project and then merge their changes back together when they are
ready.
Git is widely used for both open-source and commercial software
development, with significant benefits for individuals, teams and businesses.
Linux Torvalds along with other is the linux development community build
& released by in 2005.

Linux Torvalds
Git is available for free under GNU. GNU is a free and open-source
operating system (OS). It's a collection of free software that can be used as an
operating system or in parts with other operating systems.
GNU General Public Licence(GPL),developed by Richard Stallman.
GNU is a series of widely used free software licence or copyleft that
guarantee end user the four freedom,
• Run
• Study
• Share
• Modify the software

2
 The GPL is copyleft licence in which licence is protective (or) reciprocal
for all works that are designed from the original.
Copyleft Redistributing the software with (or) without
changes Eg: Linux Kernal
The copyleft concepts distinguishes it from existing copyleft law is which
an author is empowered to prohibit users from reproduction adopting or
distributed their work without paying for right to do so.
Version Control System: (VCS)
Version control system that records changes to file or set of file over time
so that can recall specific version later.
It allow you to revert selected file back to a previous state, revert the entire
project back to previous state, compare changes over time, see who last modified
something that might be causing a problem.
Using VCS also generally mean that if you screw thing up or lose file, you
can easily recover.
There are three type of VCS:
• Local version control system
• Centralized version control system
• Distributed version control system
i. Local Version Control System:
Programmer long ago developed local version control system that had a
simple database that kept all the changes to files under revision control.
You manage and version all the files only within your local system.There
in no remote server in this scenario. All the changes are recorded in a local
database.

3
 ii. Centralized Version Control System:
Centralized version control system developed these system such as CVCS,
that stored all version and changes to file on a single server. That contain all the
files and the numbers of clint that checkout files from that central place.
Types of software:
➢ Concurrent version system
➢ Perforce
➢ Subversion

iii. Distributed Version Control System:

It is that allows to work on the same project without relying the central
server. Each developer has a complete copy of the project history on their local
machine and can commit, branch and merge change locally.
The changes are then synchronized with other developers through a process
called pushing and pulling.
DVCS Types:
➢ Git
➢ Mercurical
➢ AWS code commit
➢ TFS
(Client don’t just check out the latest snapshot of the files, rather they fully
mirror the repository including its full history)

4
 If server dies & there system were collaborating that server any of the client
repository can be copied back upto the server to restore it every clone is really a
full backup of all the data.

Directory (or) Folder Only contain files and other directory

Just create, modify and delete.
Repository It is also like directory it’s also stored a
modification history.

5
 Git has a remote repository which is stored in a server & a local repository
which is stored in computer of each developer.
Git is distributed which mean that a project complete history is stored both
on the client and on the server.

Hash Git uses hashes that are 160 bits large if the
file time and data stamp its changed.
Git use SHA-1 algorithm.

.git Git repository on your machine contains a .git

folder.
You know that some how the folder holds the history of every version of
every file over committed to the repository.
The git folder will contain details of entry single change mode to the code
base. All snapshorts of the modification will be recorded in this folder like a
database. Which make it possible to under the change & Roll back to the desired
version of the code.
Inside the .git repository

6
 .git repository contain the some directory are,
a) Hooks:
This folder contain script file. Git hook that run automatically when
certain events occur in a git repository. They are useful tools for automating
checks as you move through your general workflow.
For example: You can setup a git hook that prevents you from committing if
the hook script detects a problem.

There are two groups of hooks: Client-Side and Server-Side.

Client-side hooks are triggered by operations such as committing and
merging, while Server-side hooks run on network operations such as receiving
pushed commits.
To use a git hooks, simply create a script with a .sh extension in the
.git/hooks directory.

7
You can use git hooks to automate a variety of tasks, such as:
❖ Checking for style violations
❖ Running tests
❖ Linting code
❖ Automating deployments
b) Object:
In git, an object is a fundamental entity that represents different types of
data in the repository.
There are four types of objects:
i. Blob:
Blob are used to store file data. They are generally the contents of
a file.
ii. Tree:
Tree are like directories. They reference a bunch of other trees and
blob (i.e. files and sub-directories).
iii. Commit:
Commits hold metadata for each change introduction in the
repository, including the author, committer, commit-data and log-messages.
iv. Tag:
Tags are used to mark important points in the repository history.

Every object consists of three things: A type, A size and content.

8
 c) Config:
This is used to set git configuration values on a global or local
project level.
There are three levels of git config:
➢ Project config: Are only available for the current project and stored in
.git/config in the project’s directory.
➢ Global config: Are available for all projects for current user and stored in
~/.gitconfig .
➢ System config: Are available for all user/projects and stored in
/etc/gitconfig .

Here some examples of git configuration variable:

User.name:- The name of the user who is making the commit.
User.email:-The email address of the user who is making the commit.
Core.editor:-The text editor that git should use to edit commit messages.
Colour.ui:- Whether or not git should use colour in its output.
d) Refs :
A git reference(git refs) is a file that contains a git commit SHA-1
hash. When referring to a git commit, you can use the git reference, which is an
easy-to-remember name, rather then the hash.
A branch is a git reference that stores the new git commit hash. These
endpoints allow you to read and write reference to you git database on github.

9
 e) HEAD:
The most recent commit to the current checkout branch is indicated
by the HEAD. It points to the master branch by default. The current branch can
be thought of as the HEAD.
The HEAD is moved to the branch when you use the checkout command
to swap branches.

f) Index:
The index file in git is a binary file that contains a list of all the files
that are being tracked by git. His also known as the staging area or the cache.
The index file located at .git/index in the root directory of your git
repository.

The index file contains the following information for each file:
The file’s name
The file’s permissions
The file’s size
The file’s SHA-1 hash

10
 The index file is an important part of git. It allows you to stage change
before you commit them, and it ensure that your changes are not lost if you
accidentally modify a file.

Git installing on windows:

The most official build is available for download on the Git website. Just
go to https://git-scm.com/download/win and the download will start
automatically. Note that this is a project called Git for Windows, which is separate
from Git itself; for more information on it, go to https://gitforwindows.org.

Git installing on linux:

If you want to install the basic Git tools on Linux via a binary installer, you
can generally do so through the package management tool that comes with your
distribution.
(OR)
Go to kernel and enter these command,

Git installing on Mac:

If you want a more up to date version, you can also install it via a binary
installer. A macOS Git installer is maintained and available for download at the
Git website, at https://git-scm.com/download/mac.

11
Git Commands:
1. git –version
The output of the command is the version of git that is installed on
your system. For example, if you have git version 2.43.0 installed the output of
the command will be:

git –version
git version 2.43.0

2. git config –global user.name “<username>”

The command is sets your git username. This command should
include both your first and name. However, your username can be anything you
want to attach to your commit.

3. git config –global user.email “<useremail>”

The command is set your email on git. Changing the name and email
on git will only affect future work.

4. git init
This command creates a new git repository. It can be used to convert
an existing, unversioned project to a git repository or initialize a new, empty
repository.
Most other git commands are not available outside of an initialized
Repository, So this is usually that first command you’ll run in a new project.

5. git add

That command is used to add files to the staging area. The staging
area is a holding area for files that your next commit. Once you have added
files to the staging area, you can commit them to the repository.

12
6. git status

The git status command is used to display the current state of the
local repository. The information displayed by the git status command
includes the name of the branch, the current status branch, staged/unstaged
changes, etc..,

7. git commit

Since we have finished our work, we are ready move from stage to
commit for our repository.

Git considers each commit change point or “save point”. It is a point

in the project you can go back to if you find a bug, or want to make change.

When we commit, we should always include a message. By adding

clear message to each commit, is easy for yourself to see what has changed
and when. The commit command performs a commit, and -m “message” add
a message.

Syntex are,

(git commit -m “message”)

8. git log

The git log command is used to view the commit history of a

repository. It lists all the commits that have been made to the repository, in
reverse chronological order. The most recent commit is shown first.

The git log --oneline command displays each commit on a single line, with
the commit hash and commit message separated by a space. This can be
particularly useful for quickly scanning the commit history of a repository.

9. git clone

Here we’ll examine the git clone command in depth. Git clone is a
git command line utility which is used to target an existing repository and
create a clone or copy of the target repository. In this page we’ll discuss
extended configuration options and common use cases of git clone.

13
Some points we’ll cover here are:

• Cloning a local or remote repository

• Cloning a bare repository
• Using shallow options to partially clone repository
• Git URL syntax and supported protocols.

10.git diff

That command is used to see the difference between two versions of

a file or directory. It can be used to compare the current version of a file with
the version that was last saved, or to compare the version of a file in the
working directory with the version that is currently staged.

It can also be used to compare two difference branches, or two different

commits.

11.git decode hash

To decode a git hash, you can the git cat-file command.

The syntax is:

git cat-file<hash>

This will print the contents of the object with the given hash.

12.git checkout -b<branch name>

The git checkout -b command is used to create a new branch and

switch to it. It is a shortcut for the two commands git branch and git checkout.

To switch back to the previous branch, you would use the git checkout
command without -b option.

The git checkout command is a powerful tool that can be used to manage
branches and commits. It is an important command to learn for any git user.

14
13.Rename branch

git branch -<branch name>

This command is used to rename the current branch.

14.git merge

The git merge command is used to combine changes from two or

more branches into one branch. It is very powerful tool that can be used to
create new features, fix bugs and improve the overall quality of your code.

They syntax are:

git merge<branch-name>

15.git rm –cached(file name)

Remove the file only from the git repository, but not from the
filesystem.

By default, the git rm command deletes files both from git repository as
well as the filesystem. Using the --cached flag, the actual file on disk will not
be deleted.

16.Delete branch:
a. git branch -d

That command is used to delete a local git branch. It is important to

note that the branch must be merge into main branch before it can deleted.

If the branch has not been merged, the git branch -d command will not
delete it and will instead output an error message.

b. git branch -D

It is also similar to git branch -d. The -D flag tells git to force the
deletion of the branch, even if it has uncommited changes.

15
Git workflow
Empowering a software development team begins with identifying a single
branching strategy. Identifying a single Git workflow is a necessary step in
ensuring rapid delivery. Software development teams encompass contributors
from various backgrounds and experiences, and they're likely to feel comfortable
with a workflow they've used previously. Without a single workflow, a team's
development workflow could be chaotic and slow down cycle time.
Git workflows empower teams to determine roles and responsibilities, set
boundaries, and identify areas of improvement.

Centralized Git workflow

A centralized Git workflow enables all team members to make changes
directly to the main branch (sometimes called the master branch or default
branch), with every change logged in a running history. A centralized workflow
involves every contributor committing to the main branch without using any other
branch. This strategy works well for small teams, because team members can
communicate so that multiple developers aren't contributing to the same piece of
code simultaneously. Centralized workflow can be seamless if team members
communicate well, but there are limitations. If multiple developers commit to the
same branch, it's challenging to find a stable moment to release changes.
Consequently, developers must keep unstable changes local until they're ready
for release.

Feature branching Git workflow

Every feature gets its own branch when developers commit to this
workflow. Rather than commit directly to the main branch, developers create a
branch, make changes, submit a merge request (or pull request), and then merge
it into main.
Ideally, a feature branch should have a lifespan of a few hours. The longer
the branch lives, the higher the risk to find integration conflicts when merging
back to main. After all, at this scale, there are plenty of teams working on other
branches and directly streaming changes to the main branch, incrementing
entropy and chances of running into conflict with local changes.

16
Trunk-based development Git workflow
Trunk-based development facilitates concurrent development on a single
branch called trunk. When developers are ready to push changes to the central
repository, they'll pull and rebase from it to update the working copy of the central
branch. Successful trunk-based development requires a developer to resolve
merge conflicts locally. Regularly updating the local branch reduces the impact
of integration changes, because they're spotted when they're still small, avoiding
merge hell.
Personal branching Git workflow
Personal branching is similar to feature branching, but rather than have a
single branch per feature, it's per developer. This approach works well if team
members work on different features and bugs. Every user can merge back to the
main branch whenever their work is done.
Forking Git workflow
A forking approach to version control starts with a complete copy of the
repository. Forking effectively creates a local copy of a Git repository and
provides the ability to create a new collaboration structure. In other words, every
developer in the team has two repositories: a local workspace and a remote
repository.
This workflow is popular for projects that have multiple developers contributing
to it, particularly open source projects. After all, keeping track and providing
privileges to collaborate to a repository with thousands of contributors is difficult
to maintain. If a maintainer enables contributors to try their changes on their
forked copy, managing change proposals is easier and safer.
GitFlow Git workflow
With GitFlow, the main branch should always be releasable to production,
and there should never be untested or incomplete code on the main branch. When
using this Git workflow, no one commits to the main branch but rather uses a
develop branch with feature branches. When the develop branch is ready to go to
production, a contributor creates a release branch where testing and bug fixing
occur before being merged back to the develop branch. The release branch makes
the code review process easier, because there's a dedicated place to resolve
conflicts when merging into the main branch. With this strategy, the main branch
always reflects production.

17