0% found this document useful (0 votes)
896 views

Version Control

This document discusses version control software and provides an overview of Git. It explains that version control systems track changes to files, including who made changes, what changed, where changes were applied, when changes were made, and why changes were made. The document then reviews the history of version control systems, from first generation local systems to current decentralized systems like Git. It provides terminology for key Git concepts like branches, commits, tags, and repositories. Finally, it explains common Git commands and workflows.

Uploaded by

d2op
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
896 views

Version Control

This document discusses version control software and provides an overview of Git. It explains that version control systems track changes to files, including who made changes, what changed, where changes were applied, when changes were made, and why changes were made. The document then reviews the history of version control systems, from first generation local systems to current decentralized systems like Git. It provides terminology for key Git concepts like branches, commits, tags, and repositories. Finally, it explains common Git commands and workflows.

Uploaded by

d2op
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

VERSION CONTROL

SOFTWARE
WHY DO WE NEED A VCS?
VCSs Track File Changes VCSs Tell Us:
 Who made the change?
 So you know whom to blame
 What has changed (added, removed, moved)?
 Changes within a file
 Addition, removal, or moving of files/directories
 Where is the change applied?
 Not just which file, but which version or branch
 When was the change made?
 Timestamp
 Why was the change made?
 Commit messages
Code is organized within a repository.
Basically, the Five W’s
2
BRIEF HISTORY OF VERSION
CONTROL SOFTWARE
First Generation – Local Only Second Generation (Cont.)
 SCCS – 1972  Team Foundation Server – 2005
 Only option for a LONG time  Microsoft product, proprietary
 RCS – 1982  Good Visual Studio integration
 For comparison with SCCS, see this 1992 forum link
Third Generation – Decentralized
Second Generation – Centralized  BitKeeper – 2000
 CVS – 1986  GNU Bazaar – 2005
 Basically a front end for RCS  Canonical/Ubuntu
 SVN – 2000  Mercurial – 2005
 Tried to be a successor to CVS  Git – 2005
 Perforce – 1995 
 Proprietary, but very popular for a long time

3
GIT – THE STUPID CONTENT
TRACKER
Started by Linus Torvalds – 2005
 After the BitKeeper debacle

Efficient for large projects


 E.g., Linux
 Was an order of magnitude faster than other
contemporary solutions

Non-linear development!
 Branching is cheap and easy!!!!

Official Site, Wikipedia,


Initial README commit (some profanity)

4
TERMINOLOGY
Branch Commit
 A history of successive changes to code  Set of changes to a repository’s files
 A new branch may be created at any time, from  More on this later
any existing commit
 May represent versions of code Tag
 Version 1.x, 2.x, 3.x, etc.  Represents a single commit
 May Represent small bugfixes/feature  Often human-friendly
development  Version Numbers
 Branches are cheap
 Fast switching
A Repository may be created by:
 Easy to “merge” into other branches
 Cloning an existing one (git clone)
 Easy to create, easy to destroy  Creating a new one locally (git init)
 See this guide for best practices

5
WHAT IS A COMMIT?
Specific snapshot within the development tree
Collection of changes applied to a project’s files
 Text changes, File and Directory addition/removal,
chmod

Metadata about the change


Identified by a SHA-1 Hash
 Can be shortened to approx. 6 characters for CLI use
 (e.g., “git show 5b16a5”)
 HEAD – most recent commit
 ORIG_HEAD – after a merge, the previous HEAD
 <commit>~n – the nth commit before <commit>
 e.g., 5b16a5~2 or HEAD~5
 master@{01-Jan-2018} – last commit on master branch
before January 1, 2018 6
Master
(branch)
a2
In e7c
it i 0
al
Co
mm
it

1.x
c4

(branch)
A d d00
dC a
oo
lF
ea
t ur

1.0
fd e1
9

(tag)
8f6
Ad 45f Ch 943
dS an
tu f ge
f the
TAGS, OH MY!

AP
I
e1
9f Ad 1bd4
Bu d132 dC
gf oo
ix lF
1 ea
tur
9e e2
Ad 5ed3
2.x

dC
(branch)

oo
lF
ea
tu r
f1c e3
Ch 2b8
an
1.1

ge
(tag)

af1 the
Bu c2b AP
gf
ix I(
2 ag
ain
61 )
BRANCHES, COMMITS, AND

Ad 9cec
dS
tuf
f
7
TERMINOLOGY
Working Files Use “git diff” to see which changes exist.
 Files that are currently on your File System
Use “git add” to tell Git that a file’s
The Stage (also called the “index”) changes should be added to the stage.
 Staging is the first step to creating a commit
Use “git status” to see the changes in your
 The stage is what you use to tell Git which working files, as well as what changes
changes to include in the commit have been staged for the commit.
 File changes must be “added” to the stage
explicitly Use “git commit” to convert all staged
 Only changes that have been staged will be changes into a commit.
committed  git commit -m “my commit message”
 git commit -m “my commit message” -a
Checkout  Will automatically stage all files tracked by the repo & add
 Replace the current working files with those them to the commit.
from a specific branch or commit  Please don’t do this.
8
A DISTRIBUTED VCS
What do we mean by distributed? Common Pattern:
 Cloning a repository (repo) creates a full copy  One canonical repository for the project (on
of that repo on your local machine. GitHub, for example)
 You can fetch updates from non-local  Every developer forks that repo on GitHub
repositories (e.g., repos on GitHub)  A fork is simply creating a copy of the repo on that remote
system
A non-local repositories is a remote  Every developer clones their own GitHub repo
 When you clone a repository, a remote called to their local machine
origin is created for you automatically in your  Every developer adds a remote pointing to the
local repo which points to the source repo. canonical (main, authoritative) repo, as well as
 Remotes are local settings. They do not other dev repos as needed
become part of your commits.  Devs work locally, push changes to their own
 You may set up additional remotes. remote, then request that the canonical repo
 Use case: Development teams, where each dev has their accept their changes via a pull request
own repository.
9
A DISTRIBUTED VCS
(VISUALIZED) Requ est
GitHub, BitBucket,
SourceForge,
l
Pul Canonical GitLab, CodePlex,
etc.
k for
for k

fork
Arlene Cindy

in
Bret
ma
ori
clo

et cin d
gin

r
ne

b
y
Action

Local repo Remote (no push)


Remote (with push)
Action on GitHub
*Names taken from 2017 Tropical Storms 10
Local

GIT WORKFLOW
You pull from a remote to your local
repository.
 A pull is a fetch and a merge
 I prefer to use fetch and merge separately,
and avoid pull.

You push a branch from your local


repository to a remote.
A failure to merge is a merge conflict,
and must be resolved manually. (more
on next slide)
Helpful list of Git Commands
 https://cscrunch.com/blog/corey-pennycuff/
my-git-cheat-sheethandout

Image by Daniel Kinzler


11
MERGING
A “merge” is the act of incorporating the What causes a merge conflict?
changes from one branch or commit into a  2 branches modify the same place in the same file.
second branch.  This often happens at the end of files or between
function declarations.
The histories do not have to match exactly;
 Git does not know which version of the change
Git will work to sort them out.
you want, or if you want both of them
If a merge fails, Git will notify you of a consecutively (and in which order), so you must
“merge conflict”. inspect the conflict and resolve it.

Merge conflicts must be fixed manually, If you cannot push your code to a remote,
and then added and committed. you probably need to first pull the latest
changes, resolve any existing merge
“git status” will show any merge conflicts. conflicts, then try to push again.
A successful merge creates a new commit Small commits are better than large ones!
automatically.
12
COMMON INDUSTRY
PROGRAMMER WORKFLOW
1. Choose a bug/feature to work on
2. Checkout the appropriate branch
The pull request is where other
3. Pull the latest additions from the programmers review your code & make
main repository comments/suggestions.
4. Create a branch for the bug/feature If changes are needed to your code, then
request repeat the process.
5. Do the coding necessary & commit
6. Push the changes to your remote Never
7. Create a pull request to main repo

13
PRACTICAL GUIDELINES
Do’s Don’ts
 Make small, incremental commits (within  Do not commit commented-out debug code.
reason) are good. Avoid monolithic commits at  It’s messy. It’s ugly. It’s unprofessional.
all cost.  Do not mix your commits. (e.g., Don’t commit
 Use a separate branch for each new bug/feature two bugfixes at the same time.)
request.  Do not commit sensitive information
 Write nice commit messages. Otherwise, the (passwords, database dumps, etc.)
commit log is useless.  Do not commit whitespace differences, unless
 Use a .gitignore to keep cruft out of your repo. it is specifically needed.
 Search engines are your friend. Someone else  Do not commit large binaries.
has had the same question/mistake/situation as
you, and they have already asked the question
online. It’s probably on StackOverflow.

14
HELPFUL RESOURCES
Pro Git – free Apress ebook
Visualizing Git histories
Wikipedia on Version Control, with
definitions
My Git Cheat Sheet
Git Commit Etiquette for Junior Devs
https://www.codeschool.com/learn/git
 Free course to walk you through basic Git
concepts

15

You might also like