Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Incorporating Version Control into Programming ...

Tommy MacWilliam
March 07, 2013
110

Incorporating Version Control into Programming Courses

Tommy MacWilliam

March 07, 2013
Tweet

Transcript

  1. What? • track revisions of files • review past versions

    of projects • collaborate with peers and staff
  2. Students: Why? • “I need to work on a project

    with a partner” • “It was working a few hours ago, but I broke it”
  3. Students: Why? • “I need to work on a project

    with a partner” • “It was working a few hours ago, but I broke it” • “I want to back up my code so I can work on another machine”
  4. Staff: Why? • “I want to collect homework submissions on

    my server” • “I want to allow students to review each others’ code”
  5. Staff: Why? • “I want to collect homework submissions on

    my server” • “I want to allow students to review each others’ code” • “I want to distribute updates to distribution code”
  6. Vocabulary • repository: project containing source code files • commit:

    snapshot of a project in time • log: history of commits for a project • branch: independent set of changes • remote: server hosting code • tag: human-readable name for a commit
  7. SCM Tools • centralized • all commits go to one

    repository • decentralized • commits go to developers’ individual repositories
  8. SVN

  9. Workflow • student creates and checks out repository • student

    adds, commits files to repository • staff updates from repository to view files
  10. Basic SVN Workflow • create repository • svn checkout https://project.googlecode.com/svn/

    • edit pset1.c • svn add pset1.c • svn commit -m “done!”
  11. Practice! • create a new SVN repository called yourname-sigcse •

    checkout the repository to ~/svn/student1 • create a file called pset1.c • add and commit pset1.c to the pset1 repo • add and commit test.c to the pset1 repo • view the history of commits
  12. Practice! • make changes to pset1.c without committing, then view

    the changes • commit the changes and compare to previous revision • compare the last revision to the first revision • search all commit logs for the word “done”
  13. Practice! • roll back to the first revision • check

    out a new copy of pset1, starting at the second revision
  14. SVN Collaboration • check out pset1 (again) to ~/svn/student2 •

    make a change and commit as student2 • update the repository as student1
  15. Creating a Merge Conflict • student1 edits pset1.c to say

    “here comes a conflict” • student1 commits to pset1 repo • student2 edits pset1.c to say “I don’t like conflict” • student2 tries to commit
  16. Conflict discovered in '~/svn/student2/pset1/file.c'. Select: (p) postpone, (df) diff-full, (e)

    edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: d
  17. Resolving a Merge Conflict • don’t panic! • mc: keep

    my changes to the file • tc: keep their changes to the file • e: manually edit conflicted file • p: view files that caused conflict separately
  18. Practice! • edit student1/pset1.c to say “here comes a conflict”

    • commit from student1/pset1 • edit student2/pset1.c to say “I don’t like conflict” • commit from student2/pset1 • press “e” to edit as a single file • repeat, but press “p” to resolve conflict!
  19. Branches • one partner wants to try something out •

    develop a feature independently of project
  20. Branches • one partner wants to try something out •

    develop a feature independently of project • staff make changes during feedback process
  21. Branches • independent sets of changes • changes on one

    branch don’t affect other branches • switching between branches changes working copy
  22. Practice! • create a branch called “test” • switch to

    the branch • make changes and commit • switch back to trunk • delete branch “test”
  23. SVN on GitHub • svn co --depth empty https://github.com/you/project •

    svn up trunk • edit files, svn add, svn commit
  24. Git

  25. Practice! • create a new repository in ~/git/pset1 • create

    a file called pset1.c • add and commit pset1.c • make more changes to pset1.c • add and commit pset1.c again
  26. Basic Git Workflow • staff (or students) create remote repositories

    • students • clone repository • add and commit changes • push changes to remote repository
  27. Practice! • create a GitHub repository • clone the repository

    • create pset1.c, then add and commit it • push pset1.c to the remote repository
  28. Practice! • make changes to pset1.c without committing, then view

    the changes • commit the changes and compare to previous revision • compare the last revision to the first revision • search all commit logs for the word “done”
  29. Practice! • roll back to the first revision • roll

    only one file back to the second revision • fast-forward to the current state again
  30. Practice! • undo the changes in your last commit •

    undo the commit that undoes that commit
  31. Practice! • create a tag called “1.0” • commit new

    changes • create a tag called “1.1” • view tags
  32. Practice! • create a branch called “test” • switch to

    the test branch • make and commit changes • switch to the master branch • merge changes from the test branch • delete the test branch
  33. Practice! • create a branch called “test2” • switch to

    the test2 branch • make and commit changes • switch to the master branch • rebase changes from the test2 branch • delete the test2 branch
  34. Collaborating with Git • students have their own local repositories

    • students commit, branch, etc. on local repositories • students push to and pull from a shared repository
  35. Practice! • create a pset2 repository on GitHub • clone

    the repository in ~/git/student1/pset2 • add, commit, and push a change • clone the repository in ~/git/student2/pset2 • add, commit, and push a change • pull the change from ~/git/student1/pset2
  36. Merge Conflicts • don’t panic! • git status shows conflicted

    files • git add files to resolve conflicts
  37. Creating a Merge Conflict • student1 edits pset2.c to say

    “here comes a conflict” • student1 commits and pushes to pset2 repo • student2 edits pset2.c to say “I don’t like conflict” • student2 commits, tries to push
  38. Using Google Code • each student creates repository for each

    project • students add staff as collaborators
  39. Using GitHub • https://github.com/edu • each student creates repository for

    each project • students add staff as collaborators
  40. Repository-Based • each project is a separate repository • students

    collaborate on same hosted repository • if projects are totally separate, makes sense • if projects build on each other, makes less sense
  41. Branch-Based • each student creates one repository for the course

    • each project is a different branch • if projects build on each other, makes sense • if projects are totally separate, makes less sense
  42. Distributing Code • each student: • create repository on GitHub

    • git clone git://github.com/course/pset1.git • git remote rm origin • git remote add origin [email protected]/student/ pset1.git • git remote add distro git://github.com/course/ pset1.git
  43. Submitting Code • students • git tag submission • git

    push --tags • staff • git checkout submission
  44. When Disaster Really Strikes • rm -rf .git • find

    . -type d -name .svn -exec rm -rf {} \;
  45. Potential Pitfalls • merge conflicts prevent pushes! • don’t panic

    • one minute before the deadline, still don’t panic • distinguish between submission and version control? • have a backup submission plan!
  46. Potential Pitfalls • commit timestamps are set by the client!

    • tags can be deleted and moved around • if new to SCM, submission process is very complicated • if using SCM, then teach SCM
  47. Hooks • small scripts that are triggered by SCM events

    • post-receive: whenever a push is received