Introduction to Git and GitHub

Introduction to
Git
Vikram
IoT Application Dev & DevOps
Distributed
Version Control

Contents
• Version Control Systems
• Setup Git
• Setup Local Git Repository
• Setup Remote Repository
• Git Branches
/kunchalavikram1427

Version Control Systems
/kunchalavikram1427

Version Control Systems(VCS)
/kunchalavikram1427
• Version control, also known as source control, is the practice of tracking and managing changes to software
code.
• It enables multiple people to simultaneously work on a single project. Each person edits his or her own copy
of the files and chooses when to share those changes with the rest of the team.
• These systems are critical to ensure everyone has access to the latest code. As development gets more
complex, there's a bigger need to manage multiple versions of entire products.
• Version control also enables one person you to use multiple computers to work on a project, so it is valuable
even if you are working by yourself.
• Version control integrates work done simultaneously by different team members. In most cases, edits to
different files or even the same file can be combined without losing any work. In rare cases, when two people
make conflicting edits to the same line of a file, then the version control system requests human assistance in
deciding what to do.
• Version control gives access to historical versions of your project. If you make a mistake, you can roll back to a
previous version. You can reproduce and understand a bug report on a past version of your software. You can
also undo specific edits without losing all the work that was done in the meanwhile. For any part of a file, you
can determine when, why, and by whom it was ever edited.
• In DevOps, other than keeping track of changes, VCS also helps in developing and shipping the products
faster.

Version Control Systems
/kunchalavikram1427
• Version control uses a remote repository and a working
copy where you do your work
• Your working copy is your personal copy of all the files in
the project. You make arbitrary edits to this copy, without
affecting your teammates. When you are happy with your
edits, you commit your changes to a repository
• A repository is a database of all the edits to, and/or
historical versions (snapshots) of, your project
• It is possible for the repository to contain edits(from
other developers) that have not yet been applied to your
working copy
• You can update your working copy to incorporate any
new edits or versions that have been added to the
repository since the last time you updated(pulling the
latest changes)
Repositories and working copies

Central Vs Distributed VCS
/kunchalavikram1427
Central VCS
• The main difference between centralized and
distributed version control is the number of
repositories
• In centralized version control, there is just one
repository, and in distributed version control, there
are multiple repositories
• In CVCS, the central server stores all the data. Each
user gets his or her own working copy, but there is
just one central repository. As soon as you commit,
it is possible for your co-workers to update and to
see your changes
• If the central server gets crashed, there is a high
chance of losing the data
• For every command, CVCS connects the central
server which impacts speed of operation
• Ex: Subversion VCS

Central Vs Distributed VCS
/kunchalavikram1427
Distributed VCS
• In distributed version control, each user gets his or
her own local repository and a remote repository
for all
• After you commit to the local repository, others
have no access to your changes until you push
your changes to the central repository
• If other users want to check your changes, they will
pull the updated central repository to their local
repository, and then they update in their local copy
• Even if the main server crashes, code that is in the
local systems can be used to restore the data
• DVCS is fast compared to CVCS because you don't
have to contact the central server for every
command
• Ex: Git, Mercurial

Installing Git
/kunchalavikram1427

Git
/kunchalavikram1427
Installing Git
For Windows
• Visit https://git-scm.com/book/en/v2/Getting-Started-Installing-
Git to install Git for your operating systems
• To install GUI clients, visit https://git-scm.com/downloads/guis
• Verify if Git is installed by running the command git version
in the CMD
• Use git help to get the list of supported commands and git
help <sub-command> for help on that command

Git
/kunchalavikram1427
What is Git?
Git is a distributed version control system source code
management (SCM) system that records changes to a file or
set of files over time, so that you can recall specific versions
later.
It allows you to revert selected files back to a previous state,
compare changes over time, see who last modified
something that might be causing a problem, and more.
Git has a remote repository which is stored in a server and a
local repository which is stored in the computer of each
developer. This means that the code is not just stored in a
central server, but the full copy of the code is present in all
the developers’ computers

Git
/kunchalavikram1427
The 3 States of Git
Files in a repository go through three stages before being under version control with git
1. Modified means that you have changed the file but have not committed it to your database yet
2. Staged means that you have marked a modified file in its current version to go into your next commit
snapshot
3. Committed means that the data is safely stored in your local database
• In addition to these three states, Git files live in one of three areas: the Working directory, Staging area, and
the Git directory (your local repository)

Git
/kunchalavikram1427
Create a local git repository
• Create a new project folder in your local filesystem
• Go into this newly created project folder and add a local Git
repository to the project using the following commands
git init
• Now this project can be managed using Git
• Git creates a hidden folder .git in the project whenever
you do git init
• The .git folder contains all the information that is
necessary for your project in version control and all the
information about commits, branches, remote repository
address, etc. All of them are present in this folder. It also
contains a log that stores your commit history so that you
can roll back to history
• Without .git, the project is considered a local project and not
a git project, that means you cannot perform any git
operations
Create a project
http://gitready.com/

Git
• A newly added file will always be created in the
working area and is untracked by default
• Now add some files to the local repository
• Check the status of the files using git status
• The status shows that file1.txt is an
untracked file as it is not added to the
staging area or Git has no idea what to do with
this file yet
• No commits yet indicates there are no commits
to the local repository yet
• The default Git branch is master
Add files to working area
UNTRACKED
UNSTAGED

Git
• Unlike many version control systems, Git has a staging area (index)
• The Staging area is there to keep track of all the files which are to be
committed. Any file which is not added to the staging area will not be
committed. This gives the developer control over which files need to be
committed at once
• git add lets you add files to the staging area
▪ git add file1.txt
▪ git status
• The status shows that file1.txt is ready to be committed to the local
repository
• In case you want to add multiple files you can use:
▪ git add file1 file2 file3
▪ git add . or git add -A
Add files to staging/index using ‘add’
STAGED

Git
• Before adding the files to staging, you can also
discard the changes done
• Lets add some content to file1.txt and see the file
status using git status
• The file is now in untracked state
• Git shows few hints whether to commit these changes
or to discard them
• To commit simple proceed with git add or run git
restore <file-name> to discard the changes
• Run git status again to see the status
Discard unstaged changes
UNTRACKED
UNSTAGED

Git
• Add few more files as shown in the figure and add to staging area
▪ git add file2.txt file3.txt (or)
▪ git add .
• Once a file is in the Staging area, you can unstage the file / untrack it
using the git rm --cached <file_name> command
Add files to staging
STAGED

Git
• git reset <filename>, git reset
HEAD <filename>, git rm --cached
<filename>, git restore --staged
<filename> all does the same work
Unstage files
UNTRACKED
UNSTAGED

Git
/kunchalavikram1427
Git Config
• The 'Git config' is a great method to configure your choice
for the Git installation. Using this command, you can
describe the repository behaviour, preferences, and user
information
• The global config resides at ~/.gitconfig in the user’s
home directory, while the repository specific config at
.git/config inside the project
• Use git config --help for more info
• Before we commit any changes to the repo, we need to set
the user name and email address for the git user so as to
make Git aware of who has made the commits
• Run below commands to set the configuration
• git config --global user.name "your name goes here"
• git config --global user.email "your email goes here"

Git
• Committing is the process in which the code is added
to the local repository
• Each commit has an associated commit message,
which is a description explaining why a particular
change was made. Commit messages capture the
history of your changes, so other contributors can
understand what you’ve done and why
• To give commit message, use -m flag
▪ git commit -m "Initial Commit"
• If you don’t use -m, Git will bring up an editor for you
to write the commit message
• Each time you commit changes to the repo, Git
creates a new SHA(20 byte number) that describes
that state
Committing the code
LOCAL
REPOSITORY

Git
• git log command lists the commits made in that
repository in reverse chronological order
• From the logs you can see the commit SHA ID,
Author, Date and Commit message
• The HEAD points out the last commit in the current
checkout branch. When you switch branches with
git checkout, the HEAD is transferred to the new
branch
View commit history
LOCAL
REPOSITORY

Git
• git log
• git show head is used
to check the status of
the Head
Add few more files to the staging
/kunchalavikram1427

Git
• git log --patch -2 shows the difference
(the patch output) introduced in each
commit. You can also limit the number of
log entries displayed, such as using -2 to
show only the last two entries
• git log --stat shows abbreviated stats
for each commit
• git log --pretty=oneline (or)
git log --oneline --pretty changes the
log output to formats other than the default.
--oneline value for this option prints each
commit on a single line
View commit history
/kunchalavikram1427

Git
/kunchalavikram1427
Git ignore (.gitignore)
• Git sees every file in your working copy as one of three things: tracked - a file which has been previously staged or
committed; untracked - a file which has not been staged or committed; or ignored - a file which Git has been explicitly
told to ignore
• Git is meant to store only source files and never the generated files or the personal config files with confidential
information
• Any generated code/binaries should not be committed due to following reasons:
▪ The generated files can be recreated at any time on the client side and may need to be created in a different form,
so It is a waste of time and space to store them in git
▪ The generated files are often large than the original source files themselves. Putting them in the repo means that
everyone needs to download and store those generated files, even if they’re not using them. This increased the
clone times
▪ Git usually stores only changes made to the file in the subsequent commits by using diff algorithm. Binary files don’t
really have good diff tools, so Git will frequently just need to store the entire file each time it is committed
• Any file added to .gitignore file in the root project directory will not show up as untracked file while doing git status and
so can be ignored. Common files to be ignored include:
▪ dependency caches, such as the contents of /node_modules or /packages
▪ compiled code, such as .o, .pyc, and .class files
▪ build output directories, such as /bin, /out, or /target
▪ files generated at runtime, such as .log, .lock, or .tmp
▪ hidden system files, such as .DS_Store or Thumbs.db
▪ personal IDE config files, such as .idea/workspace.xml
Git Ignore patterns:
https://www.atlassian.com/git/tutorials/saving-changes/gitignore
https://github.com/github/gitignore

Git
• Let’s create a file called TODO.txt which has todo list for
personal reference
• Add some content to this file and check the status
• Git shows the file as untracked. But these are personal
preferences and should not be committed or bring
under Git’s radar
• We can add this file to .gitignore file to instruct git to
ignore the changes done to TODO file and not to track
• We should commit .gitignore file so others can use it
and updated it with their own to be ignored content like
files generated code, log files, cache files and IDE
specific files
Git ignore (.gitignore)
/kunchalavikram1427

Git
• Files/Project which you have created earlier stays within your local repository
• If you want to share these files with other developers or team members to collaborate, you need to
push the local repo to a remote repository like GitHub
• After you have a remote repository set up, you upload (push) your files and revision history to it. After
someone else makes changes to a remote repo, you can download (pull) their changes into your local
repo
Create a Remote Repo
Remote Repo in Github
• Go to https://github.com/ and create a New Repository
/kunchalavikram1427

Git
• Give a Repository name, Description and
Make the repo public
• Click on Create Repository to create it
/kunchalavikram1427

Git
• Once created, GitHub will prompt to
create a new repo or to add a repo we
have created locally
• In our case, since we’ve already created a
local repository, we can push it directly
• Git will also show us the instructions to
be followed to push our local repo.
• In this case we need to push to the URL
that is shown
/kunchalavikram1427

Git
What Is Origin?
• Origin is an alias to the remote repository
• We assign an alias so we won't have to write out the URL
of the remote repo every time we want to work with the
remote repository
• While origin is the alias that most people prefer to use, it
is not a standard and we can use our own naming
conventions
/kunchalavikram1427

Git
Remote Repo
Adding the remote repo
• Add the remote repo by running
▪ git remote add origin
https://github.com/<your-user-
account>/test-repo.git
• remote command adds a remote repository
to the current repository
• Check the remote URLs and their aliases
▪ git remote –v
• Remove the remote repo by running
▪ git remote rm origin
/kunchalavikram1427

Git
Remote Repo
Push the files to the origin
REMOTE
REPOSITORY
• git push pushes our local repo changes to the
added remote repo. origin represents the remote
repo and master is the branch you want to push to.
Git will prompt for your git credentials during push
▪ git push -u origin master
• We can omit origin and -u master parameters from the git push command
with the following two Git configuration changes:
$ git config remote.pushdefault origin
$ git config push.default current
• The first setting saves you from typing origin every time. And with the second
setting, Git assumes that the remote branch on the GitHub side will have the
same name as your local branch.
/kunchalavikram1427

Remote Repo
Push the files to the origin
REMOTE
REPOSITORY
• Go to your GitHub account
and see the changes
Git
/kunchalavikram1427

Git
/kunchalavikram1427
Branches
• GIT Branch is about maintaining the separate line of development. The default branch is Master
• Git lets you branch out from the original code base. This lets you more easily work with other developers, and gives you a
lot of flexibility in your workflow
• Let's say you need to work on a new feature for a website. You create a new branch and start working. You haven't
finished your new feature, but you get a request to make a rush change that needs to go live on the site today. You switch
back to the master branch, make the change, and push it live. Then you can switch back to your new feature branch and
finish your work. When you're done, you merge the new feature branch into the master branch, and both the new feature
and rush change are kept!

Git
/kunchalavikram1427
Branches
• Basically, A branch is the isolated and independent line of
developing the feature
• Assume the middle line as the master branch where the code is
stable, working and updated
• Then, assume a developer-1 is assigned to develop Feature – 1.
So, Developer-1 is cutting a branch from the master branch
which is indicated in the diagram as in Magenta colour
• Similarly Developer-2 is assigned to develop Feature-2 and he is
cutting a branch from the master branch which is indicated in
Blue colour
• When both of them are done with their changes they merge their
branches to the master and these feature branches can be safely
deleted
• Let’s assume the codebase is the set of four files called File-1,
File-2, File-3, and File-4. So, when Developer-1 is taking the
branch from master to develop feature-1 (assume File-1 and File-
3 are going to be changed for the development). So, the
developer can safely commit his changes on both files into the
master branch. Vice versa, When Developer-2 is taking the
branch from master to develop feature-2 (assume File-2 and File-
4 are going to be changed for the development).

Git
/kunchalavikram1427
Branch commands
• Check What Branch You're On: git status
• To see local branches: git branch (The current local branch will be marked with an asterisk (*).
• To see remote branches: git branch -r
• To see all local and remote branches: git branch -a
• Create a New Branch: git branch <branch-name>
• Switch to a Branch In Your Local Repo: git checkout <branch-name>
• Create a branch and checkout: git checkout -b <branch-name>
• Rename a Branch: git branch -m <branch-name>
• To get a list of all branches from the remote: git pull
• Push to a Branch: git push -u origin <branch-name> or git push -u origin HEAD (HEAD is a reference to
the top of the current branch, so it's an easy way to push to a branch of the same name on the remote. This saves you
from having to type out the exact name of the branch!
• If your local branch already exists on the remote: git push
• You'll want to make sure your working tree is clean and see what branch you're on: git status
• git merge <branch-name> (If you want this branch to merge to master, you should already be in master branch
before merging. If not run git checkout master)
• To delete a remote branch : git push origin --delete <branch-name>
• To delete a local branch: git branch -d <branch-name> (or) git branch -D <branch-name> (the -d option
only deletes the branch if it has already been merged. The -D option is a shortcut for --delete --force, which deletes
the branch irrespective of its merged status)

Git
/kunchalavikram1427
Branch commands
• Delete a remote branch: git push origin --delete :<branch-name> or git push origin :<branch_name>
• Rename a local branch by being in the same branch: git branch -m <new-branch-name >
• Rename a local branch by being in another branch: git branch -m <old-branch-name > <new-branch-name >
• If you are in the branch which needs to be renamed in remote, then pass the following command with upstream argument
-u: git push origin -u new-name

Git
/kunchalavikram1427
CLI
• Git can be used using a command line (terminal), or a desktop app that has a GUI (graphical user interface) such as
SourceTree shown next
• I prefer using terminus https://github.com/Eugeny/terminus which is a CLI tool. It directly shows the current git branch as
seen below and has many features like Serial, SSH protocols
• Download it from here https://github.com/Eugeny/terminus/releases/tag/v1.0.132

Git
/kunchalavikram1427
SourceTree
• To visually see every commit and branches, download SourceTree from https://www.sourcetreeapp.com/
• During installation, SourceTree will automatically detect your Git installation
• Once installed, import the git project created or add a remote origin
• As you can see below, during our demo we have made 3 commits to the master branch

Git
/kunchalavikram1427
Branches
• Show current branch. The current local
branch will be marked with an asterisk
(*)
▪ git status
• List all of the branches in your repository
▪ git branch
▪ git branch --list
• Create a new branch dev
▪ git branch dev
• Switch to another branch
▪ git checkout dev
• Create and checkout at once
▪ git checkout -b dev
• Check HEAD (HEAD points out the last
commit in the current checkout branch)
▪ git show head
For making commits to a new branch, you
should be in that branch already! Master
Dev

Git
/kunchalavikram1427
Branches
• Add a new file file6.txt ad check the
status
▪ git status
• Add the file to staging
▪ git add .
• Commit to local
▪ git commit -m "Added Sixth
File to Dev Branch"
• Push to remote dev branch
▪ git push origin dev
• Check log
▪ git log --oneline
Master
Dev
Push the files to origin
HEAD

Git
/kunchalavikram1427
Master
Dev
Branches
• Check your files in the repository in dev branch
HEAD

Git
/kunchalavikram1427
Master
Dev
Branches
• Verify the same in SourceTree
HEAD

Git
Master
Dev
Checkout
Branches
• The git checkout command operates upon three distinct entities: files, commits, and
branches
• The git checkout command lets you navigate between the branches created by git branch
• Checking out a branch updates the files in the working directory to match the version
stored in that branch, and it tells Git to record all new commits on that branch
▪ git checkout master – switches the branch to master and update the files as well
• Since file6.txt is only in dev branch, the file is missing in the master branch
HEAD
/kunchalavikram1427

Git
/kunchalavikram1427
Workflow

/kunchalavikram1427
/kunchalavikram1427
/kunchalavikram1427
PART - 02
Git Pull, Fetch, Clone, Reset, Merge
Conflicts, Cherry pick etc.,

References
• https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified

Kubernetes
/kunchalavikram1427
Subscribe to my Facebook page:
https://www.facebook.com/vikram.devops
and join my group:
https://www.facebook.com/groups/171043094400359
for all latest updates on DevOps, Python and IoT
https://www.youtube.com/channel/UCE1cGZfooxT7-
VbqVbuKjMg

Introduction to Git and GitHub

Introduction to Git and GitHub

Recommended

More Related Content

What's hot (20)

Similar to Introduction to Git and GitHub (20)

Recently uploaded (20)

Introduction to Git and GitHub