Git is a version control system that tracks changes to files and allows multiple versions of files to exist. It is installed locally on a user's computer and tracks changes made to files. GitHub is a cloud-based hosting service that allows users to host Git repositories remotely and provides a web interface to view repositories. By pushing repositories to GitHub, users can easily share codebases with teams and create an online portfolio of their work.

1. E
F
G
H
B
C
D
E
Q
R
S
T
A
B
C
D
G
H
I
J
&
A
B
P
Q
R
S
C
D
E
F

2. E
F
G
H
G
H
I
J
R
S
T
U
-
&
F
G
H
I
S
T
U
&
A
B
C &

4. What is Git
• Git is a Version Control System (VCS) designed to make it easier to have
multiple versions of a code base, sometimes across multiple developers
or teams
• • It allows you to see changes you make to your code and easily revert
them.
• • It is NOT GITHUB!

5. Ok, then what is GitHub?
• Github.com is a website that hosts git repositories on a remote
server
• Hosting repositories on GitHub facilitates the sharing of codebases
among teams by providing a GUI to easily fork or clone repos to a
local machine
• By pushing your repositories to GitHub, you will pretty much
automatically create your own developer portfolio as well!

6. WHY GIT AND GITHUB?
• Distributed Version Control
• Efficient Branching and Merging
• GitHub as a Collaborative Platform
• Community and Open Source Collaboration
• Security and Access Control

7. What is version control system?
• A way to manage files and
directories
• Track changes over time
• History Tracking
• Backup and Disaster Recovery
• Traceability and Accountability

8. Used for version control
Installed locally on computer
Tracks changes made to a file
Used for hosting Git repositories
Cloud based
Provides a web interface to view
1
2
Git Vs Github: What’s the
difference

9. Used for version control
Installed locally on computer
Tracks changes made to a file
Used for hosting Git repositories
Cloud based
Provides a web interface to view
a filechanges
1
2
3
Git Vs Github: What’s the
difference

10. Used for version control
Installed locally on computer
Tracks changes made to a file
Used for hosting Git repositories
Cloud based
Provides a web interface to view
a filechanges
1
2
3
Git Vs Github: What’s the
difference

11. Local Installation and GitHub
Account Creation

12. INSTALL GIT THROUGH THIS
LINK
https://git-scm.com/download

13. Confirm that you have git
• Open your terminal and run ‘git’
• If you see a ‘command not recognized’ error, you
probably haven’t installed git yet.
• We can solve your issue when the lectures are over – sit tight for now!

14. GITHUB ACCOUNT
CREATION

16. What is GIT?
• Git is Distributed Version Control System Tool.
• Git is not acronym and hence no expansion . But most of the
people abbreviated as "Global Information Tracker".
• GIT is developed by Linus Torvalds(Finnish software engineer),
who also developed Linux Kernel.
• Most of the companies like Microsoft , Facebook , Yahoo ,
LinkedIn , Intel using Git as Version Control System Tool.
• Git is an distributed version control system

17. Version control system
Version control system :
What is meant by version control system?
Version control, also known as source control, is the practice of
tracking and managing changes to software code. Version
control systems are software tools that help software teams
manage changes to source code over time.

18. GIT Architecture:
GIT contains 2 types of
repositories:
1) Local Repository
2) Remote Repository
Working
directory
Starting
area
Local repo
Remote
repo
Git add
Git commit
Git push
Git pull
Git checkout
Git merge

19. HOW TO ADD VERSION
CONTROL SYSTEM
TO OUR PROJECT?

20. GIT INIT
• This Command basically adds the vcs to our project
Git
• How to check whether the git is installed in our system or not?
• Just type the commad
git or git --version
OUTPUT : IF YOU CAN SEE SOME GIT COMMANDS THEN YOUR SYSTEM HAS GIT
IF NOTHING IS DISPLAYED THEN YOU DON’T HAVE GIT

21. Git config
• Let me introduce a new term here that is config.
• Config mean configuration.
• We won’t use config commands frequently in our
programming journey but having a good knowledge of this cofig
is must.

22. • $ git config --list
• To list out all git configurations
• $ git config user.name
• To display user name
• $ git config user.email
• To display user email
• We can change user name and mail id with the same commands
• git config --global user.email “xxx@gmail.com"
• git config --global user.name “namexx”
Note: global means these configurations are applicable for all repositories created
by git. If we are not using global then it is applicable only for current repository.

23. Life Cycle of File in GIT
Working directory Initialization
Staging area
Local Repository
Github
Git init
Git add
Git commit
Git push

24. Life Cycle of File in GIT
• Every file in GIT is in one of the following states:
• 1)Untracked: The files which are newly created in working directory and
git does not aware of these files are said to be in untracked state.
• 2)Staged: The files which are added to staging area are said to be in
staged state. These files are ready for commit.
• 3)In Repository/ Committed: Any file which is committed is said to be In
Repository/Committed State.
• 4)Modified: Any file which is already tracked by git, but it is modified in
working directory is said to be in Modified State.

25. Stages in GIT Life Cycle
• Working directory
• Staging area (or) Cached area (or) Index area
• Git directory (or) local repository

26. Working Directory
• Consider a project residing in your local system. This project may
or may not be tracked by Git. In either case, this project directory
is called your Working directory.
• Working directory is the directory containing hidden .git folder.

27. Staging Area
• The source code files, data files, configuration files and other project
artifacts contain the business logic of the application. These files are to be
tracked by Git are thus needs to be added to the staging area.
• In other words, staging area is the playground where you group, add and
organize the files to be committed to Git for tracking their versions.
• It's important to make a quick note of the term
called indexing here. Indexing is the process of adding files to the staging
area

28. Git Directory or local repocitory
• we commit this group of files along with a commit message
explaining what is the commit about. Apart from commit
message, this step also records the author and time of the
commit. Now, a snapshot of the files in the commit is recorded by
Git. The information related to this commit (names of files
committed, date and time of commit, author of commit, commit
message) is stored in the Git directory.
• Thus, Git directory is the database where metadata about project
files' history will be tracked.

29. git init
• Once we creates workspace, if we want version control, then we require
a local repository.
• To create that local repository we have to use git init command. $ git
init Initialized empty Git repository in D:/gitprojects/project1/.git/ .git is
an empty repository, which is hidden directory.
• Now let us see whats inside the our project or folder

30. .git
• Now we can see this directory in our project
• This is the place where basically git internally takes care of everything
about the project and takes care of implementing vcs to our project
• This is what will present in .git directory don’t worry as this ppt goes
on you will come to know about this internal structure

31. • By seeing the .git we can say that git added vcs to our project
• But there is one more way to check this
• This git status does that work for us
• It shows the current status of all files in each area, like which files
are untracked, which are modified, which are staged etc.
• What if we delete .git folder ?
• What if we execute git init once more after doing it once?
• why in start because the represents the hidden files or folder.

32. Git add
• Still now we have nothing in our project (like any files)
• Lets add some files to it
• Now execute the git status command again
• You can see our files were untracked by git
• What should we do to so that git can track our files?

33. Git add
• Different variations in git command:
• To add all files present in current working directory
git add .
• To add one or more specified files
git add a.txt git add a.txt b.txt
• Even we can use pattern or regular expressions also
git add *.txt
git add *.java

34. • What actually happens when we use git add command?
• Now what will be the status of our project?
• What if we modify this files?
• Now what will be the status of our project after modifying the
files?
• What will be the status if we create a new files in working
directory?
• What happens if we modify the files that are not tracked?
Git add

35. Git commit
• If we want to commit staged changes, then we have to use git commit
command.
• For every commit, a unique commit id will be generated. It is of 40-length
hexadecimal string. $ echo -n
"df4bb05e36e672698251e05e09d92ba45ea1fc47" | wc -c 40 The first 7
characters also unique, by using that also we can identify commit.
• This unique id is considered as hash, which is generated based on content of
files. The advantages of this hash are
• 1) Data inside our local repository is more secure.
• 2) git requires less space to store contents of files. (If SVN repository required
12GB, but for same content git requires 420MB)
• while using git commit command, commit message is mandatory. git commit -
m "commit message"

36. Git commit:
• Now let us try to understand the git commit

37. Git Internal mechanism
• So basically what’s happing internally when we execute git commit
command?
• Now, suppose we create a file named myfile.txt and add it to our repository
with the command git add myfile.txt.
• When we perform this operation Git creates a blob, a file located in the sub-
folder .git/objects which stores the content of myfile.txt, without including any
related metadata (such as the creation timestamp, the author, and so on).
• Hence, creating a blob is like storing a picture of the content of the file.
• The name of the blob is related to the hash of its content. Once the content is
hashed, the first two characters are used to create a sub-folder in .git/objects,
while the remaining characters of the hash constitute the name of the blob.

38. Git Internal mechanism
• In summary, when adding a file to Git, the following steps occur:
• Git takes the content of the file and hashes it
• Git creates a blob within the .git/objects folder. The first two characters of the hash are
used to create a sub-folder in this path. Within it, Git creates the blob having a name
formed by the remaining characters of the hash.
• Git stores the contents of the original file (a zipped version of it) within the blob.

39. Git Internal mechanism
• Note that if we have a file named myfile.txt and another file
named ourfile.txt, and both of them share the same content, they have the
same hash, and so they are stored in the same blob.
• Also notice that if we slightly modify myfile.txt and re-add it to the repository,
Git carries out the same process, and since the content is changed, a new blob
is created.

40. Git Internal mechanism
• At this point, we commit both myfile.txt and yourfile.txt with the
command git commit. When doing this, Git takes two steps:
• It creates a root tree of the repository
• It creates the commit
• Let us focus on the first step. So, what is a root tree? A root tree stores
the structure of files and folders of the entire repository. It is a file
containing the reference to every blob or sub-folder included in the
repository, built in a recursive manner.

41. • Do git creates separate directories for different commits?
• So as of now we did only few commits in real time we will have hundred of
commits then how to track them?
• So for tracking of the commits we have a command called
• Git log
• It’s one of the most used command so let us have brief discussion about it

42. Git log
• How to see History of all commits in Local Repository:
• If we want to see history of all commits in local repository, then we have to use
git log command. It is the most commonly used command in git.
• There are many variations in the git log command
• Let us see few of them which are important

43. Git log
• To see Log Information of a Particular File
• git log
• --oneline Option to get brief Log Information
• git log –oneline
• -n Option to Limit the Number of commits to Display
• git log -n (number)
• --grep Option to search based on given Pattern in commit Message:
• git log --grep="pattern"
• Refer documentation for some more like according to time and date and
between dates etc

44. Another version of commit
• Can we directly commit the changes in working directory to local directory
without using staging area as intermediate area
• Yes we can do that
• Just use the command
• Git commit –a -m “commit msg”
• Lets try it out

45. Git diff
What if we want to compare the content of a particular file to other particular file?
So what can we compare
1) Between working directory and staging area
2) Between working directory and last commit
3) Between staged area and last commit
4) Between working directory and a particular commit
5) Between staged area and a particular commit
6) Between two specified commit

46. Git diff
Case-1: To see the difference in File Content between Working Directory and
staging Are
-git diff finename

47. Git diff
Case-2: To see the difference in File Content between staged Copy and Last
Commit
git diff - -staged HEAD file1.txt
(or)
git diff - -cached HEAD file1.txt

48. Git diff
Case-3: To see the difference in file content between specific commit and staging
area copy
git diff - -staged commit-id file1.tx
Or
git diff - -cached commit-id file1.tx

49. Git diff
Case-4: To see the difference in File Content between 2 specified Commits:
git diff commit-id commit-id filename

50. Git diff
Case 5: To see the difference in file content between specific commit and staging
area copy:
git diff --staged commit-id file1.txt

51. Git diff
Case-6: To see the difference in File Content between specific Commit and
Working Directory Copy
git diff commit-id file1.txt
Simillarly you can try different combinations with this diff command just try them
and see result

52. Git rm
• It is very common requirement to remove files from working directory and
staging area.
• For these removals we can use the following commands
git rm file1.txt
git rm --cached file1.txt
• Normal deletion in working directory according to operating system

53. Git checkout
We can use checkout command to discard unstaged changes in the tracked files
of working directory.
Observe the 3 words:
1) Only for working directory
2) To discard unstaged changes(The changes which are not added to staging
area)
3) In the tracked files (The files which are already added to staging area/commit)
It is something like undo operation.
It will copy contents of the file from index area(staging area) to working directory.
git checkout -- filename

54. Git reset
• git reset command is just like reset settings in our mobile.
• There are 2 utilities of git reset command.
• Utility-1: To remove changes from staging area
• Utility-2: To undo commits at repository level

55. Git reset
• Utility-1: To Remove Changes from staging Area We can use git reset to remove
changes from staging area.
• Changes already added to staging area, but if we don't want to commit, then to
remove such type of changes from staging area, then we should go for git reset.
• It will bring the changes from staging area back to working directory.
• It is opposite to git add command
• git reset file1.txt

56. Git reset
• Utility-2: To undo Commits at Repository Level
• We can also use reset to undo commits at
repository level
• Syntax: git reset Moves the HEAD to the
specified commit, and all remaining recent
commits will be removed. mode will decide
whether these changes are going t0 remove
from staging area and working directory or
not.
• The allowed values for the mode are:
• --mixed
• --soft
• --hard
• --keep
• --merge

57. Git reset
• 1)--mixed Mode:
• It is the default mode. To discard commits in the local repository and to discard
changes in staging area we should use reset with --mixed option. It won't
touch working directory.
• git reset --mixed commit-id

58. • 2)reset with --soft Option: It is exactly same as --mixed option, but changes are
available in working directory as well as in staging area.
• It won't touch staging area and working directory.
• As changes already present in staging area, just we have to use commit to
revert back.
• git reset --soft commit-id
Git reset

59. Git reset
• reset with --hard: It is exactly same as --mixed except that Changes will be
removed from everywhere (local repository,staging area,working directory)
• It is more dangerous command and it is destructive command.
• It is impossible to revert back and hence while using hard reset we have to take
special care
• git reset --hard commit-id

60. Git reset
--mixed vs --soft vs –hard
• 1. --mixed: changes will be discarded in local
repo and staging area. It won't touch working
directry. Working tree won't be clean. But we
can revert with git add . git commit
• 2. --soft Changes will be discarded only in local
repository. It won't touch staging area and
working directory. Working tree won't be clean.
But we can revert with git commit
• 3. --hard Changes will be discarded
everywhere. Working tree won't be clean. No

61. Additional git topics
Git alias names
Creating alias Name: We can create alias name by using git config command.
Syntax: git config --global alias.aliasname "original command without git"
Eg: git config --global alias.one "log --oneline“
.gitignore
Lets discuss about .gitignore
How do git treats the directory?
any special treatment for the directories?

62. THE CONCEPT OF
BRANCHING

63. What is Branching?
Branching is one of very important concept in version control systems. While
working on real time projects code base, branching is one of mandatory and
unavoidable concept. Till now whatever files created and whatever commits we
did, all these happend in main branch. main branch is the default branch/ main
branch in git. Generally main source code will be placed in main branch.
Branching

64. Branching
Need of Branching
Assume we required to work on new requirements independently, then instead of
working in the master branch, we can create a seperate branch and we can work
in that branch, related to that new requirement without affecting main branch.

65. Branching
LETS HAVE A BEIF DISCUSSION ON BRANCHINGWITH IMAGES

66. Branching
Conclusions:
1. Once we creates a branch all files and commits will be inherited from parent branch to child
branch. Branching is a logical way of duplicating files and commits. In the child branch we can
create new files and we can perform new commits based on our requirements.
2. All branches are isolated to each other. The changes performed in master branch are not
visible to the new branch and the changes performed in the new branch are not visible to the
master branch.
3. Once the work completed in new branch then we can merge that new brach to the main
branch or we can push that branch directly to the remote repository

67. Let’s see how to implement
branching and various
commands and concepts
related to branching now.

68. Branching
To View Branches:
To know all available branches in our local repository, we have to use git branch
command.
git branch - It will show all branches in our local repository.
- By default we have only one branch: master - master is the default name provided
by GIT.
$ git branch
• master indicates that master is current active branch.
• Too see remote branches just type –r along with git branch

69. Branching
How to Create a New Branch:
Short-cut Way to Create a New Branch and switch to that Branch:
We have to use -b option with checkout command.
git checkout -b new2branch
$ git checkout -b new2branch
Switched to a new branch 'new2branch’
Note : You can use the same command even to switch between the branches

70. Branching
Important Conclusions:
1. All branches are isolated to each other. The changes performed in master branch are not
visible to the new branch and the changes performed in the new branch are not visible to the
master branch.
2. In GIT branching, logical duplication of files will be happen. For every branch, new directory
won't be created. But in other version control systems like SVN, if we want to create a branch,
first we have to create a new directory and we have to copy all files manually to that directory
which is very difficult job and time consuming job.
3. In Git, if we switch from one branch to another branch just HEAD pointer will be moved,
beyond that no other work will be happen. Hence implementing branching concept is very easy

71. Branching
Multiple Use Cases where branching is required:
1. If we are working on a new feature of the project, and if it is required longer
time then we can use branching. We can create a separate branch for
Implementing new feature. It won't affect main code (master branch).

72. Branching
2. If we required to work on hot fixes of production code, then we can
create branch for the production code base and we can work on that
branch. Once work completed then we can push the fixed code to the
production. Most of the real time projects have a separate production
branch to handle this type of requirements.

73. Branching
3. To support multiple versions of same code base, branching is required. For
every version, a separate branch will be there. If we want to fix any bugs or
performance issues or any changes in a particular version, then we can work in
that branch and we can push changes to the production.
4. To test new technologies or new ideas without effecting main code base,
branching is the best choice

74. Branching
Advantages of Branching:
1. We can enable Parallel development.
2. We can work on multiple flows in isolated way.
3. We can organize source code in clean way.
4. Implementing new features will become easy
5. Bug fixing will become easy.
6. Testing new ideas or new technologies will become easy.

75. Branching
Merging of a Branch:
We created a branch to implement some new feature and we did some new
changes in that branch, once work is completed we have to merge that branch
back to parent branch.
We can perform merge operation by using git merge command.
We have to execute this command from parent branch.
Feature
Feature
Feature

76. Branching
What is Fast-forward Merge?
After creating child branch, if we are not doing any new
commits in the parent branch, then git will perform fast-
forward merge.
i.e updates (new commits) happened only in child
branch but not in parent branch. In the fast-forward
merge, git simply moves parent branch and points to the
last commit of the child branch.
Fast Forward Merge
Before Merge After Merge

77. Branching
What is Three-Way Merge?
If changes present in both parent and child branches and if we are trying to perform merge
operation, then git will do three-way merge.
Three-way merge creates a new commit which is also known as merge commit. Parent branch
will pointing to the newly created merge commit
Some features
After 3-Way Merge
Before Merge
main
main
Some features

78. Branching
• Merge Conflicts and Resolution Process In the case of 3-way merge,
• if the same file updated by both Parent and child branches then may be a chance of merge
conflict.
• If there is a conflict then GIT stops the merge process and provides conflict message. We
have to resolve the conflict manually by editing the file.
• Git will markup both branches content in the file to resolve the conflict very easily. Once we
completed editing of the file with required final content, then we have to add to the staging
area followed by commit. With that merging process will be completed.

79. Branching
How to Delete a Branch?
Once we completed our work we can delete the branch. Deletion of the branch is
optional. The main objective of deleting branch is to keep our repository clean.
We can delete a branch by using
git branch command with -d option.
Syntax: $ git branch -d
After deleting the branch, still files and commits are available because the changes are
merged to master branch.

80. Branching
• Rebase is alternative way to merge changes of two branches togther. rebase = re + base -> re
arrange base
• Process of rebasing: It is a two step process.
• Step-1: We have to rebase feature branch on top of master branch. A. Checkout feature branch git
checkout feature B. Rebase feature branch on top of master branch git rebase master
• Step-2: We have to merge feature branch into the master branch(fast-forwar merge will be
happend)
• A. checkout master branch git checkout master
• B. Merge feature branch into master branch git merge feature

81. Advantages of rebasing:
1. Rebase keeps history linear. In 3-way merge, a commit can have multiple parents. But in
Rebase every commit has a single parent only. Hence history will be liner.
2. Clear work flow (Linear) will there. Hence easy to understand for the developers.
3. Internally git performs Fast-forward merge and hence there is no chance of conflicts. 4.
No extra commit like merge commit. .
Disadvantages of rebasing:
1. It rewrites history. We cannot see history of commits what we did in feature branches
2. We does not aware which changes are coming from which branch.
Branching

82. Note: Rebase is very dangerous operation and it is never recommended to
use on public repositories because it rewrites history.

83. • Its all about working with git in local
• Now you just want to learn how to connect there local to remote
• All the concepts will be same in remote as locak bit you will have some new
concepts and features
• Here we will use github as remote server
• So we will continue git learing with github
• Thank you have a nice day
Branching

84. Branching
• Forgoten topics
• Git help command
• Git show command
• Git ls-files
• 14,15,16

85. Remote

86. Create a repository on github
• Dashboard
• Repository Settings
• Create Repository

87. Set up remote
• What is remote
How to set up remote
• git remote add <remote_name> <repository_URL>
• git remote remove <name>
• git remote rename <old-name> <new-name>

88. Push and pull
• The git push command is used to update a
remote repository with the changes you've
made in your local branch.
• git push <remote> <branch>
• The git pull command fetches the latest changes
from the specified remote repository and
branch and then merges those changes into
your current local branch.
• git pull <remote> <branch>

89. Cloning
• The git clone command is typically used when you want to start working on an existing
project or collaborate with others. It downloads the entire history, files, and branches
from the remote repository to your local machine, creating a copy that you can work
with.
• git clone <repository-url>

90. How to Create a Pull Request
on GitHub
• Contributing to open-source projects is a fantastic way to collaborate with the
community and improve software together. One common way to contribute is by
creating a pull request (PR) on a GitHub repository.

91. Fork and clone the Repository
• Clone the forked repository to your local machine using the following
command, replacing `<url>` with the repository's URL:
• git clone <url>

92. Create a branch
• Change into the cloned repository's directory:
• cd <repository_name>
• Create a new branch for your contribution.
• git checkout -b <branch_name>

93. Stage and Commit Your
Changes
• To add a specific file:
• git add <file_name>
• To add all changed files:
• git add *
• Commit your changes with a descriptive message:
• git commit -m "Description of the changes"

94. Push Your Branch to GitHub
• Push your branch to your GitHub account:
• git push origin <branch_name>

95. Create a Pull Request

96. Keeping Your Fork Up to Date
• Add the original repository as a remote source (only once):
• git remote add upstream <original_repository_url>
• Fetch the latest changes from the original repository:
• git fetch upstream

97. Keeping Your Fork Up to Date
• Update your local branch with the changes from the original repository's branch:
• git rebase upstream/<branch_name>
• Combine the original repository's branch with your local branch:
• git merge upstream/<branch_name>

98. What is ReadME
• A README is a text file that typically accompanies software projects and provides
essential information about the project.
• It's often the first thing someone sees when they visit a software repository on
platforms like GitHub.
• A README file is typically written in plain text using a simple markup language. The
most common markup language for creating README files is Markdown.

99. Lets write a simple markdown
• Heading
• Use "#" followed by a space to create headers.
# Heading1
## Heading2
### Heading3
#### Heading4
##### Heading5
###### Heading6
Heading1
Heading2
Heading3
Heading4
Heading5
Heading6

100. Lets write a simple markdown
• Ordered List:
• Prefix each item with a number followed by a period and a space.
1.First
2.Second
3.Third

101. Lets write a simple markdown
• Unordered List:
• Prefix each item with an asterisk (*) followed by a space.
- Item 1
- Item 2
- Item 3
• Item 1
• Item 2
• Item 3

102. Lets write a simple markdown
• Bold:
• Enclose text in double asterisks (**) to make it bold.
• Italic:
• Enclose text in single asterisks (*) or single underscores (_) to make it italic.
** Bold **
* Italic *
Bold
Italic

103. Extras - Github Pages
• GitHub Pages is a free
feature provided by
GitHub that allows you
to host and publish
websites directly from
your GitHub
repositories.

104. Charishma Tammana
Lead
Ashraf Mohammed
Tech Lead
Dhruv Chopra
Tech Lead
U.Abhishek
Design Lead
D.Celesty Bliss
PR Lead
S.Bhuvaneshwar
Programming Lead
J.Harika
Social Media Lead
Team

105. Thank You