Skip to content

Version control

Jump to bottom
JD Russo edited this page Dec 16, 2021 · 2 revisions

Version control with Git

Unsurprisingly given where this is hosted, we use Git for version control.

You should use version control really any time you're writing code. Even if it's a small piece of code, it's quick to set up a local git repository once you get the hang of it, and it will basically guaranteed save you headache at some point.

Version control is useful for:

  • Tracking your changes to code you write
  • Pinning down a change that broke your code
  • Easily switching between different version
  • Combining your changes when collaborating on code with others
  • Syncing code between multiple machines

Gone are the days of emailing yourself files, or scping code from your local machine to the cluster, or Save As-ing a bunch of versions of your code when you make changes. Git makes it VERY easy to do all these (while preserving a record the whole time).

Some basics

  • A repository is a directory where git is tracking changes to the files within. Note that GitHub is just a website for hosting repositories, but you can have a repository that lives locally and never talks to GitHub (or repositories hosted elsewhere).

  • A commit is a record of a set of changes to your code, with a unique identifier (the hash, or long string of characters). (Make sure to write good, descriptive commit messages!)

  • Clone-ing a repository is copying a repository so you can use it or work on it

  • Fork-ing a repository is making a copy that you can work on, that's linked back to the original repository. This is useful for making changes on repositories you don't otherwise have write access to, and being able to compare back to a live version of the original repository.

  • Push-ing is taking a set of commits to one copy of a repository (like on your local machine) and syncing a remote repository to them (like updating github with some commits you've made locally)

  • Pull-ing is the opposite, taking all the new commits in a remote repository and syncing them to your local machine.

Other uses

When running simulations, a nice trick is to store your configuration files in Git. You can initialize a repository in your simulation directory, and then only add your config files.

This has two huge benefits:

  1. It makes it super easy to start new simulations from the exact same initial configuration -- just clone the repository

  2. It makes it super easy to track changes you've made to your config files. Maybe you tweaked some simulation parameter, like your timestep or a collision frequency or something. You can commit that change with an explanation of why you changed it, and in 6 months when you try to remember why things have been set the way they are, you can just review the commit history.

Tutorials

Tools

  • I really recommend getting comfortable with at least basics from the command line
  • SmartGit is in my opinion the best graphical client available. Super powerful, and simple enough.
Clone this wiki locally