Facebook Roadmap to Impact Notes
- 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
- 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.
- 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.
- 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
- 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
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.
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:
Inspect the current state of the repo with the following commands:
For more information about a command, click on it!
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:
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.
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
Navigate through different versions of your local repo and view the pages in between using the
- 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
- 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
Push your new changes upstream using
- 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
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
hg update 3:e1e34d2439e5
- Make some changes and a new commit
- make some changes
hg commit -m "updated xxx"
hg log -Gto 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
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
The second is to merge the two commits together
At Facebook, option 1 is prefered.
Use one of the above to combine the changes!
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