GitHub is a web-based hosting service for version control using git. It is mostly used for computer code. It offers all of the distributed version control and source code management (SCM) functionality of Git as well as adding its own features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project

2. Git - GitHub
Presented By:
Nitin Goel

3. About Git
• Created by Linus Torvalds, creator of Linux, in 2005
– Came out of Linux development community
– Designed to do version control on Linux kernel
• Goals of Git:
– Speed
– Support for non-linear development (thousands of parallel branches)
– Fully distributed
– Able to handle large projects efficiently

4. Centralized VCS
• In Subversion, CVS, Perforce, etc.
A central server repository (repo)
holds the "official copy" of the
code
• The server maintains the sole
version history of the repo
• You make "checkouts" of it to
your local copy
• You make local modifications
• Your changes are not versioned
• When you're done, you "check in"
back to the server
• Your check in increments the
repo's version

5. Distributed VCS (Git)
• In git, mercurial, etc., you don't
"checkout" from a central repo, you
"clone" it and "pull" changes from it
• Your local repo is a complete copy of
everything on the remote server
• Yours is "just as good" as theirs
• Many operations are local:
– check in/out from local repo
– commit changes to local repo
– local repo keeps version history
• When you're ready, you can "push"
changes back to server

6. Version Control
• Version control is a system that records changes to a file or set of files over
time so that you can recall specific versions later.
• Allows for collaborative development
• Allows you to know who made what changes and when
• Allows you to revert any changes and go back to a previous state
• Three of the most popular version control systems are:
 Git
 Subversion
 Mercurial

7. Git vs Github
• Git is a revision control system, a tool to manage your source code history.
• Github is a hosting service for Git repositories.

8. Terminology
Version Control System / Source Code Manager
 A version control system (abbreviated as VCS) is a tool that manages different versions of
source code. A source code manager (abbreviated as SCM) is another name for a version
control system.
Commit
 Git thinks of its data like a set of snapshots of a mini file system. Every time you commit (save
the state of your project in Git), it basically takes a picture of what all your files look like at
that moment and stores a reference to that snapshot. You can think of it as a save point in a
game - it saves your project's files and any information about them.
Repository / repo
 A repository is a directory which contains your project work, as well as a few files (hidden by
default on Mac OS X) which are used to communicate with Git. Repositories can exist either
locally on your computer or as a remote copy on another computer. A repository is made up
of commits.

9. Terminology
Working Directory
 The Working Directory is the files that you see in your computer's file system. When you open your project files up
on a code editor, you're working with files in the Working Directory.
 This is in contrast to the files that have been saved (in commits!) in the repository.
Checkout
 A checkout is when content in the repository has been copied to the Working Directory.
Staging Area / Staging Index / Index
 A file in the Git directory that stores information about what will go into your next commit. You can think of the staging area as a prep
table where Git will take the next commit. Files on the Staging Index are poised to be added to the repository.
SHA(Secure Hash Algorithm)
 A SHA is basically an ID number for each commit. Here's what a commit's SHA might look
like: e2adf8ae3e2e4ed40add75cc44cf9d0a869afeb6.
Branch
 A branch is when a new line of development is created that diverges from the main line of development. This
alternative line of development can continue without altering the main line.

10. Install Git on Windows
• Download the latest Git for windows installer.
• When you've successfully started the installer, you should see the Git
Setup wizard screen. Follow the Next and Finish prompts to complete the
installation.
• Open a Command Prompt (or Git Bash if during installation you elected
not to use Git from the Windows Command Prompt).
• Run the following commands to configure your Git. These details will be
associated with any commits that you create.

11. Git Configuration
• # sets up Git with your name
git config --global user.name "<Your-Full-Name>"
• # sets up Git with your email
git config --global user.email "<your-email-address>"
• # makes sure that Git output is colored
git config --global color.ui auto
• # displays the original state in a conflict
git config --global merge.conflictstyle diff3
• git config --list

12. Associating text editors with Git
• Using Atom as your editor
– Install Atom.
– Open Git Bash.
– Type this command:
git config --global core.editor
“C:/Users/USERNAME/AppData/Local/atom/bin/atom.cmd”
Using Sublime Text as your editor
– Install Sublime Text 3.
– Open Git Bash.
– Type this command:
git config --global core.editor "'c:/program files/sublime text 3/subl.exe'
-w"

13. • Using Notepad++ as your editor
– Install Notepad++.
– Open Git Bash.
– Type this command:
git config --global core.editor "'C:/Program Files
(x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -
noPlugin"

14. git init
• Running the git init command sets up all of the necessary files and
directories that Git will use to keep track of everything.
• All of these files are stored in a directory called .git (notice the . at the
beginning - that means it'll be a hidden directory on Mac/Linux).
• This .git directory is the "repo"! This is where git records all of the commits
and keeps track of everything!

15. Local git areas

17. git clone
• The git clone command is used to create an identical copy of an existing
repository.
$ git clone <path-to-repository-to-clone>
This command:
 takes the path to an existing repository
 by default will create a directory with the same name as the repository that's being
cloned
 can be given a second argument that will be used as the name of the directory
 will create the new repository inside of the current working directory

18. git status
• The git status command displays the state of the working directory and the staging
area.
• It lets you see which changes have been staged, which haven’t, and which files
aren’t being tracked by Git.
• Status output does not show you any information regarding the committed project
history.

20. git log
• The git log command is used to display all of the commits of a repository.
• By default, this command displays:
 the SHA
 the author
 the date
 and the message

21. git add
The git add command is used to move files from the Working Directory to the Staging Index.
$ git add <file1> <file2> … <fileN>
This command:
• takes a space-separated list of file names
• alternatively, the period . can be used in place of a list of files to tell Git to add the current
directory (and all nested files)
• git rm --cached <file> command can be used to remove a file from staging Index. This
command will not destroy any of your work, it just removes it from the Staging Index.

22. git commit
The git commit command takes files from the Staging Index and saves them in
the repository.
$ git commit
This command:
• will open the code editor that is specified in your configuration
• (check out the Git configuration step from the first lesson to configure
your editor)
• Inside the code editor:
– a commit message must be supplied
– lines that start with a # are comments and will not be recorded
– save the file after adding a commit message
– close the editor to make the commit
Then, use git log to review the commit you just made!

24. Commit message
Do
• do keep the message short (less than 60-ish characters)
• do explain what the commit does (not how or why!)
Do not
• do not explain why the changes are made (more on this below)
• do not explain how the changes are made (that's what git log -p is for!)
• do not use the word "and"
• if you have to use "and", your commit message is probably doing too many
changes - break the changes into separate commits
• e.g. "make the background color pink and increase the size of the sidebar"

25. git log --oneline
• This command shortens the SHA and commit message to just one line
• Q key is pressed to co come out to regular command prompt

26. git log --stat
 displays the file(s) that have been modified
 displays the number of lines that have been added/removed
 displays a summary line with the total number of modified files and lines
that have been added/removed

27. git log –p or git log --patch
This command adds the following to the default output:
 displays the files that have been modified
 displays the location of the lines that have been added/removed
 displays the actual changes that have been made

28. git show
The git show command will show only one commit.
By default, git show displays:
the commit
the author
the date
the commit message
the patch information

29. git diff
git diff command is used to see changes that have been made but haven't
been committed, yet:
$ git diff
This command displays:
• the files that have been modified
• the location of the lines that have been added/removed
• the actual changes that have been made

31. git ignore
• 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.
– Ignored files are usually build artifacts and machine generated files
that can be derived from your repository source or should otherwise
not be committed. Some common examples are:
 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

32. git tag
• Git has the ability to tag specific points in history as being important.
• Git supports two types of tags: lightweight and annotated.
 A lightweight tag is very much like a branch that doesn’t change — it’s
just a pointer to a specific commit.
git tag v1.0
 Annotated tags are stored as full objects in the Git database. They’re
checksummed; contain the tagger name, email, and date; have a
tagging message; and can be signed and verified with GNU Privacy
Guard (GPG).
git tag -a v1.0 -m “Insert message.“
 To delete tag
git –d v1.0 or git --delete v1.0

33. git branch
• Branch enables programmer to work in the same project in different
isolated environments.
• When it is required to add a new feature or fix a bug—no matter how big
or how small ,a new branch can be created to encapsulate the changes.

34. Commands
• git branch list all of the branches in your repository.
• git branch <branch> create a new branch called <branch>. This
does not check out the new branch.
• git branch -d <branch> delete the specified branch. This is a “safe”
operation in that Git prevents you from deleting the branch if it has
unmerged changes.
• git branch -D <branch> force delete the specified branch, even if it has
unmerged changes.
• git branch -m <branch> rename the current branch to <branch>.
• git checkout <branch> checkout to branch called <branch>.
• git checkout –b <branch> create a new branch called <branch> and
checkout simultaneously.

35. git merge
The git merge command lets you take the independent lines of development
created by git branch and integrate them into a single branch.
git merge <branch>
There are two types of merging:
1. Fast forward merge
2. 3-way merge.

36. Fast forward merge
• A fast-forward merge can occur when there is a linear path from the
current branch tip to the target branch.

37. • Before merge:
• After merge:

38. 3-way merge
• A fast-forward merge is not possible if the branches have diverged. When
there is not a linear path to the target branch, Git has no choice but to
combine them via a 3-way merge. 3-way merges use a dedicated commit
to tie together the two histories.

40. • Before Merge
• After Merge

41. Merge conflict
• If the two branches you're trying to merge both changed the same part of
the same file, Git won't be able to figure out which version to use. When
such a situation occurs, it stops right before the merge commit so that you
can resolve the conflicts manually.
• visual markers to represent conflict are: <<<<<<<, =======, and >>>>>>>.

42. --amend
• Git commit –amend command is used to edit most recent commit.
git commit --amend
• Steps involved are:
– edit the file(s)
– save the file(s)
– stage the file(s)
– and run git commit --amend

43. git revert
The git revert command is used to reverse a previously made commit:
$ git revert <SHA-of-commit-to-revert>
This command:
 will undo the changes that were made by the provided commit
 creates a new commit to record the change

44. git reset
• git reset --option <SHA> command is used to erase commits. There are
three options to reset.
1. –soft (erased commits shifts to staging index)
2. –mixed(default and (erased commits shifts to working directory)
3. –hard(erases directly)

45. Remote repositry
• A remote repository is the same Git repository like yours but it exists
somewhere else.
• Remotes can be accessed in a couple of ways:
– with a URL
– path to a file system
• we can interact and control a remote repository is through the Git remote
command:
– $ git remote

46. git push
• Create a new repository on GitHub. To avoid errors, do not initialize the
new repository with README, license, or .gitignore files. You can add
these files after your project has been pushed to GitHub.
• Open Git Bash.
• Change the current working directory to your local project.
• Initialize the local directory as a Git repository.
– git init
• Add the files in your new local repository. This stages them for the first
commit.
– git add .
• Commit the files that you've staged in your local repository.
– git commit -m "First commit"

47. • Copy remote repository URL field at the top of your GitHub repository's
Quick Setup page, click to copy the remote repository URL.
• In the Command prompt, add the URL for the remote repository where
your local repository will be pushed.
-git remote add origin remote repository URL
• git remote –v command verifies the new remote URL
• Push the changes in your local repository to GitHub.
-git push origin master
# Pushes the changes in your local repository up to the remote repository you
specified as the origin

48. git fetch or git pull
• The git fetch command downloads commits, files, and refs from a remote
repository into your local repo. Git isolates fetched content as a from
existing local content, it has absolutely no effect on your local
development work.
– git push origin master
– git fetch origin master
• This makes fetching a safe way to review commits before integrating them
with your local repository.
• git fetch is the 'safe' version of the two commands. It will download the
remote content but not update your local repo's working state, leaving
your current work intact. git pull is the more aggressive alternative, it will
download the remote content for the active local branch and immediately
execute git merge to create a merge commit for the new remote content.

49. Thank You