version control systems: svn and git how do vcs support sw
TRANSCRIPT
Version Control Systems:SVN and GIT
How do VCS support SW development teams?
CS 435/535
The College of William and Mary
Chapter 3 Agile software development
Agile manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
2
What is needed?
Chapter 3 Agile software development
Plan-driven and agile specification
Requirementsspecification
Requirementsengineering
Design andimplementation
Requirements changerequests
Plan-based development
Agile development
Requirementsengineering
Design andimplementation
3
Chapter 3 Agile software development
The extreme programming release cycle
Break downstories to tasks
Select userstories for this
releasePlan release
Releasesoftware
Evaluatesystem
Develop/integrate/test software
4
Chapter 3 Agile software development
The Scrum process
Outline planningand architectural
designProject closure
Assess Select
Review Develop
Sprint cycle
5
Chapter 3 Agile software development
Scrum benefits
The product is broken down into a set of manageable and understandable chunks.
Unstable requirements do not hold up progress.The whole team have visibility of everything and
consequently team communication is improved.Customers see on-time delivery of increments and gain
feedback on how the product works.Trust between customers and developers is established
and a positive culture is created in which everyone expects the project to succeed.
6
Software Engineering is Team Work
• Enabling technology for productivity
• must support parallelization
• must support communication
• Documentation as preserved communication
• must support management of tasks & people
• What needs to be done? When? By whom?
• What has been done? By whom?
Remember SVN from CS 301?
What does it support?
Version Control Systems
Centralized •CVS – 1990•SVN - 2000
Distributed •Bitkeeper - 1997•Git – 2005•Bazaar – 2005•Mercurial - 2005
*More VCS at http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Version Control Systems
• Version control system
• supports concurrent software development on shared code base
• keeps track of changes,
• integrates versions / recognizes conflicts,
• allows for recovery, documentation of changes
• Common set up:
• IDE as front end, VCS as back end (shared, persistent storage)
Subclipse: eclipse plugin for SVN
Subclipse: eclipse plugin for SVN
http://subclipse.tigris.org/update_1.8.x
EGit: eclipse plugin for Git
EGit: eclipse plugin for Git
http://download.eclipse.org/egit/updates
EGit: eclipse plugin for Git
http://eclipsesource.com/blogs/tutorials/egit-tutorial/
http://wiki.eclipse.org/EGit/User_Guide#Overview
Centralized vs Distributed Version Control Systems
Image from http://git-scm.com/book/en/Getting-Started-About-Version-Control
Centralized Architecture:
Distributed Version Control Systems
Image from http://git-scm.com/book/en/Getting-Started-About-Version-Control
Distributed Architecture:
Centralized vs Distributed VCS
• What are the pros & cons?
• Software engineering is much about scalability:
• Project size in # of developers
• about 10
• up to 100
• more than 100
Workflows: Centralized
Image from http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
• Small teams• Typical workflow for SVN
and CVS• Repository is a single point
of failure
Workflows: Integration - Manager
Image from http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
• Supported by CVS and SVN using branches
• More easily supported by distributed version control systems
Workflows: Director and Lieutenants
Image from http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
• Supported by CVS and SVN using branches
• More easily supported by distributed version control systems
• Generally used by huge projects (e.g., Linux kernel)
Versions, Revisions, and Snapshots
• CVS: each commit generates a new version for each file modified
• SVN: each commit generates new state of the file system tree, called a revision
• GIT: same than SVN; keeps a snapshot of the system but instead of saving the deltas it saves the changed files and references to the unchanged ones
Git follows idea of a file system with snapshots
CHAPTER 1 GETTING STARTED
so on) think of the information they keep as a set of files and the changes made to each
file over time, as illustrated in Figure 1.4.
Figure 1.4: Other systems tend to store data as changes to a base version of each file.
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more
like a set of snapshots of a mini filesystem. Every time you commit, or save the state
of your project in Git, it basically takes a picture of what all your files look like at
that moment and stores a reference to that snapshot. To be efficient, if files have not
changed, Git doesn’t store the file again—just a link to the previous identical file it has
already stored. Git thinks about its data more like Figure 1.5.
Figure 1.5: Git stores data as snapshots of the project over time.
This is an important distinction between Git and nearly all other VCSs. It makes
Git reconsider almost every aspect of version control that most other systems copied
from the previous generation. This makes Git more like a mini filesystem with some
incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore
some of the benefits you gain by thinking of your data this way when we cover Git
branching in Chapter 3.
1.3.2 Nearly Every Operation Is Local
Most operations in Git only need local files and resources to operate generally no
information is needed from another computer on your network. If you’re used to a
CVCS where most operations have that network latency overhead, this aspect of Git
will make you think that the gods of speed have blessed Git with unworldly powers.
Because you have the entire history of the project right there on your local disk, most
operations seem almost instantaneous.
5
SVN et al:
CHAPTER 1 GETTING STARTED
so on) think of the information they keep as a set of files and the changes made to each
file over time, as illustrated in Figure 1.4.
Figure 1.4: Other systems tend to store data as changes to a base version of each file.
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more
like a set of snapshots of a mini filesystem. Every time you commit, or save the state
of your project in Git, it basically takes a picture of what all your files look like at
that moment and stores a reference to that snapshot. To be efficient, if files have not
changed, Git doesn’t store the file again—just a link to the previous identical file it has
already stored. Git thinks about its data more like Figure 1.5.
Figure 1.5: Git stores data as snapshots of the project over time.
This is an important distinction between Git and nearly all other VCSs. It makes
Git reconsider almost every aspect of version control that most other systems copied
from the previous generation. This makes Git more like a mini filesystem with some
incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore
some of the benefits you gain by thinking of your data this way when we cover Git
branching in Chapter 3.
1.3.2 Nearly Every Operation Is Local
Most operations in Git only need local files and resources to operate generally no
information is needed from another computer on your network. If you’re used to a
CVCS where most operations have that network latency overhead, this aspect of Git
will make you think that the gods of speed have blessed Git with unworldly powers.
Because you have the entire history of the project right there on your local disk, most
operations seem almost instantaneous.
5
Versions, Revisions, and Snapshots
Image from http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html
SVN and Git use global revision numbers
Operations and states (CVS and SVN)
Workspace Repository
Checkout
Commit
Operations and states (Git)
Workspace Repository
Checkout
Commit
Staging area (Index)
Stage
Operations and commands - Git
http://osteele.com/posts/2008/05/commit-policies
Workflows: Integration - Manager
Image from http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
• Supported by CVS and SVN using branches
• More easily supported by distributed version control systems
Operations and commands
Operation CVS SVN Git
Init init create init
Import import import commit
Checkout checkout checkout clone
Checkout branch checkout checkout checkout
Commit/Checkin commit commit commit, push
Update update update fetch, pull
Operations and commands - SVN+Eclipse
Operations and commands - SVN+Eclipse
Operations and commands - SVN+Eclipse
Operations and commands - SVN+Eclipse
Operations and commands - SVN+Eclipse
Operations and commands - SVN+Eclipse
Workflows and issues
• Workflow: 1) get code base 2) make changes 3) deliver changes
• Issue: Read/write access to remote repository
• Protected: User authentication, registration, account/pw necessary in communication, IDE stores/uses account/pw for convenience
• Issue: Conflicts
• Changes do not fit together, automatically recognized at some level of granularity (same file, same method, same line of code)
• Automatically recognized, manually fixed
• Issue: Documentation / Communication
• What changed, how trustworthy are the changes, what needs to be changed as an effect
• Finding the right historical version to undo some changes
Tagging
• Useful for marking specific points in history, in particular: Releases
• Two types: lightweight vs annotated
• annotated: full objects in Git DB, check summed, contain tagger name, email, date, tagging message, can be signed & verifiedCHAPTER 2 GIT BASICS
$ git show v1.4
tag v1.4
Tagger: Scott Chacon <[email protected]>
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <[email protected]>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch ’experiment’
That shows the tagger information, the date the commit was tagged, and the anno-tation message before showing the commit information.
2.6.4 Signed Tags
You can also sign your tags with GPG, assuming you have a private key. All you haveto do is use -s instead of -a:
$ git tag -s v1.5 -m ’my signed 1.5 tag’
You need a passphrase to unlock the secret key for
user: "Scott Chacon <[email protected]>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
If you run git show on that tag, you can see your GPG signature attached to it:
$ git show v1.5
tag v1.5
Tagger: Scott Chacon <[email protected]>
Date: Mon Feb 9 15:22:20 2009 -0800
my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
-----END PGP SIGNATURE-----
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <[email protected]>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch ’experiment’
A bit later, you’ll learn how to verify signed tags.
37
• $ git tag -a v1.4 -m ’my version 1.4’
Branching
• CVS: simple process for creating branches on the repository
• SVN: has no internal concept of a branch; branches are managed as copies of a directory.
• GIT: very simple process for creating local and remote branches
Merging
1 2 3 5 6
4Branch
1 2 3 5 6
4Branch
7
Merge
Branching in SVN
Branching in SVN
Branching in SVN
Branching in SVN
Branching in SVN
Branching in SVN
Branching in SVN
Branching in Git
• Branches are lightweight movable pointers to commits
• The default branch is the MASTER (trunk)
Images from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
Branching in Git
Initial layout for three commits
New branch pointer (iss53)
Images from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
Branching in Git
New commit on the branch
Hot fix branch on master
Images from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
Merging in Git
Images from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
Merging in Git
Images from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
Branching & Merging in Git
• Key concept, well supported
• Local workflow
• people create branches for any issue / task /assignment they deal with, sometimes called “topic” branch
• optional: rebase instead of merge to obtain a linear history
• only recommended for local repository
• Remote repository: merge with master
• For integration manager with blessed repository: pull request
What is missing so far?
• Documentation of problems, bug reports
• Work assignments, who does what and till when
Issue tracking
Github Issue Tracker
• Filter by open and closed issues, assignees, labels, and milestones.
• Sort by issue age, number of comments, and update time.
• Milestones / labels
Github Workflow: Code review & Pull request
• Pull request starts conversation around proposed changes. Additional commits may add to branch before merging into master.
• Pull Request = Code + Issue + Code Comments
Software Engineering is Team Work
• Enabling technology for productivity
• must support parallelization
• must support communication
• Documentation as preserved communication
• must support management of tasks & people
• What needs to be done? When? By whom?
• What has been done? By whom?