Module 2 - Source Control

Facebook Roadmap to Impact Notes

Introduction

Module Objectives

Describe the purpose of version control in software development
Define key terms such as repository and commit as it relates to Mercurial
Successfully make several local changes to a repository
Push your changes remotely
Explain forking and branching as they relate to Mercurial

Introducing Version Control

Version control, also known as revision control, refers to a way of managing changes to documents
- Basically, it’s an organized way of thinking about and keeping track of versions of files.
- Version control that’s specific to source code can also be called source control
A version control system(VCS) is just a piece of software that implements version control.
They typically let you view, compare, and roll back to different versions of files without having a million copies of them lying around.

Things You should know

Git is one of the most popular source control system in use today
Mercurial(sometimes called hg) is another popular source control system, and the one in general use at Facebook.

Before Going Further…

Since Mercurial is the source control system in use at Facebook, we will skip over Git entirely
The concepts are 99% the same in both, but here are a couple things that may help you learn the mechanics of Git after knowing Mercurial

Hello Mercurial!

At the end of the day, all Mercurial does is track versions of a folder
- Mercurial’s view of this folder, and all of its changes and versions, is called a repository or repo for short.
Every repo starts out empty, and is modified by successive changes
- One change may include adding, deleting, renaming, or editing files
- Each unit of change is called a commit
A repository with all of its commits is basically the full timeline of all the changes that have happened to folder

Big Ideas

Git and Mercurial are both version control systems

A repository tracks versions of a folder.

A commit is a unit of change in the repo.

Exercises 2.1-2.4

Exercise 2.1

The web starter repo you cloned in module 1 is an example of a Mercurial repo. To get into your web starter, type the following command into the terminal:

1	cd web-starter

Inspect the current state of the repo with the following commands:

hg status
hg diff
hg log
hg log -G

For more information about a command, click on it!

Exercise 2.2

Before you commit your changes, mercurial needs to know your user name. You are going to edit the config file by typing the following command:

1	hg config --edit

If you are asked about an editor, just press enter. A file should appear in nano. Towards the top, uncomment the line that starts with username = and replace the dummy information with your own. Press CTRL+X to finish editing, confirm you want to save changes by typing y and then press Enter to confirm the file name.

Commit the changes you made in module 0 to your repository using hg commit. To verify you changed something, try re-running the commands in Exercise 2.1.

If you accidentally break your config file (you’ll know because you’ll run into issues when you attempt to commit or run hg status), you can simply run the hg config --edit command again to get back to the editor.

Exercise 2.3

Add a paragraph of text to the page and commit these changes to your repository. Remember, to verify you changed something, try re-running the commands in Exercise 2.1.

Hint: Use a site like http://www.catipsum.com/ to get text for your page

Exercise 2.4

Navigate through different versions of your local repo and view the pages in between using the update command.

Using a Remote Repo

Using Mercurial in Software Engineering

One of the big benefits of using a version control system is that they are generally good at sharing work with and collaborating with others
- Think the ease of Google docs, but for code
The way to collaborate using Mercurial is different from Google docs
- First off, to work on one repo together, everyone will need to clone their own copy
- People can then make local changes at their own leisure
- To make sure changes are synced up, they pull work into their own repo and push work to others’
Although Mercurial allows collaborators to freely sync code to each other, in practice, commits are usually synced to a central master repository
- So long as everyone regularly pushes and pulls code the central repository, this gives all the same benefits of collaboration in a much easier format
- This is the case at Facebook

Bitbucket: Mercurial in the Cloud

In a nutshell, Bitbucket just hosts clones of repositories you upload to allow you to collaborate with others
You can use it as the “central repository” mentioned in previous slides
We’ve used it to host the web starter which we’ve shared with you

Exercise 2.5

Push your new changes upstream using hg push.

Forked Development

Let’s imagine a scenario where you’re working on a project with someone else
You both start off on the same repo
But they finish their features before you and push it remotely
What happens when you pull their changes in?

Your copy of the repository now has a fork between their feature and yours!
This is sometimes referred to as branched development, but confusingly enough branches also refer to another feature in Mercurial

Exercise 2.6

You’ll see forked repositories all the time in practice, but for now, let’s simulate a conflict situation for you locally.

Check out to an earlier commit
1. hg update 3:e1e34d2439e5
Make some changes and a new commit
1. make some changes
2. hg commit -m "updated xxx"
Use hg log -G to peek at the repository state
- You should see two commits that have forked from the same commit
- diff with hg diff -r 3:e1e34d2439e5..4:219e3cbf65b6

Exercise 2.7 Reconciling the forks

There are two general ways to combine the two changes into one:

The first is to update the base commit of your local commit from wherever you cloned onto their change
hg rebase
The second is to merge the two commits together
hg merge

At Facebook, option 1 is prefered.

Exercise 2.7

Use one of the above to combine the changes!

Summary

What You Just Did

Looked through repository state using Mercurial commands
Made several commits
Navigate through commits in your repo’s history
Pushed your changes to a remote server
Simulated and resolved a forked repository locally