A lot of what we do involves writing code in some way. When you write code, especially in a group project but even when on your own, it is SUPER-useful to do some kind of source code management (SCM) -- basically, this means using a tool that keeps track of the various changes that different people are making to the code base. Even when only one person is writing the code, SCM helps you keep track of what you have changed since the last "stable" version of your code; anyone who has done a significant amount of programming will be aware of how crazy things can get when you lose track of what you have changed since the last time the code actually worked like it was supposed to.
Anyway, the SCM tool we mostly use is probably also the most common one nowadays, namely Git. What follows is a quickie guide to getting started with Git. It is a really powerful tool, which is a euphemism for "it can be really complicated to use", but 90% of the time you'll just be using a handful of commands. So here's the quick-start guide.
* For reference: If you need more detail than you get here, this is the official Git documentation. Be forewarned that it goes into more detail than you probably need right now.
* For more tutorial-type content: You might try this course on Codecademy. I (Matt) haven't personally tried it but most of Codecademy's stuff is pretty decent. (If you, dear reader, do try it, feel free to edit this article and add your thoughts/notes.)
* On to getting started. First thing to do is make sure you have Git. If you are using a Mac, which you should be if you are in this lab, you already have Git pre-installed. If you are using Linux, you probably have it too (or you are a big enough nerd that you already know how to install packages and can easily do so). If you are using Windows, may God have mercy on your soul. So... for right now we're going to assume you have it.
* Second thing: You don't have to use a website or service to host your code, but there are many benefits to doing so. You may have heard of sites like GitHub or Bitbucket that host repositories of code for you -- we tend to use Bitbucket. To use Bitbucket, you need an account. And then someone in the lab will need to invite you to be a member of whatever project you are working on. So, you can either sign up for a Bitbucket account and then send Matt/Rafay/whoever your username so they can add you, or just send Matt/Rafay/whoever the email address you plan to use to register on Bitbucket. (If you just send them your email address, the invitation email from Bitbucket will then let you create an account with that email address.) Either way, at the end of this step, you will have a Bitbucket account, and someone in the lab will have added you to the relevant project(s).
* Next: You need to get a copy of the code on your machine. If you go into the project's overview on Bitbucket (should have an URL like: https://bitbucket.org/MyBitbucketUserName/project_name), you should see a little box near the upper right containing a link that looks something like this: https://MyBitbucketUserName@bitbucket.org/SomeBitbucketUserName/project_name.git . That is the URL you can use to get your own copy of the repository. (A repository is basically a copy of the current version of the code, along with some invisible metadata containing the history of all previous changes made to the code.) So select the link and copy it to your clipboard.
* Now open your Terminal (assuming you are on a Mac). There are non-Terminal ways to use Git, but if you are doing enough programming to use Git, you should just be using the command line. Navigate to whatever directory you want to keep your copy of the code in. (For example, Matt keeps all his coding projects in ~/Desktop/dev but you can put it wherever your heart desires.) Then enter the following command: git clone https://MyBitbucketUserName@bitbucket.org/SomeBitbucketUserName/project_name.git where the link part is whatever you copied from Bitbucket. You will probably be asked for your Bitbucket password, and if everything goes according to plan, you will see some download progress information, and then at the end you'll have a new folder named project_name (for whatever the project is called) with the code in it.
* Now it's time to make some edits to the code. Let's assume you have edited a couple of the code files and are pretty happy with your changes. To see what has changed since the last stable version of the code, you can use the command git status (which needs to be executed from within the main project_name folder). That will show you anything that has changed (or any new files that have been created). If you enter git status before you have changed anything, Git will basically tell you that nothing has changed yet. (It will use slightly more complicated phrasing, but don't worry about the details yet.)
* Let's assume you have made changes to two code files, which we'll call codefile1.py and codefile2.py, and that you have gotten to a stopping point you are happy with. In Git terminology we are ready to commit your changes -- i.e., we are ready to make a commitment to these changes as part of our code base. Don't worry, this is not a lifelong commitment -- you can always roll back to a previous code version later with minimal effort. So just think of a commit as a good stopping point that you can easily describe, that might be a good point to return to in the future if things get all mucked up with some later code changes, and that represents a meaningful -- though not necessarily large -- modification relative to the previous code version. For example, fixing a bug -- even if you just have to make a small tweak to a single line of code in order to fix it -- would be a perfectly reasonable commit. But if you work on the code for an hour and make several small modifications or bug fixes in the process, that would also be a perfectly reasonable occasion to make a single commit. What you consider to be a good stopping point is ultimately subjective.)