Mediascripting on the Web (CSC 195 2014F) : Outlines
Outline 01: Version Control with Git
Held: Thursday, 23 January 2014
On to Outline 02 - Math with Images: An Introduction to psaifr.
We explore source code management, focusing primarily on Git.
- Source code management systems.
- A quick demo of Subversion.
- A quick demo of Git.
- Although the title of the outline is Git, we're going to do some
first day of class stuff.
- I've modified my plans for research since early fall. You can hear about
them at 4:30 today, or again in next week of this class.
- The change in research plans means that the way I teach this class has
changed since last year.
- I expect most of you will find the new version as valuable as the old.
Source Code Management Systems
- Large projects involve lots of files.
- Large projects involve lots of people.
- Large projects involve lots of updates.
- What are some implications of these issues?
- At any one time, different modifications are likely to be in different
states (just started; somewhere along the way; perhaps working but not
completely; fully tested; etc.)
- No one person really "owns" any piece of code - what you write today
may be modified by someone tomorrow.
- Changes you make to code someone else writes may have unintended
- Different programmers may be in different places at different times;
the only way to communicate may be through the code (rather than meetings
- Source code management systems are designed to help address these and
other issues of collaborative software development.
- But much of what they do for collaboration they also help with on
- Main features of SCMs
- A way to "check out" parts of a project to work on them
- A way to "check in" the parts of your project after you've
made the changes
- A way to access all past versions of any file, so that you can retrieve
code you deleted (or see what changes you made)
- A way to help programmers deal with (well, at least identify) conflicting
- Encouragement to document changes and capabilities.
Contrasting philosophies of SCM
- While I have been referring to SCMs as a single type of entity, different
source code management systems have very different approaches to dealing
with the common issues.
- Early SCMs (at least the ones I used - rcs and sccs) tended to emphasize
much more of a library model - the repository is a library; only one person
can have any particular piece of the library checked out.
- Some more modern SCMs, such as the way I use CVS and Subversion, still
emphasize the single repository model, although they do permit more than
one person to work on the same file.
- More recently, Git (and other systems) use more of what I'd call a
parallel repository model. Rather than thinking of each programmer
contributing back to the central repository, we think of each programmer
as having her own copy of the project.
- There is still one centralized copy of the project,
- You can pull changes from the central copy.
- You can request that the owner pull your changes back into the
Common tasks with source code management systems
Rare but important tasks
- Create a new repository / Upload an existing codebase into a new repository
- Grab a repository so that you can work on it on your computer.
- In the distributed philosophy, this may involve making a copy of the
- Retrieve an older version of a file
- Rollback to an earlier version of the whole repository (useful for
undoing multiple changes)
- Grab the changes other people made. (Typically done at the start of
- Do your work.
- Note what changes you've made.
- See what files have changed
- See what details of those files have changed
- Commit your changes back to the repository (either your copy or the central)
- This typically involves documenting your changes.
- Add files to the repository
- Remove files from the repository
Behaving well in a collaborative project
- Never put broken code into the main branch of the repository!
- Arguably, you should thoroughly test any code you put into the
repository. (How thoroughly you test depends on the status of the
- Errors in your code should not affect the ability of your colleagues
to work with the project.
- Take documentation seriously. Your documentation (both the notes you log
and the notes that are there) may be the only way you communicate with
the other people who work on your project.
Subversion and the Glimmer subversion repository
- For many years, we used Subversion (svn) as the primary
repository for Glimmer projects.
- Starting in summer 2013, we moved things to Git.
- I'm still working on learning some of the deeper parts of Git (well,
even some of the shallower parts)
- I'll do a simple demo.
- List all the files in a repository
svn ls svn://svn.cs.grinnell.edu/glimmer
- Make a copy of a repository (or subrepository)
svn co svn://svn.cs.grinnell.edu/glimmer/sandbox
- Enter the copy
- See what's happened in the repository
svn log | less
- Compare an old version of a file to the current version
svn diff -r 4615 test.c
- [Play around]
- Determine what files I've changed.
- Determine precise differences
svn diff test.c
- Note that I've added a file
svn add newfile.c
- Propagate changes back to the central repository
- Grab the changes someone else made
- These days, every year or two a new SCM arrives.
- Git is a currently popular SCM system
- It's also likely to live on for awhile, since I believe it's used
for the main Linux development stream
- As I noted earlier, Git takes a slightly different philosophy on source
code management than I'm used to.
- Nonetheless, we are going to do our best to use Git for future Glimmer
- An important aspect of Git is GitHub, a popular hosting site for Git
- GitHub adds some social media aspects to SCM.
- My sense is that potential employers now use GitHub (or related sites)
a lot when making hires.
- You should have an account on GitHub and be productively active.
Note: I would like you to do these tasks using command-line Git, at
least the first time you do them.
- Set up an account on GitHub.
- Set up a project under your account. The project can be almost anything -
code from 151 or 161, notes from a class, whatever you think is
interesting and you're willing to make public.
- Make a change and incorporate it into your project.
The next steps require collaboration with one or more classmates.
- Fork one of your classmate's projects and make a copy on your computer.
- Make some change to the project.
- Send a pull request to the classmate.
- When you receive a pull request, incorporate the code from the request.