CompSci 230 Software Construction Lecture Slides #21: Version Control S1 2016

Agenda Topics: Development using version control Why use version control? Checking out, checking in, committing, merging Tagging and branching Good version control practice CompSci 230: VC

Why version control As we develop software, we produce files, e.g.: Documentation Source code Configuration / localization files Images / graphics / icons Build / deployment scripts Tests Tools Data / database queries / scripts Many of these files change over time and will be worked on by different people, in some cases at the same time? CompSci 230: VC

Version control – basic problem Alice and Bob work on the same development team The team stores its current code base on a simple network drive All developers can read from and write to this drive A developer wanting to work on a file makes a copy of the file on his/her local machine, works on the copy, tests that the change works, and then copies the new version of the file back to the network drive This way, the network drive always contains a “working” version of the code base. At 10.39 am, Alice copies the file CentralEngine.java to her disk for work. At 12.52 pm, Bob copies the file CentralEngine.java to his disk for work. At 14.23 pm, Alice copies the edited file CentralEngine.java back to the network drive. At 15.21 pm, Bob copies his edited version of the file CentralEngine.java back to the network drive, overwriting any changes that Alice made. Alice is not happy! CompSci 230: VC

Version control – non-technical solutions Alice could have notified everyone that she was working on the file Bob could have held off working on the file. What does this do to Bob’s productivity? Is this reliable? What if Alice’s notification arrives after Bob checks for file availability? What if Alice forgets to tell people that she’s finished with the file? Each file has an “owner” whose job it is to integrate any changes into the “official” version that is then stored on the network drive Only owner has write access Other developers send changes to the owner How efficient is that? CompSci 230: VC

Version control – other issues What if we discover that a change that has been made has actually broken something? When is a software code base stable? How many changes / bug fixes / added features until the next stable version? Can we fix bugs on one version while simultaneously refactoring the software for the next major version? What about collaborative working with software that does not have all of its features yet? E.g., a class where some methods are only implemented as stubs CompSci 230: VC

Version control concepts (Project) repositories, versions, branches, tags, commits, merges: Repository contains project files for all versions and branches Branches: versions of the repository for: different purposes, ongoing work Trunk: main stable branch(es) Checking out: download of a version of a document, typically for the purpose of editing Commit: incorporation of edits into a branch Merge: incorporating (committed) changes from another branch into a branch Tags: like branches, but do not evolve further Each commit generates a new version number CompSci 230: VC

Version control repositories Need to keep a copy of each file in every branch or tag every time the file is part of a commit or merge Need to keep track which copy belongs to which branch / version Is it a good idea to make a copy of the entire project file set every time we commit a change to a file (and hence create a new version)? Issues: Efficient storage Speed of retrieval / branching Locking during merges / checkouts CompSci 230: VC

Trunks, branches and tags Branches are essential development lines of the software E.g., create a new branch to allow ongoing development work for a new release of the software while retaining the already released codebase branch for bug fixes Create a new branch for a different software purpose (e.g., freeware version vs. commercial version) Branches are creates as copies of existing versions of the software and evolve from there Trunks are the main stable development lines (e.g., production code) If we create a branch for development based on the production code, we will create it as a branch of the trunk Tags are branches not intended for further development CompSci 230: VC

Checkouts, updates, refreshing Typically, repositories are kept on a server When we check out a file, directory or whole project from a branch, we download a copy of the files A good version control system keeps track of from which version we checked the files out We then get to modify the files locally The latest version in the branch in the repository may change while we do that. This is not reflected in the copies we work with unless we update our local copies by refreshing them from the repository. Updates can create conflict if a file that we have edited locally has changed on the repository. These conflicts usually need to be resolved manually. CompSci 230: UC

Commits and adds When we have changed files in our local copy of a branch, we need to copy them back to the version control system. This is called a “commit” Commits succeed if the file in the branch in the repository has not changed since we checked it out. If the file has changed on the repository side, we need to resolve this conflict. E.g.: Rename the conflicted file locally, refresh from the repository, merge the content of the two files, and then attempt another commit. If we want to add a new file, then this is usually a two-step process: Add: register the file with the repository Commit the file A commit of a file generates a new version on the repository CompSci 230: VC

Merging Merging is required when: We attempt a commit, but the file has changed in the repository branch while we worked on it We are trying to incorporate the changes from one branch into another branch Merging can be performed automatically if: The version control system is capable of automatic mergers, and The version control system can deduct how to merge two versions of a file E.g., one file has not changed, the other has had something added to it, or something was deleted Automatic merging is not a trivial task Manual merging of files that cannot be automatically merged may be assisted by the version control system, e.g., by adding markup to conflicted sections What do you need to know in order to perform a manual merge, even if you can see the conflicted sections? CompSci 230: VC

Example: Version control with GitHub Github.com Online repository with web interface, based on git version control Need a (free) account to create your own repositories Branches master branch is where the production (or closest to deployable) code goes (think trunk) To modify the code base, the developer generally creates a new branch (with a descriptive name, e.g., bobs-edits). This makes a copy of the master Edit online (text format files only) or offline and/or upload files to branch Developer commits changes to the branch first, then opens a pull request Usually includes comments on what changed and why Pull requests A pull request opens discussion on changes / allows for review Branch can continue to be modified when pull request is open and can be deployed in production if so desired or tested further Merge Merging code into master branch can be done semi-automatically Conflicts can be flagged for manual resolution Pull requests represent historical record – can track changes and why they were made CompSci 230: VC

GitHub example CompSci 230: VC

GitHub example CompSci 230: VC

GitHub example CompSci 230: VC

GitHub example alices-edits is now a copy of the master branch – all files are still identical CompSci 230: VC

GitHub example bobs-edits is now also a copy of the master branch – all files are also still identical CompSci 230: VC

GitHub example (Bob – here impersonated by me) inspects HelloWorld.java in his branch… CompSci 230: VC

GitHub example …and edits HelloWorld.java by making a change in line 3 and adding a method. CompSci 230: UC

GitHub example Bob then commits HelloWorld.java to his branch, adding a comment to explain the what and why before he hits “Commit changes”… CompSci 230: VC

GitHub example Pause for a moment… We now have: The master branch, which still contains the original files, unchanged The alices-edits branch, whose files are still identical copies of those in the master branch The bobs-edits branch, which has a file that differs from the master branch So let’s send Bob to lunch and give Alice a go… CompSci 230: VC

GitHub example Alice inspects the file – note it’s the original version, not the one that Bob edited. Alice then clicks on the pen symbol to edit the file... CompSci 230: VC

GitHub example Alice also makes a change to the same line and adds her own method, which she calls from main() CompSci 230: VC

She then commits (with comment) GitHub example She then commits (with comment) CompSci 230: VC

GitHub example Note that Alice is told that GitHub can automatically merge her branch into the master branch. Alice opens a pull request, which includes a comment CompSci 230: VC

GitHub example The pull request gives others an opportunity to comment Note: I’m impersonating Alice here If there is no further discussion, we can merge the branches CompSci 230: VC

Confirm the intent to merge GitHub example Confirm the intent to merge CompSci 230: VC

GitHub example The alices-edits branch has been merged successfully with the master branch – Alice can delete it if she wants: The two branches are identical again. Back to Bob, who is back from lunch and opens his own pull request… CompSci 230: UC

GitHub example Bob’s branch can’t be merged automatically with the master branch - GitHub detects this automatically CompSci 230: VC

Github example When we can’t merge a branch automatically in GitHub, we need to do so manually Generally, this happens if the file has changed in both branches (e.g., master and bobs-edits here) Git can’t work out what was intended so needs human input A manual merge requires the command line version of git GitHub website provides instructions To start seeing what is going on, we can also open the branch in GitHub desktop Note: GitHub desktop is not an editor, so can’t actually fix things here Open command line version of git (e.g., via GitHub desktop), check out branch (e.g., bobs-edits) and open the conflicted file in an editor CompSci 230: VC

Github example In GitHub desktop: CompSci 230: VC

Github example In GitHub desktop: Conflict area marker Divider CompSci 230: VC

Github example In Eclipse: CompSci 230: UC

Github example In Eclipse, merged with conflict resolved: CompSci 230: VC

Github example Commit & push the commits to GitHub: CompSci 230: UC

Github example Can now open the pull request – and merge automatically: CompSci 230: VC

Github notes This example showed me working on several branches In reality, this would be several users, not just me! Note how the conflict straddled method boundaries? Merging files with lots of changes can be complex and challenging What is better: Many small incremental pull requests and mergers or infrequent larger ones? Merge conflicts can arise in other ways, too: E.g., Alice has deleted a file & then merged her branch into master, while Bob has edited the same file. When Bob tries to merge his branch into master later, what happens? CompSci 230: VC

Other version control systems The grandmother of all version control: RCS (Revision Control System), 1982 For individual files only, offers rudimentary branching CVS (Concurrent Versions System), 1986/1990 Client-server architecture, works with file sets / projects, automatic merging Apache Subversion, 2000 Git, 2005 Originally developed by Linus Torvalds for Linux development CompSci 230: VC

Review Why use version control? What is a repository, a trunk, a branch, a tag? What are the two main purposes of creating a branch? What happens when one checks out a file or file set? What happens when one commits files? What happens in a merge? What is the difference between a commit and a merge? What kind of changes allow for automatic merges? What kind of changes don’t allow for automatic merges? What is the purpose of a pull request? CompSci 230: VC