This document provides an overview of Git basics, workflows, branching, and common commands. It discusses Git's data structures including its object database and references. It compares Git to centralized version control systems like SVN and outlines key Git concepts such as pushing, pulling, and distributed version control. The document also provides examples of everyday Git tasks like adding features, committing, pushing, merging, and rebasing branches. It concludes with a list of common Git commands.

1. GIT: Basics, Branching and
Tricks for SVN Users
v 0.1a
Petar Denev, SoftServe Bulgaria, February 2016

2. ●
GIT - the stupid content tracker*
●
GIT Basics
●
GIT Workflows
●
Branching
●
The “GIT Everyday” scenario + Tips
●
Common commands and usage
●
Training Task
*man git ]; )
2
Training Agenda

3. ●
Slang for “unpleasant person”
●
Made from Linux Kernel Hackers ]; )
●
Distributed revision control system focused on data integrity, and support for distributed, non-
linear workflows
●
Supports rapid branching and merging
●
Provides a local copy of the entire development history, changes are imported as additional
development branches, and can be merged as a locally developed branch.
●
Snapshots directory trees of files
●
Implements several merging strategies:
– Resolve – 3-way merging
– Recursive - default when pulling or merging one branch
– Octopus - default when merging more than two heads
3
GIT - the stupid content tracker

4. ●
Data Structures
Git has two datastructures: a mutable index (also called stage or cache) that caches
information about the working directory and the next revision to be committed; and an
immutable, append-only object database.
4
●
Data Structures
Git has two datastructures: a mutable index (also called stage or cache) that caches
information about the working directory and the next revision to be committed; and an
immutable, append-only object database.
●
Data Structures
Git has two datastructures: a mutable index (also called stage or cache) that caches
information about the working directory and the next revision to be committed; and an
immutable, append-only object database.
Object database contains four types of objects:
●
blob (binary large object) – just file content - no file
name, time stamps, or other metadata.
●
tree – describes a snapshot of the source tree - a
list of file names, some filetype bits, a blob or tree
object, symbolic link, or directory's contents.
●
commit - object linking tree objects together into a
history
●
tag - a container that contains reference to another
object and can hold additional meta-data related to
another object

5. 5
●
References - every object in the Git database which is not referred to may be cleaned up
by using a garbage collection command, or automatically.
– heads -refers to an object locally.
– remotes -refers to an object which exists in a
remote repository.
– stash -refers to an object not yet committed.
– meta -e.g. a configuration in a bare repository,
user rights.
– tags -explained in previous slide

6. GIT compared to SVNCore Concepts:
- Centralized version control focuses on
synchronizing, tracking, and backing up files.
- Distributed version control focuses on
sharing changes; every change has a guid or
unique id.
- Recording/Downloading and applying a change
are separate steps (in a centralized system,
they happen together).
- Distributed systems have no forced structure.
You can create “centrally administered” locations
or keep everyone as peers.
New Terms:
push: send a change to another repository
pull: grab a change from a repository
Key Advantages:
- local sandbox. It works offline
- FAST. Diffs, commits and reverts are all done locally.
- Branching and merging is easy
- Less management and easy to get running
Key disadvantages: you still need a backup
https://git.wiki.kernel.org/index.php/GitSvnCrashCourse

7. Before doing your first clone, the service should be configured with these
commands:
git config -–global user.name <name> //Define author name
git config –-global user.email <email> //Define author email
git config –-global –-edit //Manually edit the global config file
Lets clone: git clone https://github.com/petardenev/training
Extended repository history: git log –-graph --decorate
Add all new files and/or directories: git add -A
Submit to version control: git commit -m “<mesage>”
Push to master: git push
7
GIT Basics

8. 8
GIT Workflow
●
Centralized workflow – same as SVN
●
Distributed worflows
– Integration Manager workflow
– Dictator and Lieutenants Workflow
– GIThub workflow

9. 9
GIT Branches
● What a Branch is:
Git stores a commit objects with a pointers to the
snapshot of the content(filesystem like),
the author and message metadata, and zero or more
pointers to the commit
or commits that were the direct parents of this
commit:
zero parents for the first commit, one parent for a
normal commit,
and multiple parents for a commit that results from a
merge of two or more branches
● Remote branches – references to remote
repositories/tags
● Git fetch VS git checkout

10. ●
Task: add function to complete the feature,
then merge to master
1) switch to feature branch
●
git checkout $BRANCH
2) do the changes
3) commit
GIT Everyday
● git commit -a -m '$BRANCH done'
4) push your changes
● git push
5) push rejected ?!?!
WTH? Options here?

11. ●
DON'T USE git push –force !
●
Try to merge changes, clone the new repo in a new directory and review the
changes done
●
rebase the local repository to be up-to-date with the latest changes and then
commit yours and push to master
●
stash your changes, pull new code, stash apply
6) decided to merge
●
git merge master $BRANCH
7) can't merge, must stash changes
●
git stash
●
git pull
●
git stash apply

12. 8) stash apply results in merge – can't track, better rebase
9) The Golden Rule of Rebasing
Never use it on public branches!
The rebase moves all of the commits in master onto the tip of feature.
The problem is that this only happened in your repository.
All of the other developers are still working with the original master.
Since rebasing results in brand new commits,
Git will think that your master branch’s history
has diverged from everybody else’s.

13. 10) When to use rebase?
Rebase preserves the order of changesets,
and still commits your changes!
Thus – use it only if you're 1000000% sure
noone else works on the repository
at the time of push

14. Common commands and usage
to clone >> git clone <repo>
a specific branch only >> git clone -b my-branch <repo>
to add all, no matter files or directories >> git add -A
to check current situation in the repo >> git status
to commit in 1 line >> git commit -m ' $commit_message '
to publish changes >> git push
to change working branch >> git checkout $BRANCHNAME
to undo last commit with a new one >> git revert <commit>
to remove a file from stage(leaving it in the same directory) >> git reset <file>
to view which files would be removed >> git clean -n
to amend last commit >> git commit --amend
to rebase current branch onto <base> >> git rebase <base>
to view diff from last commit >> git diff HEAD
to reset last commit >> git reset
to reset, overwriting all changes >> git reset –hard
to reset, deleting all changes after commit >> git reset –hard <commit>

15. Training Task ?!?! open for advice,
should we get all the info in action
or ?!?

16. Thank you!
US OFFICES EUROPE OFFICES
Austin, TX
Fort Myers, FL
Lehi, UT
Newport Beach, CA
Waltham, MA
Bulgaria
Germany
Netherlands
Poland
Russia
Sweden
Ukraine
United Kingdom
www.softserveinc.com