Introduction

to Git &
Version
Controlling
Introduction to Version
controlling
 Introduction to Version controlling

What is Version controlling ?

Version control is a system that records

changes done to a file or set of files over
time so that you can recall specific
versions later.
 Introduction to Version controlling

Life without proper Version controlling

 Introduction to Version controlling

Version controlling is most commonly used in software development to manage source

code, but it can be applied to any type of file. Version control systems (VCS) allow
multiple people to collaborate on a project, track changes, and maintain a history of
modifications.

Example version controlling system:

Introduction to Version controlling

Linus Torvalds created Git in 2005.

Torvalds is a Finnish software
engineer who also created the Linux
operating system kernel.

GIT is,
Open Source under GNU general public
license.
Distributed( allows each developer to have a
local copy of the entire repository, enabling
them to work offline and commit changes
independently)
 Introduction to Version controlling

Fundamental GIT concepts,

1. Repository: A database where

the system stores all the
changes and history of the
project.

2. Commit: A snapshot of the changes made to the files in the repository at a

particular point in time.
 Introduction to Version controlling

Fundamental GIT concepts,

3. Branch: A parallel version of the repository, allowing developers to work on

different features or fixes simultaneously without affecting the main
codebase.
 Introduction to Version controlling

Fundamental GIT concepts,

4. Merge: The process of

integrating changes from
one branch into another.

5. Clone: A copy of the

repository that includes the
entire history and all
branches.
 Introduction to Version controlling

Fundamental GIT concepts,

6. Pull: Update the local

repository with changes from
the remote repository (pull).

7. Push: Upload local repository content to a remote repository

 Introduction to Version controlling

Git Vs. GitHub ?????

Git is a distributed version control

system (DVCS) used to track changes
in files and coordinate work among
multiple people. Git operates on your
local computer, and you don’t need an
internet connection to use it.

GitHub is a cloud-based platform built around Git, providing a hosting service for Git
repositories.
Since GitHub is a web-based service, it requires an internet connection to interact
with it. GitHub relies on Git.
 Introduction to Version controlling

Why we need Git & GitHub ?

1. Version Management.
2. Collaboration Challenges (Git allows team members to work in parallel
using branches, GitHub provides a centralized platform where team
members can access, share, and collaborate on code from anywhere.)
3. Accountability and Transparency (Git logs every change with the author's
name, timestamp, and commit message)
4. GitHub acts as a remote backup of the codebase.
5. Code Quality and Reviews (GitHub's pull request system allows team
members to review and discuss changes before they are merged,
improving code quality)
6. Helps to manage projects properly.
Setup GIT
 Setup GIT

https://git-scm.com/
 Setup GIT

Make sure to override the defualt branch name to ‘main ’

 Setup GIT

https://github.com/signup?source=login
 Activity 1
1. Download and install git into your PC.
2. Create a GitHub account(if you don't have a one already).
3. Make sure your github account is secured with multi-factor authentication
methods.
 Setup GIT

Then tell your local git application who you are using these
commands,

git config --global user.name "John Doe"

git config --global user.email "[email protected]"
Ex:

These details will not be used as credentails for account singing/signup

purposes. These are used only for attribution purposes (ex: to associate your
name and email with commits you make).
GIT Basics
 GIT Basics

Working directory -> Git repositrory

Working Directory : Directory(Folder) on your local file system where you
edit and make changes to your project files.

Repository : The Repository is where Git stores all the metadata and object
database for your project. It includes the entire history of your project, all
commits, branches, tags, and configuration.
Repository is typically located in the .git directory within your git directory.
 GIT Basics

git init :
To initialize the working directory to a git repository, we can execute this
command in our working directory,

$ git init
 GIT Basics

git status :
To check the status of the git repo, use this command.

$ git status
 GIT Basics

git add :
git add is used to add our changes to the staging area.
This command tells Git to include these changes in the next snapshot
(commit) you create.
Staging area : An intermediate area where Git stores changes that are ready to
be committed. It acts as a checkpoint between your working directory and the
repository's history.
 GIT Basics

Ways of using git add command,

1. Stage a specific file name 4. Add specific types of changes.
git add <file_name> 4.1 Stage only modified and deleted
ex: git add index.html files (not new files)
2. Stage all changes to the repository. git add -u
git add . 4.2 Stage new and modified files
ex: git add . (not deleted files)
3. Stage all changes in a specific directory git add -A

git add <directory_name> /

ex: git add src /
 GIT Basics

git commit :
Used to save changes to your local Git repository.
It takes a snapshot of the changes you've staged (using git add) and stores
them in the repository's history.
git commit only commit changes
in the staging area.

1. Use git add command to

stage your changes into the
staging area.
2. Use git commit command to
commit your changes to the
repo.
 GIT Basics

You must provide a commit message to describe the changes. This message
helps you and others understand what the commit does.
$ git commit -m <commit_message>
 GIT Basics

Each commit includes:

The author's name and email (set using git config).
A unique commit hash (e.g., a1b2c3d).
A timestamp.
The commit message.
 GIT Basics

git log :
Used to display the history of commits in a repository.
This command is essential for reviewing changes, understanding the project's
history, and tracking down when specific changes were made.

Commit hash

Author details

Time stamp
Commit message
 GIT Basics

Ways of using git log command,

1.To see the last n commits 2. To see one-line summary of commit logs
git log -n <number> git log --oneline

3. Filters commits by a specific author.

git log --author=<author_name>
 GIT Basics

git diff :
Used to show the differences 1. Compare changes between two commits
between various states of files in a $ git diff <commit1_hash> <commit2_hash>
repository.
It helps you compare changes in
your working directory, staging area,
and commit history.
This command is particularly useful
for understanding what has been
modified, added, or deleted before
committing changes.
 GIT Basics

2. Check differences between your working directory and the staging area.
(use git diff command without any arguments)
$ git diff
Summary
1.git init
2.git status
3.git add < . | directory_name | file_name >
4.git commit -m < commit_message >
5.git log < -n number | -oneline | --author=author_name >
6.git diff < without any params | commit1_hash commit2_hash >
 Activity 2
1. Create a folder named 'git_act'. Initialize that folder as a git repository.
2. Create a text document with the name of 'hello.txt'. Add the text line "Hello,
World!" in to that text file.
3. Create a html file. Add some basic html structre. In the body, create a
heading(h1) with the text of "Hello, Git".
4. Check the changes in the repo using an appropriate git command.
5. Add only the html file to the staging area. Then commit only the html file to
the repo using the commit message "html file added".
6. Check the repo status.
7. Again change the html file's heading text from "Hello, Git" to ""Hello, HTML!"
8. Stage all unstaged changes, all at once.
9. Commit them using the commit message "HTML modified and text file
added".
10. Check the previous commits using an appropriate git command.
Introduction to GitHub
 Introduction to GitHub

GitHub is a A cloud-based platform built around Git which provides hosting

for Git repositories.
 Introduction to GitHub

How to create a repository on GitHub ?

 Introduction to GitHub

What's 'origin', 'remote' & 'upstream' :

REMOTE (remote repository): Any Git repository that is connected to your local
repository.
Ex: GitHub, GitLab, Bitbucket, or any other Git server.

ORIGIN : The default name Git gives to the remote repository from which you
originally cloned your project.
Ex: git push origin main

UPSTREAM : The term upstream is commonly used when you've forked a

repository.
Your forked repository (on your GitHub account) is typically set as origin.
The original repository you forked from is set as upstream.
 Introduction to GitHub

git clone :

used to create a local copy of a remote Git repository. It

downloads all the repository's files, history, and branches
to your local machine.

Basic Syntax,
git clone <repository-url>

Ex:
git clone https://github.com/user/repo.git
 Introduction to GitHub

Other git clone usages,

1. Cone into a specific folder

git clone <repo_link> <folder_name>
Ex: git clone https://github.com/user/repo.git newFolder1

2. Cloning a Specific Branch

git clone --branch <branch_name> <repo_link>
Ex: git clone --branch branch-name https://github.com/user/repo.git

3. Cloning a Repository Without Full History (Shallow Clone)

git clone --depth={n} <repo_link>
Ex: git clone --depth=1 https://github.com/user/repo.git
(This clones only the latest n number of commit, reducing download size.)
 Introduction to GitHub

when you clone a remote repository, Git automatically names that remote
'origin' by default.

You can check the origin's repository link using

this command,
git remote -v
OR
git remote get-url origin
 Introduction to GitHub

How to add an existing GitHub repo to our local

repo ?
First of all, Initialize the local git repo with
$ git init

Then, add the remote repository link as your 'origin' using,

$ git remote add origin <remote_repo_link>
'-u' here is used as a short term for
'--set-upstream'
Stage, commit & push your files which is used to set the upstream
$ git add . branch when pushing changes for
$ git commit -m "Initial commit" the first time.
After setting origin/main as the
$ git push -u origin main upstream branch, us can simply
use,
git push & git pull
 Introduction to GitHub

git push & git pull :

git pull : Downloads changes from a
remote repository and merges them
into your local branch.

When you want to update your local

repository with the latest changes
from the remote repository.

git push : Uploads your local commits to a remote repository.

After committing changes locally, use git push to share them with others or
back them up on the remote repository.
 Introduction to GitHub

git pull git push

Syntax : Syntax :
git pull <remote-name> <branch-name> git push <remote-name> <branch-name>

Ex : git pull origin main Ex : git push origin main

Or simply use git pull Or simply use git push
If the remote repository has changes
If there are conflicts between your you don't have locally, you may need
local changes and the remote to git pull first.
changes, Git will prompt you to If the upstream doesn't have a branch
resolve them. we are tying to push, use this
command to create the branch in the
origin.
git push -u origin main
 Activity 3
Part 1 :
1. Cretae a GitHub repo using under the name 'git_act'
2. Connect your local 'git_act' repo with the new github 'git_act' repo. (Setup
the origin/remote repo)
3. Check the status. make sure to add and commit all changes.
4. push you files to the origin/remote repo.
5. Check your repo using github.

Part 2 :
1. Try to clone this repo into your local machine using an appropriate git
command.
https://github.com/ranga1729/git_cheat_sheet.git
 Introduction to GitHub

Branches
Branch is an independent line of development within a Git repository. It
allows multiple people to work on different features, bug fixes, or experiments
without affecting the main codebase.
Why Use Branches?
Isolate Changes - Work on a new feature
without modifying the main code.
Collaborate Easily – Teams can work on
different branches and merge their
changes later.
Safe Experimentation – Test new ideas
without breaking the working project.

Primary branch is named 'main'.

 Introduction to GitHub

1.To check the current working branch. 2. Create a new branch.

$ git branch $ git branch <branch_name>
Ex: git branch dev
3. Change the working branch.
$ git checkout <branch_name>
Ex: git checkout dev
To use 'git checkout' command, 'dev' branch must be already exists in the
repo.
Or we can create and checkout the branch at the same time using,
$ git checkout -b <branch_name>
Ex: git checkout -b dev

4. Delete a branch
$ git branch -d <branch_name>
 Introduction to GitHub

Merging Branches
Merging is the process of combining changes from one branch into another.
Whenever isolated work is completed and ready for integration, we can
merge.
 Introduction to GitHub

Common base : Shared ancestor commit, of both branches before they split
up.
Feature tip : Latest commit of the feature branch.
Main tip : Latest commit of the main branch.
 Introduction to GitHub

Main
Branch

Feature
Branch

When the feature is development is finished,

we merge this branch into the main branch.
 Introduction to GitHub

Pull Request(PR)
A Pull Request (PR) is a feature in GitHub that allows developers to propose
changes to a repository before merging them into the main branch.
It acts as a code review request, where team members can review, comment,
and approve changes.
 Introduction to GitHub

Merge a branch into another branch

source-branch First of all, Make sure necessary
changes are commited to the source
branch.
1.Checkout to target branch
target-branch $ git checkout <target-branch>

2.Execute the command

$ git merge <source-branch>

3.Push changes to the remote repository

$ git push | $ git push origin target-branch
Merge Conflicts

Merge conflict is a issue arise when

you try to merge a one branch into
another in a way that git doesn't
allow yout to complete the branch
mergeing processing untill you
solve the conflict in the changes.

Ex:
two people edit the same line in a file
when one person deletes a file that another has modified.
GitHub Interface...
git reset
Used to undo changes.
git reset

Remove staged changes from the staging area.

$ git reset

git reset can befurther used by mainly 3 ways,

$ git reset --soft $ git reset --mixed $ git reset --hard

git reset --soft <commit>
Moves HEAD to the specified
commit.
Undo commit.
Keep all changes in the staging area.
Useful when you want to undo
commits but keep the changes
staged for recommitting.
git reset --mixed <commit>
Moves HEAD to the specified
commit.
Undo commit.
Unstages changes (moves them
from the staging area to the
working directory).
Keep files.
git reset --hard <commit>
Moves HEAD to the specified
commit.
Undo commit.
Delete all uncommitted changes in
both the staging area and working
directory.
⚠ Warning: This is irreversible.
git reset summary
Keep
Keep
Moves changes in Deletes
changes in
HEAD the staging Changes?
files ?
area ?

git reset --soft

git reset --mixed

git reset --hard

git revert
Used to undo a specific commit by creating a new commit that negates its
changes.
Instead of removing a commit, git revert creates a new commit that undoes the
changes from a previous commit.

Syntax,
$ git revert <commit-hash>
revert vs reset
Affects Safe for
Effect History Shared
? Branches?

Creates a new commit that undoes

git revert
changes

Moves HEAD to a previous

git reset
commit, removing later commits
git stash
git stash temporarily saves (stashes) your uncommitted changes.

It allows you to work on something

else without committing incomplete
work. Later, you can restore (unstash)
those changes when needed.
 1. git stash
Temporarily save your change.
Moves all uncommitted changes (both staged and unstaged) into a stash.
2. git stash list
To see a list of all stashed changes.
Moves all uncommitted changes (both staged and unstaged) into a stash.
Ex:

3. git stash apply

To bring back the most recent stash. This restores the changes but keeps the
stash in the list.
4. git stash apply stash@{n}
If you want to apply a specific stash. {n : 1, 2, 3, ...}

5. git stash pop

To apply and remove the most recent stash in one step.
This restores the changes and deletes the stash entry.

6. git stash drop stash@{n}

Delete a specific stash in entry in the list.

7. git stash clear

Delete all stashes.
gitignore
A .gitignore file tells Git which files and directories to ignore in a repository.
This is useful for excluding temporary files, dependencies, and sensitive
information from being tracked.

Ex: node_modules in a react/node project

Create a gitignore file using the CLI,

$ touch .gitignore
Add the names of files, directories, or patterns you want Git to ignore.

1. Ignore a specific file 2. Ignore a specific directory

Mention the file name. Mention the folder name with the '/' at the end.
Ex: Ex:
config.env dirName/
names.txt node_modules/
/build/output/

3. Ignore all files of a specific file type.

Mention the file type with the '*' as the file name and mention the file extension.
Ex:
*.txt
Add the names of files, directories, or patterns you want Git to ignore.

3. Ignore everything in a directory except a specific file.

First, add the rule to ignore the directory.
Then add a rule to add the file in that directory.

Ex:
Ignore everything
/docs/*
in the a directory.
!/docs/README.md
Specifically saying
not to ignore this file

The .gitignore file only affects untracked files. It won't remove files already
tracked by Git.
 Best practises in Git
Write clear commit messages
Use present tense imperative mood.
ex: "Add feature"
Make small, atomic commit messages.
Each commit should represent single logical change.
Don't include unrelated changes to the commit.
Create a new branch for each feature, bug fix or experiment.
Use descriptive branch names.
ex:
feature/login
bugfix/header-stylings
 Best practises in Git
Frequently sync your branch with the main branch (e.g., main or master)
to avoid merge conflicts.
Review Changes Before Committing.
Use git status or git diff

Avoid Committing Sensitive Data.

Set a .gitignore file to exculde sensitive information.
Ex: Passwords, API Keys
Write Descriptive PR Titles and Descriptions
Clearly explain the purpose of the PR and the changes made.
Include screenshots, links, or references to related issues.
 Best practises in GitHub
Write Descriptive PR Titles and Descriptions
Clearly explain the purpose of the PR and the changes made.
Include screenshots, links, or references to related issues.

Use Issues and Project Boards

Track tasks, bugs, and feature requests using GitHub Issues.
Organize work with GitHub Projects or Kanban boards.

Follow a branching strategy.

Ex:
main - for production ready code
dev - for ongoing development
feature branches - for new features.
 Best practises in GitHub
Keep the Main Branch Stable
Ensure the main branch is always deployable.
Avoid pushing directly to main; use PRs instead.

Document Your Repository

Include a README.md with project details, setup instructions, and usage
guidelines.

Secure Your Repository:

Use two-factor authentication (2FA) for your GitHub account.
Regularly review access permissions for collaborators.
 Mark down
Markdown is a lightweight markup language used to format text with simple
syntax, allowing users to create documents with headings, lists, bold, and
italic text, without needing HTML or a complex editor.

GitHub uses markdown in,

repository READMEs
comments on pull requests and issues