COMPSCI 169 Lecture Notes - Lecture 13: Code Review, Git, Distributed Version Control

47 views2 pages
21 Oct 2013
of 2
CS169: Software Engineering
October 16, 2013
Complete mid semester survey
Sign up for face to face project meetings with GSI
Version Control for the 2-Pizza Team: Merge Conflicts
Git is vastly superior
commit ID: use unique prefix (in this repo)
HEAD: most recently committed version on current branch
ORIG_HEAD: right after a merge, points to pre-merged version
HEAD~n: nth previous commit
Effective Branching
creating a branch is cheap
use branch to create and use checkout to switch between branches
branch histories are separate
then if we decide against the feature - undo the merge!
one feature should touch too many other parts anyway
branches should be short lived or else they drift too much with master
gitrebase for incremental merge
gitcherrypick for only specific commits
pull request asks owner of the original repo to pull specific commits from a forked app
(since you don’t have admin privileges to the original app)
Fixing Bugs: The Five R’s
Report, Reproduce, Regression, Repair, Release the fix
NOT JUST AGILE - all projects
Github has the “issues” feature
use simplest bug reporting system for your team
Design Reviews, Code Reviews, Plan-And-Document Perpective on
Project Management
design review: authors present the design
code review: after design implemented
SAMOSAS: start/stop meeting promptly, agenda created in advance, minutes recorded so
everyone can recall, one speaker at a time, send material in advance, action items at end of
meeting, set the date/time of next meeting
formal design and code reviews often too late in process to make big impact
have earlier “approach reviews”
use your pull requests on github instead of reviews!
Fallacies and Pitfalls
pitfalls: dividing work based on software stack rather than features
agile: deliver all aspects of the story
don’t stomp on other people’s changes!
reload files into editor after you pull/merge!
don’t make small changes to master!