Git for Developers

Duration: 1 Day

Training Plan

Course Duration

● approx. 8 Hours (1 days) Approx.

Prerequisites

• A foundational understanding of IT infrastructure

• Basic knowledge about Software Development Life Cycle

• Internet with basic infrastructure to work

• Basic understanding of linux/unix system concepts (for learning from linux)

• Familiarity with Command Line Interface (CLI)

• Familiarity with a Text Editor

Learning outcomes

● Learn Git

● Become ready to use Git in development projects

What is Git?

Reference

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

##############################################################################

What is Git?

• Introduction to version control

System that records changes to a

file or

set of files

Allows to control/monitor/manage/share/recover files and filesystems.

Example of Control

Who can see

Private repo/Public repo.

Who can merge?

Example of manage

revert selected files back to a previous state

revert the entire project back to a previous state

compare changes over time

see who last modified something that might be causing a problem

who introduced an issue and when

Example of monitor

What changes you made to your local filesystems

What change was made in the central repo.

Example of share/recover

Local Version Control Systems

-----------------------------

Preliminary method.

Copy files into another directory

perhaps a time-stamped directory.

Simple

Error prone

Lot of manual dependency

Local VCSs

Had a simple database

Recorded all changes to files under revision control.

RCS

Revision Control System

A popular Local VCS

Still distributed with many computers today.

Delta between files in a special format on disk

Can compute what any file looked like at any point in time by adding up all the patches.

https://www.gnu.org/software/rcs/

Centralized Version Control Systems

-----------------------------------

VCS need to collaborate with developers on other systems.

Centralized Version Control Systems (CVCSs)

deal with this problem

E.g.

CVS,

Subversion, and

Perforce

Have a single server that

Contains all the versioned files

Multiple clients can check out files from that central place.

Was the most popular until git.

Adv.

Much better than local VCSs.

For example, supports sharing code between engineers.

Very good support for access control

Easier to administer a CVCS compared local databases on every client.

Disadvantage

Single point of failure.

Even short downtime affects collaboration.

History/Collaboration etc. all focused at a single unit.

Distributed Version Control Systems

-----------------------------------

E.g.

Git,

Mercurial,

Bazaar or

Darcs)

More on this latter

##############################################################################

• The history of Git

In 2005

Linux kernel dev. team and the BitKeeper dev. company broke relationship

Bitkeeper free-of-charge status was revoked.

Linux development community (and in particular Linus Torvalds, the creator of Linux)

developed their own tool

Some of the goals of the new system were as follows:

Speed

Simple design

Strong support for non-linear development (thousands of parallel branches)

Fully distributed

Able to handle large projects like the Linux kernel efficiently (speed and data size)

##############################################################################

• About distributed version control

# Internals of Git

Git is a decentralized VCS

In centralized VCS

the database resides on a central server

you checkout a copy from the server.

Most of the commands require you to contact the central database

hence require network access.

In a decentralized or distributed VCS (like git)

each and every node has a copy of the database

hence you clone a copy from a remote server.

Remote server has

no special permissions

except all the nodes have access to the remote server.

So all commands in git (except git push or git pull)

can be performed without network access.

When you

clone a git repository(git clone)

or

git init

creates a .git folder at the root of the repository.

This is where git stores all the data.

Clients don’t just check out the latest snapshot of the files;

Client fully mirror the repository, including its full history.

If any server dies

clients 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.

Clone at the time of cloning.

Generally these systems deal pretty well with having several remote repositories they can work with

So you can collaborate with different groups of people in different ways simultaneously within the same project.

What is Git

-----------

Git is 1.6 times faster than it's nearest rival.

Snapshots, Not Differences

--------------------------

The major difference between Git and any other VCS (e.g. Subversion)

the way Git thinks about its data.

Most other systems store information as a list of file-based changes.

These other systems (CVS, Subversion, Perforce, Bazaar, and so on)

consider information they store as a set of files

changes made to each file over time

described as delta-based version control.

Git doesn’t think of or store its data this way.

Git thinks of its data more like a series of snapshots of a miniature filesystem.

Snapshots are like taking a photo of the repo. at the given point in time.

Stores a reference to that snapshot.

To be efficient,

Git store only the changed files

Others it links to the previous identical file it has already stored.

Git thinks about its data more like a stream of snapshots.

Refer image

https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

So what?

1. Almost all Operation are Local

(except push and pull - among the most used)

Most operations in Git need only local files and resources to operate

Generally no information is needed from another computer on your network.

Every operation is very fast.

Entire history of the project available on your local disk

Most operations seem almost instantaneous.

e.g., See history of the project,

Git doesn’t need to go out to the server

Reads it directly from your local database.

See project history almost instantly.

To find delta between current and a month old version of a file,

Git can look up the file a month ago

do a local difference calculation,

2. No network connectivity required

Except for very few everything you can do offline.

This is not the case with most of it's competitors.

3. Git Has Integrity

Everything in Git is checksummed before it is stored

Latter referred to by that checksum.

So Git knows about any change you make to the filesystem.

Built into Git at the lowest levels

Integral to its philosophy.

Can’t lose information in transit

Get file corrupted without Git being able to detect it.

checksum

Git uses SHA-1 hashing for this.

This is a 40-character string composed of hexadecimal characters (0–9 and a–f)

Calculated based on the contents of a file or directory structure in Git.

A SHA-1 hash looks something like this:

24b9da6552252987aa493b52f8696cd6d3b00373

Git stores everything in its filesystem

not by file name

but by the hash value of its contents.

So this hash is represented everywhere in git.

4. Git Generally Only Adds Data

Almost all actions in Git,

only add data to the Git database.

is undoable

But cannot erase traces in any way.

Once committed, we should be able to get to it.

We can lose or mess up changes you haven’t committed yet

So we can experiment without the danger screwing things up.

The Three States

----------------

Reference to the image in

https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

Three states

modified

Updated a tracked file but have not committed it to your database yet.

staged

Like staging for production.

current version of modified file moving to next level.

Ready to go to commit.

committed

Data is safely stored in your local database.

Three main logical areas of a Git project:

the working tree,

the staging area

Git directory.

Working Tree

------------

Single checkout of one version of the project.

Files pulled out of the compressed database in the Git directory

placed on disk for you to use or modify.

The staging area

It'sa file

contained in your Git directory

stores information about what will go into your next commit.

Technical name in Git parlance is “index”

“staging area” is equally accepted.

Git(.git) directory

Git stores the metadata and object database for your project.

Most important part of Git

This is copied when you clone a repository from another computer.

The basic Git workflow

Modify files in your working tree.

Selectively stage just those changes you want to be part of your next commit

Adds only those changes to the staging area.

Do a commit,

takes the files as they are in the staging area

stores that snapshot permanently to your Git directory.

If a particular version of a file is in the Git directory, it’s committed.

If it has been modified and was added to the staging area, it is staged.

Updated since it was checked out but has not been staged

it is modified.

-------------------------------------------------

Reference: https://www.daolf.com/posts/git-series-part-1/

Here is what’s your .git will look like before your first commit:

├── HEAD

├── branches

├── config

├── description

├── hooks

│ ├── pre-commit.sample

│ ├── pre-push.sample

│ └── ...

├── info

│ └── exclude

├── objects

│ ├── info

│ └── pack

└── refs

├── heads

└── tags

branches directory isn’t used by newer Git versions.

HEAD

stores where the HEAD points to.. More on this latter.

config

Contains the settings for your repository

e.g.

url of the remote

your mail,

username

Every-time you use ‘git config …’ in the console it ends here.

description

Used by gitweb (an ancestor of github) to display the description of the repo.

hooks

Git comes with a set of script

Script can automatically run at every meaningful git phase.

called hooks

Can be run before/after a commit/rebase/pull…

Name of the script: explain when to execute it.

E.g. useful pre-push hook

test that all the styling rules are respected to keep consistency in the remote.

index

file is where Git stores your staging area information.

info —

exclude

Can put the files you don’t want git to deal with in your .gitignore file.

Exclude file is the same

Except that it won’t be shared.

If you don’t want to track your custom IDE related config files

Not through .gitignore

(do two commit's to the same file .. watch objects folder step by step)

Add a file called file_1.txt -

git add *

A new folder is created.

cd /<git root folder>/.git/<number>

git commit -m "comments"

That creates another two folders

What’s inside a commit ?

Every-time you create a file, and track it,

git

compresses it

stores it into its own data structure.

Compressed object will have

a unique name

a hash

will be stored under the object directory.

And once that snapshot is created,

it will also be compressed

name with an hash

all compressed objects are stored in object folder.

Contents of the objects directory after creating an empty file and committing.

── 4c

│ └── f44f1e3fe4fb7f8aa42138c324f63f5ac85828 // hash

├── 86

│ └── 550c31847e518e1927f95991c949fc14efc711 // hash

├── dd

│ └── e4f5e818d517ba8ea51e18d255f57062035a7c // hash

├── info // let's ignore that

└── pack // let's ignore that too

Commit

(snapshot of your working directory)++.

you commit

git does two things - to create the snapshot of your working directory:

1. If the file didn’t change

git just adds the name of the compressed file (the hash) into the snapshot.

2. If the file has changed,

git compresses it

stores the compressed file in the object folder.

Adds the name (the hash) of this compressed file into the snapshot.

Above tree

If the hash of your file = “4cf44f1e…”

git will store this file under a “4c” subdirectory

name the file “f44f1…”.

A small trick

size of the /objects directory/reduces by 255 the .

Notice 3 hash.

One hash: for my file_1.txt

Second hash: for the snapshot created when I commited.

Third hash:

Commit is an object in itself

It is also compressed and stored in the object folder.

Commit is made of 4 things :

The name (a hash) of the working directory’s snapshot

A comment

Commiter/Author information

Hash of the parent commit

And that’s it, look by yourself what happen if we uncompressed the commit file :

// by looking at the history you can easily find your commit hash

// you also don't have to paste the whole hash, only enough

// characters to make the hash unique

git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828 #foldername + filename

-------------------------------------------------------

Actual o/p copied from my machine.

tree dde4f5e818d517ba8ea51e18d255f57062035a7c

author vilasvarghese <vilas.varghese@gmail.com> 1621305337 +0530

committer vilasvarghese <vilas.varghese@gmail.com> 1621305337 +0530

test

D:\temp\test\.git\objects\4c>cd ../dd

D:\temp\test\.git\objects\dd>git cat-file -p dde4f5e818d517ba8ea51e18d255f57062035a7c

100644 blob 27206866b5792a330d1df923916c5a49e7927e3c test1.txt

-------------------------------------------------------

Output includes,

the snapshot hash,

the author,

and my commit message.

Two things are important here :

1. As expected, the snapshot hash “dde4f5…” is also an object and can be found in the object folder.

2. Because it was my first commit, there is no parent.

What’s in my snapshot for real ?

git cat-file -p dde4f5e818d517ba8ea51e18d255f57062035a7c

100644 blob 27206866b5792a330d1df923916c5a49e7927e3c test1.txt

And here we find the last object that was previously in our object store

#branch, tags, HEAD all the same

--------------------------------

So everything in git can be reached with the correct hash.

Let’s take understand HEAD now.

cat HEAD

ref: refs/heads/master

not an hash

HEAD can be considered as a pointer to the tip of the branch you’re working on.

And now if we look at what is in refs/heads/master here what we’ll see :

cat refs/heads/master

4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

This is the exact same hash of our first commit.

So branches and tags are

Pointer to a commit.

Nothing more than that

Delete

all the branches

all the tags

the commit they were pointing to are still going to be here.

Further details: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Summary

All that git does when you commit is

“zipping” your current working directory

storing it into the objects folder

with a bunch of other information.

But git commit can be committing specific files.

So commit isn’t really a snapshot of your working directory

it is a snapshot of the files you want to commit.

Git stores files into the index file.

Launches the actual commit from there.

#Git Refs

---------

Ref's directory includes

heads

remotes

tags

Git Head

containing the SHA-1 hash of the latest commit in that repository.

where your current tip is pointing.

The HEAD file is a symbolic reference to the branch you’re currently on.

By symbolic reference

it doesn’t generally contain a SHA-1 hash

instead pointer to another reference.

vi .git/HEAD

Remote

Add a remote

push to it

Git stores the SHA-1 value you last pushed to that remote for each branch in the refs/remotes directory.

Tags

tag folder

has references to a tag object.

A tag object is very much like a commit object

it contains a tagger,

a date,

a message,

and a pointer.

The main difference

tag object generally points to a commit rather than a tree.

It’s like a branch reference, but it never moves

it always points to the same commit but gives it a friendlier name.

Other references

http://git-scm.com/book/en/v2/

http://slidetocode.com/2013/08/25/how-git-works/

##############################################################################

• Who should use Git?

##############################################################################

Installing Git

##############################################################################

• Installing Git on Windows

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

https://www.linode.com/docs/development/version-control/how-to-install-git-on-linux-mac-and-windows/

##############################################################################

• Installing Git on Linux

##############################################################################

• Installing Git on a Mac

https://www.atlassian.com/git/tutorials/install-git#mac-os-x

##############################################################################

• Configuring Git

git config --global user.name "vilasvarghese"

git config --global user.email "vilas@vilas.com"

##############################################################################

• Exploring Git auto-completion

https://medium.com/@yannmjl/how-to-set-up-auto-complete-for-git-commands-on-windows-cmd-exe-687424d2f142

https://pagepro.co/blog/autocomplete-git-commands-and-branch-names-in-terminal/

##############################################################################

• Using Git help

To get help there are three equivalent ways:

$ git help <verb>

$ git <verb> --help

$ man git-<verb>

For example, you can get the manpage help for the git config command by running this:

$ git help config

These commands works offline.

For concise “help” use -h option, as in:

git add -h

##############################################################################

Getting Started

• Initializing a repository

mkdir demo

cd demo

ls -a

git status

#Convert the folder to a git repo.

git init

ls

ls -a

- .git folder would be present.

cd .git

More on this folder latter.

cd objects (.git/objects)

ls

objects

pack

However these are empty.

Create

Abc.txt

Xyz.txt

ls -a

Go back and check .git/objects folder

No new folder

git status

Adding a file to staging area

git add Abc.txt

Go back and check .git/objects folder

New folder created with hash.

git status

Notice add files and untracked files.

Commit

git commit -m "Learn git commit"

Go back and check .git/objects folder

New folders created with hash.

##############################################################################

• Understanding where Git files are stored

https://www.toolsqa.com/git/dot-git-folder/

.git folder is required to

Log every commit history

Every other information required for your

remote repository,

version control,

commits etc.

ls -a .git

They will look probably like this:

Folder

Hooks

Info

Objects

refs

Files

Config

Description

HEAD

Hooks folder in the Dot Git Folder (.git)

-----------------------------------------

Has few script files.

known as Git Hook Scripts.

Git hooks

scripts that are executed before or after the events.

events: any Git event including the common Git events like

commit,

push or

receive.

increase the productivity of the developer.

pre-commit script

executed before executing the commit event.

E.g. checking the spelling errors etc.

post-commit script

executed after the commit is done.

These scripts can be updated to customize validtiion.

This is very very rare.

When you have multiple repositories.

Info folder in the Dot Git Folder (.git)

----------------------------------------

Info folder contains the exclude file inside it.

exclude file (Not .gitignore)

exclude certain pattern of files from Git to read or execute.

This file is local and personal to you

Not shared among the developers that clone your project.

If all developers in the project needs to ignore,

use .gitignore.

Objects folder in Dot Git Folder (.git)

----------------------------------------

Everything is saved in objects folder as a hash value.

commit,

every tree or

every file that you create

is saved in this directory.

With every object,

there is a hash value linked to it,

through which Git knows where is what.

The folders are created accordingly.

--------------------------------------------------------------------------------------------------------

ls .git/objects

These contain the hash value of the events you just did.

Git tracks and recognizes everything by converting it to the hash value.

The folders are named according to the hash value saved inside.

Talking in layman’s terms, hashing is a popular method (data structure) of converting your data to hash value (random combinations of letters and digits) which is only decodable by trusted sources. Due to its nature, hashing is today used most popularly in security measures. But in Git it is not used mainly as a security feature. Hashing in Git is used to be able to trust and create stable data where collision does not occur which means two same files can be saved because they will have different hash values. Hash acts as a medium for having your data in a form which can be converted and used to any other technology in the future. Since hashing acts as a mediocre, we can anytime create technologies that take input as the hash value and not the source code files. This way, the code you save today can also be viewed years later due to this feature of Git. Go to the folders and see the hash value has been created.

--------------------------------------------------------------------------------------------------------

Config Folder in Dot Git Folder (.git)

--------------------------------------

The config file contains your configuration.

Configuration you set for e.g.

username,

email, etc.

for your project is saved permanently in this folder.

You can modify it once you set them but you don’t need to do it generally.

Once you edit the configuration setting, they are saved permanently.

You can view them by typing this command:

vi ~/.gitconfig

https://www.toolsqa.com/git/dot-git-folder/

https://www.toolsqa.com/git/set-up-default-credentials-for-git-config/

More on this latter.

Description File in Dot Git Folder

----------------------------------

Description contains the data about the repositories which can be seen on GitWeb only.

This file is none of a programmer’s use.

It is just for seeing the repositories on GitWeb.

HEAD File in Dot Git Folder (.git)

----------------------------------

Head file

contains the reference to the branch we are currently working on.

Symbolic reference to the branch

Not the normal reference.

Normal reference contains the Hash value as we saw in the above Objects folder.

But this is in plain text.

It refers to something directly like pointers in programming.

A symbolic reference is a reference to another normal reference.

It means that the symbolic reference will refer to a normal reference

and as learned, that normal reference will be referring to the actual value. It is a type of two-step reference. So in this case, Head refers to somewhere else which contains the hash value of the branch we are working on. Note here that head always points out to the last checked out revision. If you have checked out a branch recently, then it will point to the branch. If that revision is a commit, then the head will point to the commit.

MORE DETAILS ON Configuration

-----------------------------

Why to set up Configuration File in Git?

https://www.toolsqa.com/git/set-up-default-credentials-for-git-config/

As we install Git in our system,

the configuration file takes default values for some of the fields.

This means Git starts by setting same files to every user.

Although many of these values are default and are kept that way, but the personal ones should not.

This creates a conflict in the identity of the programmer among the team about which we will see through an example in this section.

Start Git first time,

the common default (across users) files are searched inside the

/etc/gitconfig file.

User specific files are found inside

~/.gitconfig or

~/.config/git/config

file.

The specific file include your username, your name etc.

Setupp default cofig

-----------------------------

git config –global user.name “Your UserName”

git config –global user.email “Your UserName”

List all config

git config --list

View a particular config

git config --global <key>

git config user.name

• Configuring the command prompt to show the branch

Already covered - configure

user.name

user.email

##############################################################################

Merging Branches

“killer feature”

Incredibly lightweight

branching operations nearly instantaneous

Switching back and forth between branches generally just as fast.

Git encourages

workflows that branch and merge often,

even multiple times in a day.

To really understand the way Git does branching, we need to take a step back and examine how Git stores its data.

When you make a commit,

Git stores a commit object

contains a pointer to the snapshot of the content you staged.

This object contains

pointer to the snapshot

the author’s name and email address,

the message

pointers to the commit(s) that came before this commit

zero parents for the initial commit,

one parent for a normal commit,

multiple parents for a commit that results from a merge of two or more branches.

Let’s assume we have a directory containing three files

stage them all and commit.

Staging the files computes a checksum for each one

stores that version of the file in the Git repository

adds that checksum to the staging area:

$ git add test.txt LICENSE

$ git commit -m 'Initial commit'

When you commit

Git checksums each subdirectory

in this case, just the root project directory

stores them as a tree object in the Git repository.

Git then creates a

commit object that has the metadata

pointer to the root project tree

so it can re-create that snapshot when needed.

If you make some changes and commit again,

the next commit stores a pointer to the commit that came immediately before it.

A branch in Git is simply a lightweight movable pointer to one of these commits.

The default branch name in Git is master.

As you start making commits,

you’re given a master branch that points to the last commit you made.

Every time you commit, the master branch pointer moves forward automatically.

Creating a New Branch

---------------------

What happens when you create a new branch?

Well, doing so creates a new pointer for you to move around.

Let’s say you want to create a new branch called testing.

You do this with the git branch command:

$ git branch testing

This creates a new pointer to the same commit you’re currently on.

How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch.

you can easily see this by running a simple git log command that shows you where the branch pointers are pointing. This option is called --decorate.

git log --oneline --decorate

Switching Branches

To switch to an existing branch, you run the git checkout command.

$ git checkout testing

This moves HEAD to point to the testing branch

$ vi test.txt

$ git commit -a -m 'made a change'

The HEAD branch moves forward when a commit is made

This is interesting,

now our testing branch has moved forward,

but your master branch still points to the commit you were on when you ran git checkout to switch branches. Let’s switch back to the master branch:

$ git checkout master

That command did two things.

It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch so you can go in a different direction.

Now your project history has diverged

You created and switched to a branch,

did some work on it, and

then switched back to your main branch and

did other work.

Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready.

And you did all that with simple branch, checkout, and commit commands.

##############################################################################

• Merging code

Let's follow a workflow

Do some work on a website.

Create a branch for a new user story you’re working on.

Do some work in that branch.

At this stage, you’ll receive a call that another issue is critical and you need a hotfix.

You’ll do the following:

Switch to your production branch.

Create a branch to add the hotfix.

After it’s tested, merge the hotfix branch, and push to production.

Switch back to your original user story and continue working.

You’ve are going to resolve the latest bug.

Create a new branch and switch to it at the same time,

you can run the git checkout command with the -b switch:

$ git checkout -b newissue

Switched to a new branch "newissue"

This is shortform for:

$ git branch newissue

$ git checkout newissue

You work on your website and do some commits.

Doing so moves the newissue branch forward, because you have it checked out (that is, your HEAD is pointing to it):

$ vi index.html

git add *

git commit -a -m 'Fix issue'

Now you get the call

there is an issue with the website,

you need to fix it immediately.

With Git,

We don't need to repeat

reverting those changes before you can work on applying your fix to what is in production.

All you have to do is switch back to your master branch.

If your working directory or staging area has uncommitted changes

that conflict with the branch you’re checking out,

Git won’t let you switch branches.

It’s best to have a clean working state when you switch branches.

ways to get around this

stashing

$ git checkout master

Switched to branch 'master'

At this point,

your project working directory is exactly the way it was before you started working on new issue,

when you switch branches,

Git resets your working directory to look like it did the last time you committed on that branch.

Git

adds,

removes, and

modifies files

automatically to ensure working copy is what the branch looked like on your last commit to it.

Next, you have a hotfix to make.

Let’s create a hotfix branch on which to work until it’s completed:

$ git checkout -b hotfix

Switched to a new branch 'hotfix'

$ vi index.html

$ git commit -m 'Fix broken email address'

$ git checkout master

$ git merge hotfix

Notice the phrase “fast-forward” in that merge.

Current commit pointed to by the branch hotfix you merged in was directly ahead of the commit

Git simply moves the pointer forward.

i.e.

when you try to merge one commit with a

commit that can be reached by following the first commit’s history

Git simplifies things by moving the pointer forward

because there is no divergent work to merge together

This is called a “fast-forward.”