+++ /dev/null
-Version control is a way to keep a track of changing files and store a
-history of those changes and the motivation behind them. This
-organized history allows many people in a collaboration to make
-changes concurrently, while staying up to date with changes made by
-their collaborators. It also makes it easy to keep yourself organized
-if you store similar files in several different locations (e.g. a
-project that you develop on both your home computer and your work
-computer).
-
-Basic use
-=========
-
-Learning objectives
--------------------
-
-* Draw a diagram showing the places version control stores
- information.
-* Check out a working copy of a repository.
-* View the history of changes to a project.
-* Add files to a project.
-* Commit changes made to the working copy.
-* Get changes from an upstream repository.
-* Compare the current state of a working copy to the most recent
- update from the upstream repository.
-* Explain what "version 123 of `xyz.txt`" actually means.
-
-Key points
-----------
-
-* Version control is a better way to manage shared files than email or
- shared folders.
-* People share their changes by committing them to public repositories
- and fetch other's changes by updating their local copy from public
- repositories.
-* The version control system prevents people from overwriting each
- other's work by making merges explicit.
-* It also keeps a complete history of changes made to the master so
- that old versions can be recovered reliably.
-* Version control systems work best with text files, but can also
- handle binary files such as images and Word documents.
-* Every repository is identified by a URL.
-* Each change to the master copy is identified by a unique revision
- ID.
-* Revisions identify snapshots of the entire repository, not changes
- to individual files.
-* Each change should be commented to make the history more readable.
-* Commits are transactions: either all changes are successfully
- committed, or none are.
-
-Merging conflicts
-=================
-
-Learning objectives
--------------------
-
-* Explain what causes conflicts to occur and how to tell when one has
- occurred.
-* Resolve a conflict.
-
-Key points
-----------
-
-* Conflicts must be resolved before a commit can be completed.
-* Most version control systems put markers in text files to show
- regions of conflict.
-
-Recovering old versions
-=======================
-
-Learning objectives
--------------------
-
-* Discard changes made to a working copy.
-* Recover an old version of a file.
-* Explain what branches are and when they are used.
-
-Key points
-----------
-
-* Recovering an old version of a file may not erase the intervening
- changes.
-* Use branches to support parallel independent development.
-
-Setting up a repository
-=======================
-
-Learning objectives
--------------------
-
-* How to create a repository.
-
-Key points
-----------
-
-* Repositories can be hosted locally, on local (departmental) servers,
- on hosting services, or on their owners' own domains.
-
-Provenance
-==========
-
-Learning objectives
--------------------
-
-* What data provenance is.
-* How to embed version numbers and other information in files managed
- by version control.
-* How to record version information about a program in its output.
-
-Key points
-----------
-
-* Put version numbers in programs' output to establish provenance for
- data.
+++ /dev/null
-Version control is the most important practical skill we introduce.
-By the end of 90 minutes, the instructor should be able to get
-learners to fetch upstream updates, make local edits, and submit their
-changes upstream and why that's a good way to structure development.
-
-Provided there aren't network problems, this entire lesson can be
-covered in 90 minutes.
-
-Teaching notes
---------------
-
-* Make sure the network is working *before* starting this lesson.
-
-* Give learners a ten-minute overview of what version control does for
- them before diving into the watch-and-do practicals. Most of them
- will have tried to co-author papers by emailing files back and
- forth, or will have biked into the office only to realize that the
- USB key with last night's work is still on the kitchen table.
- Instructors can also make jokes about directories with names like
- "final version", "final version revised", "final version with
- reviewer three's corrections", "really final version", and, "come on
- this really has to be the last version" to motivate version control
- as a better way to collaborate and as a better way to back work up.
-
-* Learners could do most exercises with repositories on their own
- machines, but it's hard for them to see how version control helps
- collaboration unless they're sharing a repository with other
- learners. In particular, showing learners who changed what using
- `blame` is only compelling if a file has been edited by at least two
- people.
projects / swc-workshop.git / commitdiff