Git Hub

Software development platform

Kishore A
16 November 2019
Agenda

 Types of Version Control Systems (Local, Centralized , Distributed)

 Git Basics
 Steps to get your project into Git
 Three States
 Recording changes to the repository
 Checking the status of your Files
 Viewing Staged and Unstages changes
 Committing your Changes
 Working with remotes
 Branching
 Merging

CUSTOMER 2
Customer
Version Control System
 Version control is a system that records changes to a file or set of files.
 The following are the types of version control systems:

1.Local Version Control System

Ex: RCS(Revision Control System)

2.Centralized Version Control System

Ex: CVS(Concurrent Versions System), Subversion

3.Distributed Version Control System

CUSTOMER
Ex: Git Customer
3
Local VCS
 Many people’s version-control method of choice is to copy files into another directory
(perhaps a time-stamped directory, if they’re clever).

 This approach is very common because it is so simple, but it is also incredibly error
prone. It is easy to forget which directory you’re in and accidentally write to the wrong file
or copy over files you don’t mean to.

 To deal with this issue, programmers long ago developed local VCSs that had a simple
database that kept all the changes to files under revision control.

CUSTOMER 4
Customer
Local VCS

CUSTOMER 5
Customer
Centralized Version Control Systems

 The next major issue that people encounter is that they need to collaborate with
developers on other systems.

 To deal with this problem, Centralized Version Control Systems (CVCSs) were
developed.

 These systems (such as CVS, Subversion, and Perforce) have a single server that
contains all the versioned files, and a number of clients that check out files from that
central place.

CUSTOMER 6
Customer
Centralized Version Control Systems

CUSTOMER 7
Customer
Centralized Version Control Systems

 However, this setup also has some serious downsides.

 The most obvious is the single point of failure that the centralized server represents.

 If that server goes down for an hour, then during that hour nobody can collaborate at
all or save versioned changes to anything they’re working on.

 If the hard disk the central database is on becomes corrupted, and proper backups
haven’t been kept, you lose absolutely everything — the entire history of the project except
whatever single snapshots people happen to have on their local machines.

 Local VCS systems suffer from this same problem — whenever you have the entire
history of the project in a single place, you risk losing everything.

CUSTOMER 8
Customer
 Distributed Version Control Systems

 In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the
latest snapshot of the files; rather, they fully mirror the repository, including its full history.

 So if any server dies, and these systems were collaborating via that server, any of the
client repositories can be copied back up to the server to restore it.

 Every clone is really a full backup of all the data

CUSTOMER 9
Customer
Distributed Version Control Systems

CUSTOMER 10
Customer
Git Basics ( What is Git )

 Git is a free and open source distributed version control system designed to handle
everything from small to very large projects with speed and efficiency.

 It was initially designed and developed by Linus Torvalds for linux kernel
development.

 Now it is maintained by Junio Hamano.

 Every Git working directory contains a full-fledged repository with complete history
and full revision tracking capabilities.

 It is not dependent on network access or a central server.

CUSTOMER 11
Customer
Installing Git

 Downloading Git for Windows

https://git-scm.com/download/win

 Download Git reference Book

https://git-scm.com/book/en/v2

 Download Git for Linux and Unix

https://git-scm.com/download/linux

CUSTOMER 12
Customer
Steps to get your project into Git
There are two steps to get the project into the git.

Step 1 : Cloning the existing Git repository from the server to yourlocal git repository.
Commands:

git clone git://github.com/schacon/grit.git(URL)

Step 2 : Import the existing project or directory into your localgit repository and push into the
remote git repository.

Commands:

git init // Create an empty Git repository or reinitialize an existing one

git add // Add file contents to the index
git commit -m ‘ initial version’ // Record changes to the local repository
git push origin master // Push the code into remote repository
CUSTOMER 13
Customer
Git on the Server

At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git.

However, in order to do any collaboration in Git, you’ll need to have a remote Git repository.

You have several options to get a remote Git repository up and running so that you can
collaborate with others or share your work.

CUSTOMER 14
Customer
CUSTOMER 15
Customer
What is GitHub?

GitHub is an American company that provides hosting for software development version control
using Git.

GitHub lets you (and others) work together on projects.

Sign up for GitHub at https://github.com/:

CUSTOMER 16
Customer
17
18
19
GitHub essentials are:

Repositories

Branches

Commits

Push and Pull Requests

Git (the version control software GitHub is built on)

20
Repository

A GitHub repository can be used to store a development project.

It can contain folders and any type of files (HTML, CSS, JavaScript, Documents, Data, Images).

A GitHub repository should also include a licence file and a README file about the project.

A GitHub repository can also be used to store ideas, or any resources that you want to share.

21
Branch

A GitHub branch is used to work with different versions of a repository at the same time.

By default a repository has a master branch (a production branch).

Any other branch is a copy of the master branch (as it was at a point in time).

New Branches are for bug fixes and feature work separate from the master branch. When
changes are ready, they can be merged into the master branch. If you make changes to the master
branch while working on a new branch, these updates can be pulled in.

22
Commits

At GitHub, changes are called commits.

Each commit (change) has a description explaining why a change was made.

Push

The git push command is used to upload local repository content to a remote repository.

Pushing is how you transfer commits from your local repository to a remote repo.

23
Pull Request

 Pull Requests are the heart of GitHub collaboration.

 With a pull request you are proposing that your changes should be merged (pulled in) with the
master.

Pull requests show content differences, changes, additions, and subtractions in colors (green
and red).

As soon as you have a commit, you can open a pull request and start a discussion, even before
the code is finished.

24
Three main states of a Git

25
Three main states of a Git

26
Recording Changes to the Repository

27
Thank You