GIT Details for people who: * don't know what version control means * don't know what distributed version control means * Used to work on SVN (Subversion)

1. GIT
WHAT? WHY? HOW? AND THE
BEST PRACTICES
18 – 10 - 2018

2. 03
WHY GIT?
02
WHAT ARE
THE VCS
TYPES?
01
WHAT IS VERSION CONTROL?
06
BEST
PRACTICES
05
HOW TO
WORK WITH
GIT?
04
GIT MAIN CONCEPTS
AGENDA

3. What is Version Control?
Version Control
• Version control is a practice that tracks and controls files changes
• As teams design, develop and deploy software, it is common for
multiple versions of the same software to be deployed in different
sites
• At the same time, bugs and new features may present in certain
versions
• Therefore, we may have multiple development tasks on multiple
versions concurrently. For instance,
• one version need new features (development version)
• and at the same time we need to apply fixes on another
version (production version)
Version Control System (VCS)
• Version control system is a system that records changes to a file or
set of files over time so that you can recall specific versions later

4. What Are the Different VCS Types?
Local VCS
• Local VCS installed on developer local computer with a simple DB
to track the files changes
• This type has the following main downsides:
• Collaboration between developers is not supported in this type
• If the local hard disk becomes corrupted, and proper backups
haven’t been kept, you lose absolutely everything (including
the project history)

5. What Are the Different VCS Types?
Centralized VCS
• This VCS type depends on a single server that contains all the
versioned files.
• Many clients can access the server to checkout the files commit the
changes from/to the server
• In this type, everyone in the team knows to a certain degree what
everyone else on the project is doing.
• Administrators have fine-grained control over who can do what
• This type has mainly two downsides:
• It a single point of failure; if the server goes down, then
nobody can create branch, commit the changes, or even see
the history.
• If the server’s hard disk becomes corrupted, and proper
backups haven’t been kept, you lose absolutely everything.

6. What Are the Different VCS Types?
Distributed VCS
• This type is similar to Centralized VCS by depending on a remote
server that contains all the versioned files but it also has a local
repository on developers local computers.
• In this VCS type, the clients don’t just check out the latest snapshot
of the files: but they fully mirror the server’s repository locally.
• Thus if any server dies, and these systems were collaborating
via it, any of the client repositories can be copied back up to
the server to restore it
• Every checkout is really a full backup of all the data

7. Why GIT?
Strong support for non-linear development
• GIT has an incredible branching system
• It allows you to work on different versions concurrently
• You can work on a new feature for a new release and at the
same time work on a bug on production
Distributed Development
• GIT implements DVCS
• Multiple developers can work on the same project at the same time
• No single point of failure
• It is also fast and very efficient with large projects
Safeguards
• Everything saved in GIT is accessible at some point later (Even if
you deleted it)

8. GIT Main Concepts
Remote Repo
• This is a central server accessible by all the team members
• Team pushes changes to remote server when it is ready to
share with the others
• Team fetch the changes from remote server to see what others
did
Local Repo
• It is on developer computer (.git directory)
• Enable full diff, history review and committing while offline
• Has mainly two area; staged (indexed) files and committed files
Working Directory
• Sometime called Working tree and sometimes called “untracked” area
• This is the folder that holds your files/source code
• When you make changes on a file you are doing them first in this folder
• Working directory is attached with the local repo using a special folder
called “.git”

9. How to work with GIT?
Initialize
• git clone
• Clone command copies a remote repository into a local repository and checks it out into the working directory
• Clone command actually performs the following commands in the background:
• git init (create the local repository)
• git remote add (attach the local repo to remote repo)
• git fetch (fetch the branches to local repo)
• git checkout (create all the files of the main branch in the working tree)

10. How to work with GIT?
Update
• git pull
• Pull command updates the local repo from the remote repo and merges the
changes with working directory
• Pull command actually performs the following commands in the background:
• git fetch (update local repo from remote repo)
• git merge (merge the changes with the working directory)

11. How to work with GIT?
Share Changes
• Submitting the changes with the others is a multi-step process
1. Add
• git add .
• Contrary to most VCS, GIT requires staging the files
before committing, not just new files
• This command adds the files to staging area in the
local repo
2. Commit
• git commit –m “This is a basic commit
message”
• commits all staged files together as an atomic
commit to the committed files area
• git commit –a: do the following:
• git add (Add the updated/deleted files to
staged area but not the newly added files)
• git commit (commit the changes to
committed area)
3. Push
• git push
• Share the local repo commits to the remote repo

12. How to work with GIT?
Undo Changes
• git checkout
• Takes the changes from the staged area and uses it
to override the working tree
• git reset
• Takes the latest version from local repo/committed
area and uses it to override the staged area
(working tree will remain as is)
• git reset <file>
• Do the same as previous command but only for the
specified file.
• git reset <commit>
• Takes the version marked by <commit> from the
local repo/committed area and uses it to override
the staged area (but not the working tree).
• git reset –hard (Don’t use)
• Takes the latest version from the local
repo/committed area and uses it to override the
staged area and the working tree
• git fetch
• Takes the latest version from remote repo and uses
it to override the local repo/committed area only
Local Repo
WorkingTree Staged Area CommittedArea Remote Repo
git fetch
git reset <file>/ git reset --hard/ git checkout
<commit>/ git reset <commit>
git reset --soft

13. How to work with GIT?
Diff
• git status
• Shows which changes in the working tree that are staged
and which changes are not
• git diff
• Shows the differences between the staged area and
working tree
• git diff HEAD
• Shows the differences between the latest version in the
committed area and the working tree
• git diff –cached
• Shows the differences between the latest version in the
committed area and the staged area
• git diff <source_branch> <target_branch>
• Shows the differences between two branches
• git diff <local_branch> <remote>/<remote_branch>
• Shows the differences between local branch with remote
branch
• For example: git diff master origin/master

14. How to work with GIT?
Branching and Tagging
• git checkout -b feature_x
• Creates new branch on the local repo and switch our
working directory to it so when you commit, you will commit
on this branch
• git push origin <branch>
• Push the new branch to remote repository
• git tag 1.0.0 <commit>
• Creates new tag based on the specified <commit>
• Use git log to list the commits
• git branch –a
• Lists all available branches
• Note: Don’t be confused with the checkout command
• If checkout used with branch, it will just switch to that
branch without overriding the changes you have in your
working tree
• If checkout used with commit id, it will override your working
tree with the version marked by the specified commit id

15. Best Practices
• Commit regularly (Preferably by end of day)
• Stay up to date with your team (Pull the changes every day early
morning)
• Follow standard branching models
• Tag production releases
• Divide work into repositories
• Use useful commit messages
• Don’t commit generated files (such as .class)
• Don’t commit configuration files that can be changed from
environment to environment
• Don’t use git reset --hard

16. Best Branching Model
Branching and Tagging
• Best Branching model depends on 3 main branches
• Development Branch
• This is were your team daily commits go
• It can be the master branch
• Releases Branches (branch for each release)
• For each release (Ready for production) we can create
a branch for that release from the development branch
• Any fixes on these releases must be merged with the
development branch
• Tags (Snapshot of the production):
• once the application deployed on production, make sure
to tag it
• Hotfixes Branches
• If we had a production issue, you should have a branch
from production tag, apply the fixes on the new branch,
test the fixes, deploy them on production and tag it
under new label
• The changes on hotfix branch must be merged with the
development branch

17. Thank you