Zeeshan Hanif

Director/CTO Panacloud
PIAIC
Book we will
follow
 What is Version Control System?

❖ A software utility that tracks and manages changes to a

filesystem.
❖ Also known as revision control or source control system
❖ It's a management of changes to documents, computer
programs, large websites and other collection of
information
 What is Version Control System?

❖ A VCS also offers collaborative utilities to share and

integrate these filesystem changes to other VCS users.
❖ VCS will track the addition, deletion, and modification
actions applied to files and directories
❖ A repository is a VCS term which describes when VCS is
tracking a filesystem.
 What is Version Control System?

❖ VCS options include Git, Mercurial, SVN and preforce.

❖ You can think of a VCS as a kind of “database”.
❖ It lets you save a snapshot of your complete project at any
time you want
❖ When you later take a look at an older snapshot your VCS
shows you exactly how it differed from the previous one
 What is Version Control System?

❖ Version control is independent of the kind of project /

technology / framework you‘re working with
❖ It works just as well for an HTML website as it does for a
design project or an iPhone app
❖ It lets you work with any tool you like; it doesn‘t care what
kind of text editor, graphics program, file manager or other
tool you use
Why Use a Version Control System?

❖ Collaboration
➢ Without a VCS in place, you‘re probably working together in a
shared folder on the same set of files.
➢ And you have to coordinate with others so that they don’t work on
same file, it will be very difficult to manage
➢ With a VCS, everybody on the team is able to work absolutely freely
- on any file at any time.
➢ The VCS will later allow you to merge all the changes into a
common version.
 Why Use a Version Control System?

❖ Storing Versions (Properly)

➢ Saving a version of your project after making changes is an
essential habit. But without a VCS, this becomes tedious and
confusing very quickly:
■ How much do you save? Only the changed files or the complete
project?
■ How do you name these versions? “myapp_2013-11-12_v23”
■ The most important question: How do you know what exactly is
different in these versions?
 Why Use a Version Control System?

❖ Storing Versions (Properly) (cont…)

➢ Version control system acknowledges that there is only one project
➢ Therefore, there‘s only the one version on your disk that you‘re
currently working on
➢ Everything else - all the past versions and variants - are neatly
packed up inside the VCS
➢ When you need it, you can request any version at any time and
you‘ll have a snapshot of the complete project right at hand.
 Why Use a Version Control System?

❖ Restoring Previous Versions

➢ Being able to restore older versions of a file or whole project
➢ If the changes you‘ve made
➢ lately prove to be garbage, you can simply undo them in a few
clicks
Why Use a Version Control System?

❖ Understanding What Happened

➢ Every time you save a new version of your project, your VCS
requires you to provide a short description of what was changed
➢ Additionally (if it‘s a code / text file), you can see what exactly was
changed in the file‘s content
Why Use a Version Control System?

❖ Backup
➢ A side-effect of using a distributed VCS like Git is that it can act as
a backup
➢ every team member has a full-blown repository of the project on
his disk
➢ If central server break down (and your backup drives fail), all you
need for recovery is one of your teammates’ local Git repository.
 ❖ VSS
Different Types
Of Version
Control Systems ❖ SVN

❖ GIT
 Microsoft Visual SourceSafe
VSS
(VSS) is a source control
program, oriented towards
small software development
projects.
 SVN is the abbreviated form
SVN of “Apache Subversion” and
is a popular version control
system tool. It is a
centralized version control
system
 Git is a distributed
version-control system for
tracking changes in source
GIT
code during software
development. It is designed
for coordinating work among
programmers, but it can be
used to track changes in any
set of files.
 ❖ Centralized Version
Types of Version
Control System (CVCS)
Control Systems

❖ Distributed Version
Control System (DVCS)
 Centralized version control
Centralized system (CVCS) uses a
central server to store all files
Version Control
and enables team
System (CVCS) collaboration. It works on a
single repository to which
users can directly access a
central server.
 Every programmer can
Centralized extract or update their
workstations with the data
Version Control
present in the repository or
System (CVCS) can make changes to the
data or commit in the
repository. Every operation is
performed directly on the
repository.
 ❖ It is not locally available;
meaning you always need to
be connected to a network
CVCS Drawbacks to perform any action.

❖ Since everything is
centralized, in any case of
the central server getting
crashed or corrupted will
result in losing the entire
data of the project.
 Distributed
Version Control These systems do not
System (DVCS) necessarily rely on a central
server to store all the
versions of a project file.
 In Distributed VCS, every
Distributed contributor has a local copy
or “clone” of the main
Version Control
repository i.e. everyone
System (DVCS) maintains a local repository
of their own which contains
all the files and metadata
present in the main
repository.
 Distributed
Version Control
System (DVCS) GIT is Distributed version
Control System
 Every programmer maintains
Distributed a local repository on its own,
Version Control which is actually the copy or
System (DVCS) clone of the central
repository on their hard drive.
They can commit and update
their local repository without
any interference
 Programmer can update their
Distributed local repositories with new
Version Control data from the central server
System (DVCS) by an operation called “pull”
and affect changes to the
main repository by an
operation called “push” from
their local repository.
 Distributed
Version Control All operations (except push &
pull) are very fast because
System (DVCS)
the tool only needs to access
the hard drive, not a remote
Advantages server. Hence, you do not
always need an internet
connection.
 Distributed
Version Control Committing new change-sets
can be done locally without
System (DVCS)
manipulating the data on the
main repository. Once you
Advantages have a group of change-sets
ready, you can push them all
at once.
 Distributed Since every contributor has a
Version Control full copy of the project
System (DVCS) repository, they can share
changes with one another if
Advantages they want to get some
feedback before affecting
changes in the main
repository.
 Distributed
Version Control If the central server gets
System (DVCS) crashed at any point of time,
the lost data can be easily
Advantages recovered from any one of
the contributor’s local
repositories.
 Git is a distributed
version-control system for

Git tracking changes in source

code during software
development

Everything we learned about

Distributed version control
system is applicable on GIT
 Installing and Setting Up Git

❖ Go to https://git-scm.com/downloads
❖ Installation Guide:
➢ https://git-scm.com/book/en/v2/Getting-Started-Installi
ng-Git
❖ For Linux:
➢ https://git-scm.com/download/linux
❖ For Windows:
➢ https://git-scm.com/download/win
 Installing and Setting Up Git

❖ For windows after download

➢ Double click on exe file and follow the installation
wizard
➢ Do not change anything just keep the default setting
and press next on every step
➢ It will install git on your machine
 Installing and Setting Up Git

❖ Open Terminal and run following commands to setup your

name and email id
➢ git config --global user.name “Your Name”
➢ git config --global user.email “Your Email”
Installing and Setting Up SmartGit GUI Tool

❖ Go to https://www.syntevo.com/smartgit/download
❖ Download SmartGit
❖ Install SmartGit with all default settings
Basic operations ❖ Initialize
in Git are ❖ Add
❖ Commit
❖ Pull
❖ Push
Advanced Git
operations ❖ Branching
❖ Merging
❖ Rebasing
Git
Operations
 ❖ Think of a repository as a
kind of database where your
Important Terms VCS stores all the versions
and metadata that
1. Repository accumulate in the course of
your project.
❖ In Git, the repository is just a
simple hidden folder named
“.git” in the root directory of
your project
Important Terms
The root folder of your
project is often called the
2. Working “working copy” (or “working
Directory directory”). It‘s the directory
on your local computer that
contains your project‘s files.
Important Terms

3. File Status
 Staging area is a virtual place
Important Terms that collects all the files you
want to include in the next
4. Staging Area commit

In Git, simply making some

changes doesn‘t mean
they‘re automatically
committed.
 Every commit is
Important Terms “hand-crafted”: each change
that you want to include in
4. Staging Area the next commit has to be
marked explicitly (“added to
the Staging Area” or, simply
put, “staged”)
Basic Workflow
Starting with an Unversioned, Local Project

1. Open terminal and create directory on your machine

a. C:\Repo\myproject
2. Go into directory in terminal
3. Initialize repository in this directory
a. git init
b. This will create .git hidden folder in your directory which
will make your current folder, a git repository
Starting with an Unversioned, Local Project

4. Create first.txt and second.txt

5. Check status, it will show you two untracked files
a. git status
6. Add these files to staging area
a. Two ways to add files in staging
i. git add first.txt second.txt OR
ii. git add .
Starting with an Unversioned, Local Project

4. Commit your files to VCS with commit message

a. git commit -m “implemented new feature”
5. Commit message is very important, you should provide
proper commit message so that it can be refer back to
identify what was added in that commit
6. Check logs to see commit history
a. git log
Demo with
Terminal
Demo with
Smartgit UI
HEAD shows last commit
New and changed files will be part of next
commit
git add command add files in staging area
After commit, our new commit will be HEAD
Commit Hash ❖ Every commit has a
unique identifier: a
40-character checksum
called the “commit hash”.
 ❖ As multiple people can
work in parallel,
committing their work
Commit Hash offline, without being
connected to a shared
repository
❖ Therefore commit Hash
helps in identifying which
user made specific
commit
 git reset
❖ git reset command will
remove file from staging
Unstage files or area
remove change ❖ git reset can remove
changes in files if the are
not commited
 git reset

Unstage files or ❖ git rest

remove change ❖ git reset --hard
Demo with
Terminal
Demo with
Smartgit UI
 ❖ Typically, in every project
and on every platform,
there are a couple of files
Ignoring Files that you don‘t want to be
version controlled
❖ E.g
➢ .DS_Store
➢ Node_modules
➢ Build
➢ logs
 ❖ Create an empty file in
your favorite editor and
save it as ”.gitignore” in
Ignoring Files
your project‘s root folder.
❖ You can define rules in
“.gitignore” file to ignore
files
❖ Add file or directory path
or extension or name
 Ignoring Files -- Examples

❖ Ignore one specific file

➢ path/to/file.ext
❖ Ignore all files with a certain name (anywhere in the
project)
➢ filename.ext
❖ Ignore all files of a certain type (anywhere in the project)
➢ *.ext
❖ Ignore all files in a certain folder:
➢ path/to/folder/*
Demo with
Terminal
Demo with
Smartgit UI
Branching and
Merging
 Why branches are important

❖ In every project, there are always multiple different contexts

where work happens
❖ Each feature, bugfix, experiment, or alternative of your
product is actually a context of its own
❖ There can me unlimited amount of different contexts
❖ Most likely, you‘ll have at least one context for your “main”
or “production” state, and another context for each feature,
bugfix, experiment, etc.
 Why branches are important

❖ In real-world projects, work always happens in multiple of

these contexts in parallel:
➢ While you‘re preparing two new variations of your website‘s design
(context 1 & 2)
➢ you‘re also trying to fix an annoying bug (context 3).
➢ On the side, you also update some content on your FAQ pages (context 4)
➢ one of your teammates is working on a new feature for your shopping cart
(context 5)
➢ and another colleague is experimenting with a whole new login
functionality (context 6).
Why branches are important

❖ Another example
➢ Production, development and feature context
➢ Production code is tested and deployed and we don’t want
any problem in that
➢ Development team is working on new feature and we don’t
want that feature to effect production code until it is properly
tested
➢ All feature combines in development to have final testing
before deployment
 ❖ Branches are what we
need to solve context
Branches to the problems.
Rescue ❖ Because a branch
represents exactly such a
context in a project and
helps you keep it separate
from all other contexts.
Branches to the Rescue
 Branches to the Rescue

❖ All the changes you make at any time will only apply to the
currently active branch; all other branches are left
untouched
❖ This gives you the freedom to both work on different things
in parallel and, above all, to experiment - because you can‘t
mess up!
❖ In case things go wrong you can always go back / undo /
start fresh / switch contexts
 Working with Branches

❖ Without knowing, we were already working on a branch.

❖ This is because branches aren‘t optional in Git: you are
always working on a certain branch (the currently active, or
“checked out”, or “HEAD” branch).
❖ Check ‘git status’ and it will show you current branch
❖ The “master” branch was created by Git automatically for
us when we started the project.
 Working with Branches

❖ ‘master’ branch does not mean anything special

❖ It is initially created when we start project
❖ ‘HEAD’ always represent current branch
 ❖ git branch
➢ Show list of branches
Branch ❖ git branch -v
Commands ➢ Show list of branches
with some details
❖ git branch new-dev
➢ Creates new branch with
name ‘new-dev’
❖ Git checkout new-dev
➢ Switch to ‘new-dev’
branch
 ❖ git merge new-dev
➢ Merge ‘new-dev’ branch
Branch into current active
Commands branch
❖ git log new-dev..master
➢ Show commit difference
in two branches
 git checkout contact-form

❖ git checkout move you to other branch and HEAD represent

that branch
 Merging Changes

❖ You can merge all your commits in your branch into

another branch by git merge command
Demo with
Terminal
Demo with
Smartgit UI
 ❖ Commit wraps up
Stash changes and saves them
permanently in the
repository
❖ Stash save changes
temporarily
 ❖ If you want to switch to
another branch without
commiting changes in
Stash current branch
❖ You will need to save your
changes somewhere so
that you have clean
working directory
❖ Stash will work in this
case
 ❖ Later, at any time, you can
restore the changes from
Stash stash in your working
copy - and continue
working where you left
off.
❖ You can create as many
Stashes as you want
 ❖ git stash
➢ Save local changes
stash clipboard
Stash Commands ❖ git stash save <name>
➢ Save local changes in
stash clipbaord with
the name provided in
command
❖ git stash list
➢ Show list of stashes
 ❖ git stash pop
➢ Apply latest stash and
Stash Commands
remove it from clipboard
❖ git stash apply stashname
➢ Apply specific stash and
that stash will remain
saved in clipboard
Demo with
Terminal
Demo with
Smartgit UI
 Short-Lived /
❖ They are about a single
Topic Branches topic or feature and once
work done with them they
are removed
 ❖ Branch that are higher level
and independent of any
Long-Running
feature, remain for longer
Branches time
❖ They represent states in
your project lifecycle - like a
❖ “production”, “testing”, or
“development” state
 Remote
Repositories
 Remote Repositories

❖ About 90% of version control related work happens in the

local repository: staging, committing, viewing the status or
the log/history, etc.
❖ If you're the only person working on your project, chances
are you'll never need to set up a remote repository.
❖ Only when it comes to sharing data with your teammates, a
remote repo comes into play.
 Remote Repositories

❖ Think of it like a "file server" that you use to exchange data

with your colleagues.
❖ Local repositories reside on the computers of team
members. In contrast, remote repositories are hosted on a
server that is accessible for all team members - most likely
on the internet or on a local network.
 Remote Repositories

❖ For remote repository you have to first select the online

service that offer git and allow you to create remote
repository
❖ Following are few online services:
➢ GitHub (https://github.com)
➢ BitBucket (https://bitbucket.org)
➢ GitLab (https://gitlab.com)
➢ Many others
❖ Github is online service for
git to create remote
repositories on github’s
server and collaborate with
teammates/colleague
Setting up a new GitHub account
Create New Repository
Create New
Repository
Cloning a
repository

Copy the url in

popup
 Cloning a repository

❖ Go to the local root folder, C:\Repos, for the repositories.

❖ Open a terminal within it.
❖ Type git clone
https://github.com/zeeshanhanif/MyProject.git
 Work on remote repository

❖ After clone, make changes to your project on your local

machine
❖ Add file or change a file
❖ Add file to staging area by git add .
❖ Commit file git commit -m “updated feature”
❖ Run command “git push” to push your change to remote
repository on server
 ❖ git push
➢ Push changes to
Commands to remote repository
interact remote ❖ git fetch
repository ➢ Fetch changes from
remote repository
❖ git merge
➢ Merge changes that
was fetch by ‘git fetch’
command
 ❖ git pull
Commands to ➢ Fetch and merge
interact remote changes from remote
repository repository
❖ git remote -v
➢ Show remote urls
❖ git remote show origin
➢ Show details of origin
 Commands to ❖ “git remote add myremote
interact remote https://github.com/zeesh
repository anhanif/MyProject.git”

This command will add

remote repo in local
repository
Demo Basic clone
and push pull with
Terminal
Demo Basic clone
and push pull with
Smartgit UI
 Publish a local repository to GitHub

❖ If you already have local repository on your machine and

want to connect it with remote repository then:
➢ Create repository on github
➢ Open terminal in your local repository
➢ Run following command
➢ git remote add origin
https://github.com/zeeshanhanif/MyProject.git
➢ git push -u origin master
 Publish a local repository to GitHub

❖ git push -u origin master

➢ The “-u” flag establishes a tracking connection between
remote and our local
 ❖ git push ‘remote’ ‘branch’
Commands to ➢ git push origin master
interact remote ❖ Git push command
repository require which remote
repository you want to
push and in which branch
of remote repository
 ❖ git log
➢ Show logs for current
Commands to branch
interact remote ❖ git log remote/branch
repository ➢ git log origin/master
❖ In git log command you
specify remote repository
and branch so it will show
logs from that branch of
remote.
Demo with
Terminal
Demo with
Smartgit UI
 ❖ git branch work
Pushing a local ➢ This will create new
branch to a branch ‘work’ on local
remote repo
repository ❖ git checkout work
➢ Switch to ‘work’
branch
❖ Make changes
❖ git push -u origin work
Demo with
Terminal
Demo with
Smartgit UI
 ❖ When working in team we
want follow some rules
Git workflow and style to work on
git-flow project.
❖ For this we should follow
branching model in where
there should be specific
branches for specific
purpose
 ❖ Branches (example)
➢ master
Git workflow ➢ development
git-flow ➢ feature/rss-feed
➢ hotfix/missing-link
 ❖ When working in team we
want to review code of
Git workflow team members and
git-flow merge code in main
branch only after that.
❖ For this purpose github
provide pull request
feature.
❖ In professional projects
you will see the very often
Demo
 ❖ First, remember that fork
Social Coding is not a Git feature, but a
- GitHub invention
Forking a ❖ When you fork on GitHub,
repository you get a server-side
clone of the repository on
your GitHub account
 ❖ When you want to work
Social Coding on someone else’s
- repository on which you
Forking a don’t have write access,
repository you create fork of it
❖ This is mostly done with
public projects, where
community contributes
 ❖ When you fork that
Social Coding means you are creating
- copy of someone else’s
Forking a repo on github into your
repository github account.
❖ This happens on server
side directly on github
❖ Then you can clone the
repo from your account
 ❖ After clone you can work
Social Coding on repo as it is your repo
- ❖ Make changes, commit
Forking a push/pull all happens in
repository your repo
❖ Only when you want to
contribute your changes
to original repo you can
create pull request
 ❖ A pull request is a way to
Social Coding tell the original author,
- "Hey! I did something
Forking a interesting using your
repository original code. Do you
want to take a look and
integrate my work, if you
find it good enough?"
 ❖ As you are not contributor
Social Coding to the project you can
- only submit your work to
Forking a original repo with pull
repository request
❖ Author of original repo
has rights to accept or
reject or you changes
Demo
 Deleting Branches

❖ When you are done with a branch and it is no longer needed

then you can delete the branch
➢ git branch -d contact-form
❖ Deleting remote branch, add “r” flag
➢ git branch -dr origin/contact-form
Demo
 Undoing Local Changes

❖ If you have local changes that are not committed and want
discard change then you can use following commands
❖ Discard changes in single file
➢ git checkout HEAD <file/to/restore>
❖ Discard all changes that are not committed (already
learned previously)
➢ git reset --hard HEAD
Demo
Undoing Committed
Changes
 Undoing Committed Changes

❖ Once code is committed and you feel your changes were

wrong and you want to undo commits
❖ You can undo committed changes using following
commands:
➢ git revert <commitHash>
➢ git reset --hard <commitHash>
 git revert <commitHash>

❖ This command does not actually delete any commit.

❖ Instead it reverts the effects of a certain commit,
effectively undoing it.
❖ It does this by producing a new commit with changes that
revert each of the changes in that unwanted commit.
❖ For example, if your original commit added a word in a
certain place, the reverting commit will remove exactly this
word, again.
 git revert <commitHash>

❖ For example: git revert 2b504be

 git reset --hard <commitHash>

❖ It neither produces any new commits nor does it delete any

old ones.
❖ It works by resetting your current HEAD branch to an older
revision (also called “rolling back” to that older revision):
❖ If you call it with “--keep” instead of “--hard”, all changes
from rolled back revisions will be preserved as local
changes in your working directory.
 git reset --hard <commitHash>

❖ For example: git reset --hard 2be18d9

❖ Preserved as local changes : git reset --keep 2be18d9
Demo
Rebase
 Rebase as an Alternative to Merge

❖ Merging is definitely the easiest and most common way to

integrate changes.
❖ But merging is not the only one: “Rebase” is an alternative
means of integration.
❖ Rebasing is quite a bit more complex than merging
 Rebase Two possibilities
--
Understand
merge first ❖ Fast-Forward

❖ Merge Commit
 ❖ In very simple cases, one
Understand of the two branches
doesn‘t have any new
merge first :
commits since the
Fast-Forward branching happened - its
latest commit is still the
common ancestor.
Understand merge first : Fast-Forward

❖ Only one branch has new commits

 Understand merge first : Fast-Forward

❖ In this case, performing the integration is dead simple

❖ Git can just add all the commits of the other branch on top
of the common ancestor commit.
❖ In Git, this simplest form of integration is called a
“fast-forward” merge. Both branches then share the exact
same history.
 Understand merge first : Fast-Forward

❖ Both branch have same history after fast-forward

Demo
 Understand
❖ In a lot of cases, however,
merge first :
both branches moved
Merge Commit forward individually.
❖ And can have different
commits
 Understand merge first : Merge Commit

❖ Both branches have commits that are done after branch

created
 Understand merge first : Merge Commit

❖ To make an integration, Git will have to create a new

commit that contains the differences between them - the
merge commit.
 Understand merge first : Merge Commit

❖ Git automatically created merge commit “C5”

Demo
 Rebase

❖ Sometimes we prefer to go without such automatic merge

commits.
❖ We want the project’s history to look as if it had evolved in a
single, straight line.
❖ No indication remains that it had been split into multiple
branches at some point.
Rebase
 Rebase

❖ Let‘s walk through a rebase operation step by step.

❖ The scenario is the same as in the previous examples: we
want to integrate the changes from branch-B into branch-A,
but now by using rebase.
Rebase

❖ Same scenario as we did with Merge

 Rebase
Command ❖ git rebase <BranchName>
❖ git rebase branch-B
 Rebase -- Step 1

❖ First, Git will “undo” all commits on branch-A that happened

after the lines began to branch out (after the common
ancestor commit).
❖ However, of course, it won’t discard them: instead you can
think of those commits as being “saved away temporarily”.
Rebase -- Step 1

❖ Undo all commits on branch-A after common ancestor

 Rebase -- Step 2

❖ Next, it applies the commits from branch-B that we want to

integrate. At this point, both branches look exactly the
same.
 Rebase -- Step 3

❖ In the final step, the new commits on branch-A are now

reapplied - but on a new position, on top of the integrated
commits from branch-B (they are re-based).
❖ The result looks like development had happened in a
straight line.
❖ Instead of a merge commit that contains all the combined
changes, the original commit structure was preserved.
❖
 Rebase -- Step 3

❖ Applying Branch A commits in the end

 The Pitfalls of Rebase

❖ Of course, using rebase isn‘t just sunshine and roses. You

can easily shoot yourself in the foot if you don‘t mind an
important fact: rebase rewrites history.
❖ As you might have noticed in the last diagram above,
commit “C3*” has an asterisk symbol added.
❖ This is because, although it has the same contents as “C3”,
it‘s effectively a different commit.
 The Pitfalls of Rebase

❖ The reason for this is that it now has a new parent commit
(C4, which it was rebased onto, compared to C1, when it
was originally created).
❖ Rewriting history in such a way is unproblematic as long as
it only affects commits that haven‘t been published, yet
❖ If it is published then, some other developer might have
based his work on on original C3, this will make it more and
more complex
 The Pitfalls of Rebase

❖ Therefore, you should use rebase only for cleaning up your

local work - but never to rebase commits that have already
been published.
Demo
Markdown
 Markdown

❖ Markdown is a lightweight markup language that you can

use to add formatting elements to plaintext text
documents.
❖ Created by John Gruber in 2004, Markdown is now one of
the world’s most popular markup languages.
❖ Markdown is often used to format readme files, for writing
messages in online discussion forums, and to create rich
text using a plain text editor.
GitHub Flavored ❖ Github release its own
markdown language
Markdown
based on original
(GFM) markdown
❖ So to format readme file
we can use markdown
syntax
Basic writing and formatting syntax

❖ Heading
❖ Styling text
❖ Quoting text
❖ Quoting code
❖ Links
❖ List
❖ Task List
Heading
❖ To create a heading, add
one to six # symbols before
your heading text.
Styling text
❖ You can indicate emphasis
with bold, italic, or
strikethrough text.
Quoting text
❖ You can quote text with a >
Quoting code ❖ You can call out code or a
command within a sentence
with single backticks. The
text within the backticks will
not be formatted.
 ❖ You can create an inline link
by wrapping link text in
Links brackets [ ], and then
wrapping the URL in
parentheses ( ). You can
also use the keyboard
shortcut command + k to
create a link.
Lists
❖ You can make an unordered
list by preceding one or
more lines of text with - or *
Nested Lists
❖ You can create a nested list
by indenting one or more list
items below another item.
Task lists ❖ To create a task list, preface
list items with a regular
space character followed by
[ ]. To mark a task as
complete, use [x]
Demo
Resources

❖ https://www.amazon.com/Learn-Version-Control-step-step/dp/1
520786506
❖ https://www.git-tower.com/learn/git/ebook
❖ https://git-scm.com/book/en/v2/Git-Branching-Rebasing
❖ http://git-scm.com/book/en/v2/Git-Branching-Remote-Branche#
Tracking-Branches
❖ https://help.github.com/en/articles/basic-writing-and-formatting
-syntax
Zeeshan Hanif
Director/CTO Panacloud
PIAIC