Introduction to git, a version control system

Prepared by – Kumaresh Chandra Baruri
Software Engineer

 VCS is software tools that help software teams manage changes to source code over
time.
 It allows software teams work faster and smarter.
 VCS keeps track of every modification to the code in a special kind of database.
 Developers can turn back the clock and compare earlier versions of the code.
Version control system(VCS), also known as source control, is
the practice of tracking and managing changes to software code.

A distributed version control system (DVCS) brings a local copy of the
complete repository to every team member's computer, so they can
commit, branch, and merge locally.

■ Each developer has a complete, local repository.
■ Technically the central repository is not different from the local
repositories.
■ Easy to offline usage.
■ Easy to branch a project.
Examples: Git, Mercurial, Bazaar

Main features of git is-
 A DevOps tool used for source code management.
 Used to tracking changes in the source code.
 Enabling multiple developers to work together on non-linear development using
thousands of branches.
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.

Git repository is like a data structure used by VCS to store metadata
for a set of files and directories. .git folder inside a project represents
a git repository.
There are two ways to obtain repository in the development PC-
1. Create a local repository and make it as Git repository.
Command: git init
2. Clone a remote repository (already exists on a server).
Command: git clone <Repository URL>

■ A Git repository has at most one working
tree.
■ Calculator is the project name.
■ Repository: .git folder which contains full
version of the project DB. Some of the files
are human readable.
■ Source codes: src folder

There are two types of repository.
files/folders next to the
.git folder are the
working tree
.git folder is the
Git repository Non-bare repository -
where working tree is
present.

.git folder is the
Git repository
Bare repository - where
working tree is not present.

Git branch is a pointer to a snapshot of the changes made by the
developer.
A new branch is derived when-
• A new feature is implemented.
•A bug is fixed.

master  What is currently in production.
staging contains the code that is being tested before going to
production.
testing source codes ready for testing. Testable build will be
prepared from here.
develop active development environment. Developer will create
pull request by targeting this branch.
feature currently being developed feature. Individual developer
will be working on this. From here, pull request will be created. After
completing the development, the branch will be deleted.

Initial
branch/
target
commit
Feature
Branch
Working
Tree
Staging
/Index Area
Modification in files
Send target files
to staging area
Commit and
push to repo

<working tree>
git checkout
1. git checkout branch name
populates the working tree with the latest commit of the
selected branch to start working from
2. git checkout -b ＜new-branch＞
populates the working tree of the new branch with the
latest commit of the current branch.
3. git checkout -b <new_branch_name> <SHA1>
populates the working tree of the new branch with
<SHA1>.

<working tree>
Modification can be happened on the following contexts:
■ Modify, add, delete files
■ No need to tell Git which files you want to work on
■ Just tell Git which changes you intend to commit:
a) git add <file>: Add file by name
b) git rm <file>: Remove file
c) Git add * : Add all file etc.

<working tree>
git add <file-name>
Index or Staging Area is where the next commit is
prepared to push in repo:
■ git add and git rm update the index
■ Stage single hunks:
git add -p <file> : Add file to staging
area by name.
■ Unstage files:
git reset HEAD <file>
■ Git add * : Add all the files to staging area.

<working tree>
.git
git commit
 git commit commits staged changes only (the index).
Then, the file(s) is ready to push in repo.
 There can still be non-staged changes in the working
tree which will not be included into the commit.

<working tree>
.git
commit that was
checked out (HEAD)
git diff --staged
git diff
git diff HEAD
■ git status shows changed paths
○ between index and commit that was checked out (HEAD)
○ between working tree and index
■ git diff shows file modifications
○ details on next slide

A commit is kind of 'object' in git, and identifies and specifies a 'snapshot'
of the branch at the time of the commit.
Commit #01
A
B
C
A project consists of 3 files named –
1. A
2. B
3. C
These files are pushed to repo by 1st commit.

Commit 01
A
B
C
Commit 02
A1
B
C1
Commit 03
A1
time
■ Each and every individual commit is a
full snapshot of the whole project.
■ Commit 02 modified file A  A1 and
C C1.
■ Commit 3 modified C1 C2.
■ Git does not copies non modified file in
snapshot. Like- B is not changed in 2nd
commit, B amd A1 is not changed in
commit 3 and so on.
C2
B

Commit 01
Snapshot 01
Commit 02 Commit 03
time
Snapshot 03 Snapshot 03
Each commit knows its parent.

ID: 78ae51a
Snapshot
Parent: 6709af
Tree: 922b8c
Author:
John Doe
<jdoe@example.com>
Committer:
John Doe
<jdoe@example.com>
Commit Message
...
SHA1:
■ globally unique commit ID
■ 40-digit hexadecimal number
■ function of the commit object content
■ shown in git log output etc.
To inspect a commit use:
■ git show <SHA1>
■ git show --format=fuller <SHA1>
Once created commits are immutable.

■ Git sets author and committer based
on the user.name and user.email
config values.
■ Author can be explicitly set on
commit:
git commit --author=<author>
■ Author:
○ person who wrote the patch
■ Committer:
○ person who created the commit,
e.g. project maintainer who applied the
patch

First line is the subject, should be shorter
than 70 chars
Separate the body from the subject by an empty
line. The commit message should describe why
you are doing the change. That's what typically
helps best to understand what the change is
about. The details of what you changed are
visible from the file diffs.
The body can have as many paragraphs as you
want. Lines shouldn't exceed 80 chars. This
helps command line tools to render it nicely.
Paragraphs are separated by empty lines.
Bug: Issue #123
1. First line is the subject.
2. Separated by a blank line follows the
body.
3. The last paragraph is for metadata (key-
value pairs). The metadata is intended to
be interpreted by tools.

C
B
A
time
■ C is a successor of B
■ B is a successor of A
■ The lines between the commits represent parent
relationships, the arrows for parent relations are omitted.
■ Can be seen by:
○ git log (with file diffs)
○ git log --oneline (with subject only)
○ git log --graph (as graph)
○ gitk (as graph in Git repository browser)

G
B
A
feature2
C
feature
1
D
E
F
origin/master
bugfix10
master
HEAD
HEAD points to the current branch:
■ git commit updates the current branch
■ git checkout sets the current branch

G
B
A
feature
2
C
feature
1
D
E
F
origin/master
bugfix10
master
HEAD
HEAD
git checkout:
■ moves HEAD to newly
checked out branch .
■ also updates the working tree

■ a working tree with modifications is called dirty
■ a working tree without modifications is called clean
■ git stash puts changes in a dirty working tree
aside, with git stash pop they can be applied
somewhere else (more about conflict resolution
later)
If you started to make changes to the working tree
but the wrong branch is checked-out:
■ just try to checkout the correct branch, if there
are no conflicts this will just work
■ if there are conflicts the checkout fails,
in this case you can do:
$ git stash
$ git checkout <correct-branch>
$ git stash pop
$ <resolve conflicts>
$ git stash drop

C
B
A
D
master
HEAD git commit --amend rewrites the last commit:
■ creates a sibling commit D of the last commit
C and resets the current branch to it
■ the old commit message is preserved, but
can be edited if wanted
■ the old commit C is still available in the
repository
■ rewrites the history of the branch (you should
never rewrite commits that have already
been shared with others, since others may
already have used it as base for other work)
master
Add additional
changes to an
existing commit.

C
B
A
D
master
HEAD
Branches can be reset manually
git reset

git reset branch index working tree
--soft Yes No No
--mixed (default) Yes Yes No
--hard Yes Yes Yes
The branch is always reset, whether the
index and working tree are reset depends
on the reset mode (soft, mixed, hard).
With git reset --hard local
modifications in the working tree are lost.
■ git reset --hard:
Discard all local modifications.
■ git reset --soft:
Squash commits.
■ git reset --mixed:
Split commits.

C
B
A
D
master
HEAD
master
git reset B
git reset B
■ Updates the current branch to point to
commit B.
■ Commit C and D are no longer part of the
history of the master branch.
■ D and C are non-reachable.

C
B
A
D
master
Non-reachable commits
■ are by default kept for 2 weeks
■ are garbage collected after the expiry time has
passed and when
git gc is run
■ Can be checked out by SHA1.
HEAD

C
B
A
D
HEAD
master
If HEAD points directly to a commit (instead of
pointing to a branch) it’s called detached HEAD.
HEAD
HEAD
Detached

C
B
A
D
HEAD
master
New commits can be created even if HEAD is detached:
■ If you checkout something else now the new commit
gets unreachable (but you may still access it if you
know its SHA1).
HEAD
E
New commit
on Detached
HEAD

A tag allows to tag a specific point in the version
history:
■ normally used to tag important versions such as
releases
■ in contrast to branches tags are immutable (well
you can delete and recreate tags, but you really
should not do this once they have been shared with
others)
■ example: v1.0.0
■ full name: refs/tags/v1.0.0
B
A
C
stable-1.0
E
F
D
master
HEAD
v1.0.0
v1.0.1

There are 3 kind of tags:
■ lightweight tags (just a pointer to a commit)
■ annotated tags (full Git object, allows tags to have a
message)
■ signed tags (tag with signature)
Tag creation:
■ git tag <tagname>
■ git tag -a <tagname>
■ git tag -s <tagname>
List tags:
■ git tag
B
A
C
stable-1.0
E
F
D
master
HEAD
v1.0.0
v1.0.1

git fetch
 fetches new commits
 updates the remote tracking
branches
 never updates local branches
 never changes the working tree
 is always safe to do
 FETCH_HEAD points to the commit
that was fetched last
B
A
C
stable-1.0
E
F
D
master
HEAD
remote repository local repository
B
A
C
origin/stable-1.0
E
F
D
master
HEAD
origin/master
G G FETCH_HEAD
Used to download contents from a remote repository.

C
B
A
D
master
HEAD
E
F Feature_login
Merging
feature_login
to master
Git merging combines sequences of commits into one unified history of commits.

C
B
A
D
E
F feature_login
G
master
HEAD
master
git merge feature_login:
■ Merges feature_login into the current
branch (master).
■ Creates a merge commit (commit with
more than one parent).
■ The current branch is updated.

Cherry-pick enables arbitrary Git commits to be picked by reference and appended to the current
working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to
another. git cherry-pick can be useful for undoing changes
C
B
A
D
master
HEAD
E
F featureX
Here,
■ commit E implements a feature
■ commit F is bug-fix
■ the bug-fix F is needed in master

C
B
A
D
E
F featureX
Cherry-Pick:
■ Applies the modifications that were done by the commit
that is cherry-picked (the commit delta) to a new base.
■ The commit message is preserved.
■ The new commit has no parent relation to the commit
that was cherry-picked.
■ The cherry-pick can fail with conflicts. The conflict
resolution is done the same way as for conflicts on
merge.
G
master
HEAD
∆F
∆F
∆E

Rebasing is the process of moving or combining a sequence of commits to a
new base commit
Rebase:
■ redo the work that was done in the
featureX branch on top of the master
branch
C
B
A
D
master
HEAD
E
F featureX

Rebase:
■ rebases the current branch to a another base commit
■ rebase = series of cherry-picks
■ git rebase master rebases all commits of the
featureX branch (which is currently checked out) onto
the master branch.
■ the commit messages are preserved
■ the history of the featureX branch is rewritten, this is
bad if the featureX branch is shared and others have
based work on top of it
■ the old commits E and F still exist in the repository
■ after the rebase a fast-forward of master is possible
■ Linear history
■ ORIG_HEAD points to the old HEAD
C
B
A
D
master
E
F featureX
HEAD
G
H featureX
∆F
∆E
∆F
∆E
ORIG_HE
AD

Push:
■ pushes commits from the local repository to a
remote repository (more precisely from a local
branch to a remote branch)
■ git push origin HEAD:master
is equivalent to
git push origin
HEAD:refs/heads/master
■ git push origin master
is equivalent to
git push origin
refs/heads/master:refs/heads/master
git push origin HEAD:master
Name of remote
repository to which the
push is done.
What’s pushed to the
remote repository
(branch, commit, HEAD =
current branch).
Destination in the remote
repository (target
branch).

Situation:
■ The remote repository was
cloned, a local featureX
branch was created and in this
branch a commit C was created.
B
A
featureX C
HEAD
local repository remote repository
B
A
master
origin/master

Push:
■ pushes commit C to the remote repository
■ updates the master branch in the remote
repository
■ The local branch name is never
transferred to the remote repository.
B
A
featureX C
HEAD
B
A
master
origin/master
C
master
When Pushed

B
A
featureX
C
HEAD
B
A
origin/master
D
Push:
■ pushes all commits which are
reachable from the pushed commit
and which are not available in the
remote repository
C
D
master
master

Situation:
■ The remote repository was
cloned, a local featureX branch
was created and in this branch a
commit C was created. In the
meantime master in the remote
repository was updated to
commit D.
B
A
featureX C
HEAD
B
A
master
origin/master
D
When Pushed

git push fails if the target branch
cannot be fast-forwarded to the
pushed commit.
B
A
featureX C
HEAD
B
A
master
origin/master
D

Force push:
■ Makes the push succeed even if the target
branch cannot be fast-forwarded.
■ The target branch is updated to the pushed
commit, conflicting commits are removed
from the history of the target branch!
■ After the force push commit D is no longer
contained in the history of the master
branch.
B
A
featureX C
HEAD
B
A
master
origin/master
D
git push --force origin HEAD:master
C
master

Pull:
■ git pull can be configured to do
git fetch +
git rebase instead (config parameter pull.rebase=true)
git pull = git fetch + git merge FETCH_HEAD
Pull is used to fetch and download content from a remote repository and immediately update the local
repository to match that content

1. https://www.simplilearn.com/tutorials/git-tutorial/what-is-git
2. https://www.atlassian.com/git/tutorials/what-is-version-control
3. https://www.geeksforgeeks.org/what-is-a-git-repository/
4. https://www.slideshare.net/kumareshbaruri/git-branching-policy-and-review-comments-prefix-246339744
5. https://www.atlassian.com/git/tutorials/syncing/git-
pull#:~:text=The%20git%20pull%20command%20is,Git%2Dbased%20collaboration%20work%20flows.

Introduction to git, a version control system

Introduction to git, a version control system

Recommended

Recommended

More Related Content

Similar to Introduction to git, a version control system

Similar to Introduction to git, a version control system (20)

More from Kumaresh Chandra Baruri

More from Kumaresh Chandra Baruri (10)

Recently uploaded

Recently uploaded (20)

Introduction to git, a version control system