October 5, 2015

Version Control
and Code Review

Version Control

Who Wrote What When and Why

A version control system tracks changes to files over time.

VCS is like Track Changes, but better. It's designed for multiple users working on the same material simultaneously and for selectively rolling back changes. We can go back in time and retrieve the state of our code before changes were introduced.

Code Review

"Efficient streamlined QC" is not an oxymoron.

Code review integrates quality control, and its documentation, into the workflow.

Git and GitLab

Git is…

  • Version control
    • authorship, time stamps, and files changed
  • Distributed
    • Repositories are self-contained and collaborative - work on a flight and share when you land.
  • Open source and widely used

GitLab is…

  • Code review
  • Browser-based Git repository manager
  • Project ownership and management
  • Task assignment and tracking
  • Open source and widely used


Install Git

Configure Git

git config --global user.name "Elizabeth Byerly"  
git config --global user.email "elizabeth.byerly@gmail.com"

By issuing these configuration commands, all our Git activity will be stamped with our name and e-mail.

These commands must be re-issued for every installation of Git (i.e., if you want to use Git on your home computer).

Create a Git repository

We use the init command to create a repository in the current working directory of our console.

git init

Or, we can specify the directory we want to make a Git repository (it will make the directory if it does not exist).

git init "L:/my-new-project"

All files in the working directory, as well as all files in all subfolders, will be seen by Git.

Making and committing changes

Add some files to your directory and then to your new git repository.

git status
git add --all
git status
git commit -m 'My first commit'
git status

status is helpful for seeing the current condition of your potential commit. The first call will show in red the files you've added to your repo. The second call will show them in green, staged and ready to be tracked by Git. The last call, after our commit, shows we have no current changes to consider.

Seen, Staged, Committed

Let's pause here to talk about three levels of "saved" in the world of Git:

  • Seen: Files written to disk, our working copy. Git cannot see work in our file editor until we save it. (We can also deliberately hide files from Git using .gitignore.)
  • Staged: Git is aware of a change and is ready to add it to the file's tracked history.
  • Committed: Git has saved the state of the staged file changes written to disk.

We care about committed file changes. Changes saved to disk and staged, but never committed, can be lost as soon as we change the file again.

Commit history

Change a file

Stage a file

Commit, update repo history


git checkout <commit hash 1> "File C"
git checkout HEAD@{3} "File C"


git checkout -b dev

When collaborating, branching allows us to work from a stable base while continuing to commit our interim work.

Once our updates are ready, we can merge them onto the master (or any other) branch.

git checkout master
git merge dev


Repositories can be cloned.

git clone -b master "L:/my-new-project" "P:/my-clone-new-project"

Cloning does not copy the folder contents. It creates a new Git repository with the same contents, including its history of changes, and tracks the repository from which it was cloned (its origin). This means we can update "P:/my-copy-new-project" everytime its origin repository changes.

Note we provide the option -b master, which specifies we want to clone the master branch initially. All branches pushed to the central repository are available; this option sets what you define as your local master.

Fourth level saving: central

Updating based on the changes in origin is one part of Git's collaborative workflow. To be able to push our changes to origin (that is, update origin based on the changes we make to our remote repository), we need to make origin a bare repository.

<hr / >

What is a bare repository? One without a working directory!

For collaborative workflows, this is key. Multiple users can use a bare repository as their central repository - the one source of project Truth - from which they will pull down changes and push updates.

Bare repositories, cloning, pulling

git init --bare "L:/second-new-project"
git clone "L:/second-new-project" "P:/my-remote-second-project"

We do some work, add some files changes, then we check the origin repo is in the same state as when we cloned.

git pull origin

If changes were introduced by another collaborator, they either (a) merge without issue or (b) introduce code conflicts we can resolve.


Finally, we give our code changes to the central repository.

git push origin master

Note, if we skipped the git pull step and another contributer has added conflicting work to the project, your push will be rejected!

Otherwise, anyone with access to the bare central repository can now clone our work and add to it.

Git GUIs

  • Git GUI for Windows (gitk)
  • SourceTree
  • Giggle
  • …many more!
  • Note: TortoiseGit will break our Windows SSH connection to GitLab.

These have not been reviewed for compatibility with a GitLab workflow. Please provide feedback if any of these are particularly easy/difficult or effective/horrible to use.


Make your account

Attach an SSH key to your account

In your console window, run the SSH generation.

ssh-keygen -t rsa -C "elizabeth.byerly@gmail.com"

Allow its default save location and press Enter twice to create without a password. Then, copy your public key to your clipboard.

clip < "~/.ssh/id_rsa.pub"

Paste the contents of your clipboard into Add an SSH Key: https://gitlab.com/profile/keys

These commands must be re-issued for every computer on which you use GitLab. You can add multiple SSH keys to your GitLab account.

Make your first project


Your Project path is your project name. It cannot contain spaces.

Your Visibility Level sets the project privacy.

  • Private: Your project is invisible to users not explicitly invited to see it. Authentication is required to read and write. (This option is only available for private installations of GitLab.)
  • Internal: Your project is visible to users logged into https://gitlab.com/. Authentication is required to write.
  • Public: Your project is visible to everyone and can be copied by anyone.

We can also Create a group if we want to associate multiple projects.

Clone your project

git clone git@gitlab.com:ByerlyElizabeth/test-gitlab.git

Once you've cloned the bare repository from GitLab, you use it exactly the same as a normal Git repository. The push and pull commands will refer to the bare repository on the GitLab server.

Add users


When adding a user to your project, you must assign their permissions level.

  • Owner: Creator of the project. Can delete or change the visibility level.
  • Master: Create milestones, add team members, and push to protected branches.
  • Developer: Create and manage merge requests, create and modify unprotected branches.
  • Reporter: Pull code and manage issues.
  • Guest: Create issues and leave comments.


Protected branches

By default, the master branch is protected.

Protected branches can only be written to by users with Master or Owner permissions. This forces lower level users to issue a merge request.

Merge requests

Before a development branch can be merged onto a protected branch, it must pass through a merge request. Merge requests are a formal process of code review and approval.

Once the request is approved, the work is added to the master branch as a new known stable release.

View the update history