22CS910 DEVOPS

GIT
• Version control is a system that records changes to a file or set of files
over time so that you can recall specific versions
• Local Version Control Systems
• ISSUE need to collaborate with
developers on other systems.
Centralized Version Control
Systems
• ISSUE
• single point of failure
Distributed Version Control Systems
Git is a distributed version control system
clients don’t just check out the latest
snapshot of the files; rather, they fully
mirror the repository, including its full
history. Thus, if any server dies, and
these systems were collaborating via that
server, any of the client repositories can
be copied back up to the server to restore
it. Every clone is really a full backup of all
the data.
INTRODUCTION TO GIT
• Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time commit, or
save the state of the project, Git basically takes a picture of what all files look like at that moment and stores a
reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to
the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

• ADVANTAGE OF GIT
• No need to connect to central server
• Can work without internet connection
• No single failure point
• Developers can work independently and merge their work later
• Every copy of a Git repository can serve either as the server or as a client
• Git tracks changes, not versions
• Bunch of little change sets floating around
What is Repository

• “repo” = repository

• Usually used to organize a single project

• The purpose of git is to manage a project, or a set of files, as they change over time.
Git stores this information in a data structure called a repository

• A git repository contains, mainly a set of commits

• Repos can contain folders and files, images, videos, spreadsheets and data sets –
anything your
• project needs
A simple Git workflow
After initializing a new git repo…
A note about commit messages

• Tell what it does (present tense)

• Single line summary followed by blank space followed by more complete description

• Keep lines to <=72 characters

• Ticket or bug number helps

• A commit object mainly contains three things

• 1. A set of changes the commit introduces
• 2. Commit messages describing the changes
• 3. A hash, a 40-character string that uniquely identifies the commit object
The HEAD Pointer

• Points to a specific commit in repo

• As new commits are made, the pointer changes

• HEAD always points to the “tip” of the currently checked-out branch in the repo

• Not to the working directory or staging index

• Last stage of repo (what was checked out initially)

• HEAD points to parent of next commit(where writing the next commit takes place)
22CS910 DEVOPS
D.M.KALAI SELVI
ASSISTANT PROFESSOR
CSE DEPARTMENT
R.M.D ENGINEERING COLLEGE
GIT COMMANDS USED IN GIT
BASH.EXE
• cd command
• cd command refers to change directory
• SYNTAX : cd folder_name
• ls command
• ls command is used to list all the files and folders in the current directory.
• SYNTAX: ls
1.Set your global username/email configuration
Open Git Bash and begin creating a username and email for working on Git Bash. Set your
username:
git config --global user.name "FIRST_NAME LAST_NAME"
Set your email address:
git config --global user.email "MY_NAME@example.com"
2. GIT INIT COMMAND
Initialize the local directory as a Git repository
git init

3) Git clone command

This command is used to make a copy of a repository from an existing URL. If I want a local copy of my
repository from GitHub, this command allows creating a local copy of that repository on your local directory
from the repository URL.

SYNTAX

$ git clone URL

4) Git add command

This command is used to add one or more files to staging (Index) area.
Syntax
To add one file
$ git add Filename
To add more than one file
$ git add*
5. GIT COMMIT COMMAND
This command changes the head. It records or snapshots the file permanently in the version history
with a message.
Syntax
$ git commit -m " Commit Message"
Git commit -a
This command commits any files added in the repository with git add and also commits any files
changed since then.
Syntax
$ git commit -a
• 6) Git status command
• The status command is used to display the state of the working directory and the
staging area. It does not show you any information about the committed project
history.
• Syntax
• $ git status
• 7) Git push Command
• It is used to upload local repository content to a remote repository.
• It's the complement to git fetch, but whereas fetching imports commits to local
branches on comparatively pushing exports commits to remote branches
• SYNTAX
• $ git push [variable name] master
Git push -all
This command pushes all the branches to
the server repository.
Syntax
$ git push --all

8) Git pull command

Pull command is used to receive data from GitHub. It fetches and merges changes on the remote server
to your working directory.
Syntax
$ git pull URL

9) Git Branch Command

This command lists all the branches available in the repository.
Syntax
$ git branch
10) Git Merge Command
This command is used to merge the specified branch?s history into the current branch.
Syntax
$ git merge BranchName

11) Git log Command

This command is used to check the commit history.
Syntax
$ git log

12) Git remote Command

Git Remote command is used to connect your local
repository to the remote server.
13)Git Checkout
In Git, the term checkout is used for the act of switching
between different versions of a target entity.
Syntax:
$ git checkout <branchname>
ADDING README.MD FILE

• A ReadMe file is a standard place for instructions or documentation that you want to share with
people about a repo.

1. Create a file named README.md in the root (based) folder of the Git repo.
2. Add any instructions or documentation that you want to share with others.

3. When done, commit the changes and push them to the remote repo.
GETTING UP REPOSITORY

• Git repository in local machine can be obtained in one of two ways:

• Take a local directory that is currently not under version control, and turn it into a Git
repository, or
• You can clone an existing Git repository from elsewhere.
• Initializing a Repository in an Existing Directory
For Linux:
$ cd /home/user/my_project
for macOS:
$ cd /Users/user/my_project
for Windows:
$ cd C:/Users/user/my_project
and type:
$ git init
GIT CLONE
Every version of every file for the history of the project is pulled down –git clone command
SYNTAX
git clone <url>
CREATING REPOSITORY
The clone command will create a directory named libgit2, initializes a .git directory inside it,
pulls down all the data for that repository, and checks out a working copy of the latest version

$ git clone https://github.com/libgit2/libgit2

The cloned repository can also be save into a new directory

$ git clone https://github.com/libgit2/libgit2 mylibgit

Mylibgit-target directory
To Create Local Repository in GIT

• Step 1: $ cd c:\localhost
• Step 2 : $ mkdir my-new-repository
• Step 3: $ cd my-new-repository
• Step 4: $ git init
• Step 5: $ touch my-new-filename.text
(Creating a new file in the repository)
• Step 6 : $ git status
• Step 6: $ git add my-new-filename.txt
• Step 7: $ git status
• Step 8: $ git commit –m ”create a new file my-new-filename.txt” (commit the changes to the
local repository)
• Step 9: $ git log(to see the file added)
• Step 10: $ git checkout –b “my-new-branch” (create a new branch. Branch is adding feature
without affecting the main project
• Step 11: $ git branch(to see which branch we are in )
• Step 12: $ touch myfile-branched.txt (create a new file in the new branch)
• Step 13: $ git add myfile-brancehed.txt(add the file to the new branch)
• Step 14: $ git commit –m “Create a new file mufile-branched.txt”
• Step 15: $ git status
• Step 16 : $ git log (changes shows the log history)
• Merge the new branched file with the master file
• Step 17: $ git checkout
• Step 18: $ git branch
• Step 19: $ git merge my-new-branch(merged the changes to the main file)
Recording Changes to the Repository

File in working directory can be in one of two states: tracked or

untracked.
Tracked files are files that were in the last snapshot, as well as
any newly staged files; they can be unmodified, modified, or
staged. Tracked files are files that Git knows about.
Untracked files are everything else — any files in your working
directory that were not in your last snapshot and are not in your
staging area. When you first clone a repository, all of your files
will be tracked and unmodified because Git just checked them out
and you haven’t edited anything.As you edit files, Git sees them as
modified, because you’ve changed them since your last commit.
As you work, you selectively stage these modified files and then
Viewing commit history
Git log command: git log lists the commits made in that repository in reverse chronological order
options
1.A patch is a text file whose contents are similar to Git diff but along with code it contains
metadata about commits, for example, a patch file will include commit ID, date, commit message,
etc.
Options –p or –patch can be used in log command
Ex: $git log –p -2
// list only last two enteries

2. --stat
option prints below each commit entry a list of modified files, how many files were changed, and how
many lines in those files were added and removed. It also puts a summary of the information at the end.
3.– pretty
This option changes the log output to formats other than the default.
Value to the –pretty option
The oneline value for this option prints each commit on a single line.
short, full, and fuller values show the output in roughly the same format but with less or more
information,
Format which allows you to specify your own log output format.
Ex;
$ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott
Chacon, 6 years ago : Change version number 085bb3b - Scott
Chacon, 6 years ago : Remove unnecessary test a11bef0 - Scott
Chacon, 6 years ago : Initial commit
Specifier Description of Output
%H Commit hash
%h Abbreviated commit hash
%T Tree hash
%t Abbreviated tree hash
%P Parent hashes
%p Abbreviated parent hashes
%an Author name
%ae Author email
%ad Author date (format respects the --date=option)
%ar Author date, relative
%cn Committer name
%ce Committer email
%cd Committer date
%cr Committer date, relative
%s Subject
Option Description
-p Show the patch introduced with each commit.
--stat Show statistics for files modified in each commit.
Display only the changed/insertions/deletions line from
--shortstat
the --stat command.
Show the list of files modified after the commit
--name-only
information.
Show the list of files affected with
--name-status
added/modified/deleted information as well.
Show only the first few characters of the SHA-1
--abbrev-commit
checksum instead of all 40.
Display the date in a relative format (for example, “2
--relative-date
weeks ago”) instead of using the full date format.
Display an ASCII graph of the branch and merge history
--graph
beside the log output.
Show commits in an alternate format. Option values
--pretty include oneline, short, full, fuller, and format (where
you specify your own format).
Shorthand for --pretty=oneline --abbrev-commit used
--oneline
together.
Option Description

-<n> Show only the last n commits

--since, --after Limit the commits to those made after the specified date.

--until, --before Limit the commits to those made before the specified date.

Only show commits in which the author entry matches the

--author
specified string.

Only show commits in which the committer entry matches the

--committer
specified string.

Only show commits with a commit message containing the

--grep
string

Only show commits adding or removing code matching the

-S
string
UNDOING THINGS
One of the common undos takes place when you commit too early and possibly forget to add some files,
or you mess up your commit message. If you want to redo that commit, make the additional changes
you forgot, stage them, and commit again using the --amend option:

$ git commit --amend

Unstaging a Staged File

git reset HEAD <file> OR git restore

Unmodifying a Modified File

git restore
Working with Remotes

• Remote repositories are versions of your project that are hosted on the Internet or network
somewhere.
• To see which remote servers you have configured, you can run the git remote command.
• You can also specify -v, which shows you the URLs that Git has stored for the shortname to be
used when reading and writing to that remote:
• EXAMPLE
• $ git remote –v
backdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
Cho45 https://github.com/cho45/grit (fetch)
• To add remote repositoriesgit remote add <shortname> <url>
Fetching and Pulling from Your Remotes
git fetch command only downloads the data to your local repository — it doesn’t automatically merge it
with any of your work or modify what you’re currently working on. You have to merge it manually into
your work when you’re ready.
$ git fetch <remote>
git pull command to automatically fetch and then merge that remote branch into your current branch
Pushing to Remotes
When you have your project at a point that you want to share, you have to push it upstream. The
command for this is simple: git push <remote> <branch>
Inspecting a Remote
If you want to see more information about a particular remote, you can use the git remote show
<remote> command.
Ex $git remote show origin
Renaming and Removing Remotes
You can run git remote rename to change a remote’s shortname
$ git remote rename pb paul
$ git remote remove
$ git remote rm:
Tagging
• Listing Your Tags
• Git has the ability to tag specific points in a repository’s history as being important.
• Example
• $ git tag
• v1.0
• v2.0
• You can also search for tags that match a particular pattern.
• Example
• $ git tag -l "v1.8.5*“
• v1.8.5
• v1.8.5-rc0
• v1.8.5-rc1
• v1.8.5-rc2
• v1.8.5-rc3
• v1.8.5.1
• Creating Tags
• Git supports two types of tags: lightweight and annotated.
• Annotated Tags
• Annotated tags are stored as full objects in the Git database. They’re checksummed; contain the tagger name,
email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG)
• Example
• $ git tag -a v1.4 -m "my version 1.4"
• Lightweight Tags
• Another way to tag commits is with a lightweight tag
• Ex:$ git tag v1.4-lw
• Tagging Later
• Tagging of commits can also be done after moved on
• Ex $ git tag -a v1.2 9fceb02
• Sharing Tags
• By default, the git push command doesn’t transfer tags to remote servers. It will have to explicitly push tags to a
shared server after created them. This process is just like sharing remote branches — you can run git push origin
<tagname>.
• Deleting Tags
• To delete a tag on your local repository, you can use git tag -d <tagname>
• There are two common variations for deleting a tag from a remote server.
• The first variation is
$git push <remote> :refs/tags/<tagname>
• The second (and more intuitive) way to delete a remote tag is with:
$ git push origin --delete <tagname>

• Checking out Tags

• If you want to view the versions of files a tag is pointing to, you can do a git checkout of that tag,
Git Aliases

• Git doesn’t automatically infer your command if you type it in

partially.
• If you don’t want to type the entire text of each of the Git commands,
• you can easily set up an alias for each command using
• git config.
• $ git config --global alias.co checkout
• $ git config --global alias.br branch
• $ git config --global alias.ci commit
• $ git config --global alias.st status
Git
Basics
• Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.
• It was initially designed and developed by Linus Torvalds for linux
kernel development.
• Now it is maintained by Junio Hamano.
• Every Git working directory contains a full-fledged repository with
complete history and full revision tracking capabilities
• It is not dependent on network access or a central server.
Steps to get your project
•
into Git
There are two steps to get the project into the git.

Step 1 : Cloning the existing Git repository from the server to your
local git repository.
Commands:
git clone git://github.com/schacon/grit.git(URL)
Step 2 : Import the existing project or directory into your local
git repository and push into the remote git repository.
Commands:
git init // Create an empty Git repository or reinitialize an existing
one
git add *.* // Add file contents to the index
git commit -m ‘ initial version’ // Record changes to the local
repository
git push origin master // Push the code into remote repository
Three
states

Three main states of a Git:

• Working Directory

• Staging Area

• Git Directory
Contd…

Git directory - Stores the metadata and object database for

your project (while cloning the repository)

Working directory - Single checkout of one version of the project.

The files in the directory are pulled out of the compressed database in

the Git directory and placed on disk for you to edit and use.

Staging area - It is a simple file, generally present in your Git

directory, that stores information about what will go into your next

commit.
Recording Changes to the
Repository

• Each file in your working directory can be in one of the

following two states:

Tracked or Untracked

• File status in Life Cycle :

• Untracked

• Unmodified

• Modified

• Staged
Checking the status of Your
files
Command : git status

1.Untracked Files - Files in your working directory that are not present

in your last snapshot and staging area.

2. Tracked Files - Files that are present in the last snapshot

The following command is used to make the file status as trackable

Command : git add filename

Contd…

3. Staging Modified Files – A File which is already tracked and has

been modified in the working directory, but not yet staged.

4. Unstaging Modified Files - A File that is out of the staging area.

The following command is used to make the file unstaged

Command : git reset HEAD filename

Viewing Your Staged and Unstaged
Changes

• To view the difference between staged and unstaged files

•
Command : git diff

• To view the difference between staged and the last committed file

•
Command : git diff –cached

•
Note : git diff does not show the difference of staged and the last

committed file
Commiting Your Changes

• The simplest way to commit is to type

Command : git commit

• To commit along with comments

Command : git commit –m “Comments”

Skipping the Staging Area:

• To skip the staging area during commits

Command: git commit –a –m

Removing Files

• To remove the file

Command : git rm filename

• To remove the file from staged area

Command : git rm -- cached filename

Moving Files

• The metadata stored in Git does not tell you whether the file is
renamed.
• To rename a file in Git:
Command : git mv file_from file_to
Viewing the commit
history

• To view the commit history

Command : git log
• To view the difference introduced in each commit
Command : git log p
• To limit the output for last two entries
Command : git log p -2€
Changing Your Last Commit
• To change the last commit (if we forgot to add any file)
Command : git commit –amend
This will take the file to the staging area and use it for commit
Example:
git commit –m ‘comments’ // Record changes to the repository
git add filename // Realize, you forgot to add the file
git commit –amend // Record changes to the repository with newly
added file
Unstaging and Unmodifying

• To make the Staged file to a Unstaged file

Command : git reset HEAD filename

• To make the Modified file to an unmodified file

Command : git checkout filename

Working with remotes

• To push our code to the remote server (actual git repository)

Command : git push origin branchname

• To pull the code from the remote server (actual git repository)

Command : git pull

• To get the newly created branches in our local repository

Command : git fetch

Branching

• To create a branch in local repository

Command : git checkout –b branchname

• To delete a branch in local repository

Command : git branch –d branchname

Merging the
branch
• Merging brings two lines of development together while preserving
the ancestry of each commit history.
Command : git merge branchname
git checkout devel // Switch to devel branch in local repository
git pull // Pull the latest code of devel from remote repository
git merge hotfix // Merge the hotfix branch into devel branch present
in the local repository
git push origin devel // Merged devel branch is pushed to the remote repository
Example for Merging the
branch
Rebasing the
branch

• Rebasing unifies the lines of development by rewriting changes from

the source branch so that they appear as children of the destination
branch
Command : git rebase branchname
git checkout devel // Switch to devel branch in local repository
git pull // Pull the latest code of devel from remote repository
git rebase hotfix // Get the hotfix branch changes to the devel branch
present in the local repository
git push origin devel // Rebased devel branch is pushed to the remote
repository
Example for Rebasing a
branch
Git BRANCHING

• Branching means diverging from the main line of development and

continue to do work without messing with that line.
Git BRANCHING

• Command for branching:

- git branch
For Creating new branch:
- git branch develop
In the above command develop is the new branch. Once the command
got executed the develop branch will get created.
Now, we have switch from the master branch to the newly created
branch develop.
Git BRANCHING

• Switching Branches
- git checkout develop
Here, git checkout command is used for switching from one branch to
another branch.
Creating and Switching Branches at Same Time:
- git branch – b release
The above command create a new branch called release and same the
command will also switch to the newly create branch release.
BASIC BRANCHING

• Steps for branching and merging with a workflow that might be used
in the real world:
1.Do some work on a website.
2. Create a branch for working on a new user story.
3. Do some work in that branch.
• To solve a critical issue by hotfix, following steps will be followed
1 Switch to production branch
2 Create a branch to add the hotfix
3 After it’s tested, merge the hotfix branch, and push to production
4 Switch back to your original user story and continue working
MERGING BRANCHES

• To merge the release branch with master branch, check out the
branch and then run the git merge command:
- git checkout master
- git merge release
Now, the changes made in the release will get changed in master
branch.
BRANCH MANAGEMENT

• $git branch v
• The useful merged and no merged options can filter this list to
branches merged into the current branch To see which branches are
already merged into the Branch run the following command:
• $git branch merged
• To see all the branches that contain work not yet merged, run the
following command:
• $git branch no merged
BRANCH MANAGEMENT

• To delete it with git branch d will fail

• $git branch d testing
• To forcefully delete it, run the following
• $git branch D testing
• To chat what is not merged into the master branch?
• $git checkout testing
• $git branch no merged master
CHANGING A BRANCH NAME
• Rename the branch locally with the git branch –move command:
• $git branch –move bad-branch-name corrected-branch-name
• This replaces your bad-branch-name with corrected-branch-name, but this change
is only locally.
• To let others see the corrected branch on the remote, push it:
• $git push --set-upstream origin corrected-branch-name
• Now we’ll take a brief look at where we are now:
• $git branch --all
• *corrected-branch-name
• Main
• Thebranchwiththebadnameisalsostillpresenttherebutdeleteitbyexecutingthefollowin
gcommand:
• $git push origin –delete bad-branch-name
CHANGING THE MASTER BRANCH NAME

• Changing the name of a branch like master/main/mainline/default

will break the integrations, services, helper utilities and build/release
scripts that the repository uses.
• Rename local master branch into main with the following command:
• $git branch --move master main
• To let others see the new main branch, push it to the remote This
makes the renamed branch available on the remote
• $git push --set-upstream origin main
CHANGING THE MASTER BRANCH NAME

• Now we end up with the following state:

• $git branch --all
• *main
• remotes/origin/HEAD -> origin/master
• remotes/origin/main
• remotes/origin/master
• After confirming that the main branch performs just as the
master branch, delete the master branch by the following:
• $git push origin –delete master
GIT BRANCHING WORKFLOWS

Long Running Branches

•In Github one can merge one branch with another multiple times
•Many Git developers have a workflow, having only code that is
stable in the master branch. (The code that will be released)
•Another parallel branch named develop or next which they work
or test stability Whenever the branch gets stable it will be merged
with the master branch
GIT BRANCHING WORKFLOWS

Long Running Branches

•This process can be iterated till stability
•Some larger projects have proposed branch that has integrated
branches that may be ready to go into the next or master branch.
•The idea is that your branches are at various levels of stability
•When they reach the more stable level they are merged to the
master branch.
GIT BRANCHING WORKFLOWS
GIT BRANCHING WORKFLOWS

Topic Branches

•Topic Branches are used in projects of any size

•It is a short lived branch that you create and use for a single
particular feature or related work But work, create, merge and delete
is something very common in github
•Once the branch is merged to the master branch the branch can be
deleted This technique allows you to context-switch quickly and
completely
•As your work is separated into silos where all the changes in that
branch have to do with that topic and easier to see what has
happened during code review
•You can merge files into the master branch whenever you want
regardless of the day and time it had been created.
GIT BRANCHING WORKFLOWS
REBASING
• In Git, there are two main ways to integrate changes from one
branch into another. – The merge and The Rebase
The Basic Rebase:
• It merges C3 and C4 to commit C2
REBASING

The Rebase:
•Another methodology is take a patch of the change that was
introduced in C4 and reapply it on top of C3. It Git, this is called
Rebasing.
REBASING

The Rebase:
•In the following figure we can see the changes rebased in C3 and
C4 is introduced into the master file
•At this point we can go to the master and do a fast forward merge
Examining the log of a rebased branch, it looks like a linear history.
•It appears that all the work happened in series, even when it
originally happened in parallel.
•Rebasing replays changes from one line of work onto another in the
order they were introduced, whereas merging
•takes the endpoints and merges them together.
REBASING

Dangers in Rebasing

•Do not rebase commits that exists outside your repository and that
people may have based work on.

•If you push commits somewhere and others pull them down and
base work on them, and then your rewrite those commits with git
rebase and push them up again, your collaborators will have to
remerge their work and things will get messy when you try to pull
their work back into yours.