Introduction to Git (part 1)

Introduction to
Git
@parallelit
(part 1)

Agenda
• Git References
• SourceTree conﬁguration
• Git history
• working directory, Git
directory, staging area
• File Status Lifecycle
• git init, clone, checkout, add,
commit, blame, log, status,
pull, fetch, push, archive
• gitignore
• Git in action
• HEAD or head?
• Fast-forward Merge
• Tracked branches
• Tagging
• git commit --amend

Git References
• https://www.atlassian.com/git/
• https://git-scm.com/documentation
• http://www.vogella.com/tutorials/Git/article.html

Git history
• Git repository is one giant graph
• Node := a Git commit is a node in a graph

SourceTree conﬁguration (1)
• Fullname
• Email address
• Project folder

SourceTree conﬁguration (2)
• Visual Diff Tool
• Merge Tool

What is a branch?
A branch represents an independent line of
development.

• git init := Create an empty Git repository or
reinitialize an existing one
• git clone := Clone a repository into a new
directory from remote Git server
• git checkout := Switch branches or restore
working tree ﬁles

• git add := Add ﬁle contents to the index (staging
area)
• git commit := Record changes to the repository

Directory
Git doesn’t track directories, it tracks ﬁles, so to
acheive this you need to track at least one ﬁle

• working directory := A folder that contains an
initialized GIT repository
• Git directory := It’s contained in working directory
and it’s called “.git”. In the Git directory there are
ﬁles and folders that compose our repository
• staging area := The staging area is a ﬁle, generally
contained in your Git directory, that stores
information about what will go into your next
commit. It’s sometimes referred to as the “index”,
but it’s also common to refer to it as the staging
area.

• git blame := Show what revision and author last
modiﬁed each line of a ﬁle
• git log := Show commit logs
• git status := Show the working tree status

• git pull := Fetch from and integrate with another
repository or a local branch (fetch + merge)
• git fetch := Download objects and refs from
another repository
• git push := Update remote refs along with
associated objects

• git archive := Create an archive of ﬁles from a
named tree

.gitignore (1)
• A gitignore file specifies intentionally untracked
files that Git should ignore.
• Files already tracked by Git are not affected.
• Each line in a gitignore file specifies a pattern.
• Three levels: $GIT_DIR, $HOME,
$WORKING_DIR

.gitignore (2)
composer.phar
*.log
wp-content/uploads/
conﬁg/autoload/*.local.php
/bin/*

.gitignore (3)
• http://git-scm.com/docs/gitignore
• https://github.com/github/gitignore
• https://www.gitignore.io/

HEAD o head?
• A head is simply a reference to a commit object. Each
head has a name (branch name or tag name, etc). By
default, there is a head in every repository called
master. A repository can contain any number of heads.
At any given time, one head is selected as the “current
head”. This head is aliased to HEAD, always in
capitals.
• Note this difference: a “head” (lowercase) refers to any
one of the named heads in the repository;
“HEAD” (uppercase) refers exclusively to the currently
active head. This distinction is used frequently in Git
documentation.

Fast-forward Git merge (1)
Merging a branch is a pretty common operation
when using Git.
In some circumstances, Git by default will try to
merge a branch in a fast-forward mode.

Let us assume that I created
a feature branch named test
from the current master. After
working on this branch for a
while, I ﬁnally decided that I
am done and then I pushed it
to my own remote.
Meanwhile, nothing else
happened in the master
branch, it remained in the
same state right before I
branched off.
master
feature/test
3 commit

Once my branch is ready to be
integrated, we might use the
usual steps of git fetch followed
by git merge (git pull). Because
master has not been changed
since the commit (gray circle)
which serves as the base for
the said topic branch, Git will
perform the merge using fast-
forward. The whole series of the
commits will be linear. The
history will look like the
diagram on the right.

Another variant of the merge is
to use -no-ff option (no fast-
forward). In this case, the
history looks slightly different,
there is an additional commit
(dotted circle) emphasizing the
merge. This commit even has
the right message informing
us about the merged branch.
The default behaviour of Git is
to use fast-forwarding
whenever possible.
merge

Introducing Tracked branches
(Local and remote branches)
• A local branch is a branch that only you (the local user) can
see. It exists only on your local machine.
• If you're using Git collaboratively, you'll probably need to sync
your commits with other machines or locations. Each machine
or location is called a remote, in Git's terminology, and each
one may have one or more branches. Most often, you'll just
have one, named origin.
• A remote branch was once a local branch that was pushed to
origin. In other words now every user has access to it.
• A local tracking branch on the other hand is a branch that is a
local image of the remote branch (think of it as your copy of the
remote branch).

Tracked branches (1)
(Remote tracking branch)
• Each branch has the concept of what it is
tracking. As well as the branches that will be
affected by a fetch/pull/push, tracking says
which branch is upstream of which.
• Normally, branches checked out of a remote
repository are automatically set up as tracking
branches.

Tracked branches (2)
(Remote tracking branch)
• They’re used to link what you’re working on
locally compared to what’s on the remote.
• They will automatically know what remote
branch to get changes from when you use git
pull/fetch/push.
• Even better, git status will recognize him how
many commits you are in front of the remote
version of the branch.

Tagging (1)
• Git has the ability to tag speciﬁc points in history as
being important. Typically people use this functionality to
mark release points.
• Git uses two main types of tags: lightweight and
annotated.
• A lightweight tag is very much like a branch that doesn’t
(shouldn’t) change. It’s just a pointer to a speciﬁc commit.
• Annotated tags, however, are stored as full objects in the
Git database. They contain the tagger name, email, and
date and they have a tagging message.

Tagging (2)
• By default, the git push command doesn’t
transfer tags to remote servers.
• By default, SourceTree transfers tags to remote
servers (Look at push all tags checkbox on
push window).

git commit --amend (1)
The git commit --amend command is a convenient
way to ﬁx up the most recent commit.
It lets you combine staged changes with the
previous commit instead of committing it as an
entirely new snapshot.
It can also be used to simply edit the previous
commit message without changing its snapshot.

But, amending
doesn’t just alter the
most recent commit. It
replaces it entirely. To
Git, it will look like a
brand new commit,
which is visualized
with an asterisk (*) in
the diagram.
*
Initial history
Amended history

Never amend commits that have been pushed to a
public repository.

Coming next
• Reset (soft, mixed, hard)
• Rebase
• Checkout
• Revert
• Branching
• Merging
• Gitﬂow Workﬂow
• GitHub Flow

http://sal.va.it/1LNuBGx
Download these slides on

Introduction to Git (part 1)

Recommended

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Introduction to Git (part 1) (20)

More from Salvatore Cordiano (20)

Recently uploaded (20)

Introduction to Git (part 1)