Git - Part 1

Basic
Version control system ● Version control systems are a category of
software tools that help a software team
manage changes to source code over time.
● Ability to have unlimited number of developers
working on the same code base.
● Easily revert back your files if something
happened.
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 checkin increments the repo's version
Distributed VCS

● 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
What is Git ● By far, the most widely used modern version
control system in the world today is Git.
● The raw performance characteristics of Git
are very strong when compared to many
alternatives. Committing new changes,
branching, merging and comparing past
versions are all optimized for performance
Local git areas

● In your local copy on git, files can be:

○ In your local repo (committed)
○ Checked out and modified, but not yet
committed (working copy)
○ Or, in-between, in a "staging" area
■ Staged files are ready to be committed.
■ A commit saves a snapshot of all staged
state.
Basic Git workflow

● Modify files in your working directory.

● Stage files, adding snapshots of them to your
staging area.
● Commit, which takes the files in the staging
area and stores that snapshot permanently to
your Git directory.
Git commit checksums ● In Subversion each modification to the central
repo increments the version # of the overall
repo.
○ In Git, each user has their own copy of the repo,
and commits changes to their local copy of the
repo before pushing to the central server.
○ So Git generates a unique SHA-1 hash (40
character string of hex digits) for every commit.
○ Refers to commits by this ID rather than a
version number.
○ Often we only see the first 7 characters:
■ 1677b2d Edited first line of readme
■ 258efa7 Added line to readme
■ 0e52da7 Initial commit
Initial Git configuration ● Set the name and email for Git to use when you
commit:
○ git config --global user.name "Test User"
○ git config --global user.email
[email protected]
○ You can call git config –list to verify these are
set.
● Set the editor that is used for writing commit
messages:
○ git config --global core.editor nano(it is vim by
default)
Creating a Git repo ● To create a new local Git repo in your current
directory:
○ git init
■ This will create a .git directory in your
current directory.
■ Then you can commit files in that
directory into the repo.
○ git add filename
○ git commit –m "commit message"
● To clone a remote repo to your current
directory:
○ git clone url localDirectoryName
■ This will create the given local directory,
containing a working copy of the files
from the repo, and a .git directory (used to
hold the staging area and your actual
local repo)
Add and commit a file ● The first time we ask a file to be tracked, and
every time before we commit a file, we must
add it to the staging area:
○ git add Hello.java Goodbye.java
■ Takes a snapshot of these files, adds
them to the staging area.
■ In older VCS, "add" means "start tracking
this file." In Git, "add" means "add to
staging area" so it will be part of the next
commit.
● To move staged changes into the repo, we
commit:
○ git commit –m "Fixing bug #22"
● To undo changes on a file before you have
committed it:
○ git reset HEAD -- filename (unstages the file)
○ git checkout -- filename (undoes your changes)
○ All these commands are acting on your local
version of repo.
Viewing/undoing ● To view status of files in working directory and
staging area:

changes ●
○ git status or git status –s (short version)
To see what is modified but unstaged:
○ git diff
● To see a list of staged changes:
○ git diff --cached
● To see a log of all changes in your local repo:
○ git log or git log --oneline (shorter version)
■ 1677b2d Edited first line of readme
■ 258efa7 Added line to readme
■ 0e52da7 Initial commit
○ git log -5 (to show only the 5 most recent
updates), etc.
Merge conflicts
Interaction w/ remote ●
●
Push your local changes to the remote repo.
Pull from remote repo to get most recent

repo changes.(fix conflicts if necessary, add/commit

them to your local repo)
● To fetch the most recent updates from the
remote repo into your local repo, and put them
into your working directory:
○ git pull origin master
● To put your changes from your local repo in the
remote repo:
○ git push origin master
Questions?
Thank
You.