Git Basic Usage
Short Version (working with the repositories I set up for you)
Your code will go into Git repositories on GitHub. I am providing three starter projects that use sbt. You should clone these and work with them during the semester. Make sure that you have set up your git configuration on the machine you are working on.
git config --global user.email "username@trinity.edu"
git config --global user.name "Your name"
To get the repository on your machine use. Do this in the directory where you are storing all the stuff for this class. I would actually recommend your Eclipse workspace directory.
git clone URL
Thes are the commands you will be running regularly. (The stuff after the # is a comment telling you what it is doing.)
git status # Run this anytime to see the status of the repository.
git add -A # Stage any changes for being committed.
git commit -m "Commit message" # Commit changes to your local repository. You should use informative commit messages.
git push origin master # Push your local repository up to the remote repository on GitHub. I can't see anything to grade until you have done this.
If you are working on different computers, each time you move to a new computer you need to do the following to pull down the changes you make to where you are working now. Note that this requires that you did a push on the other computer.
git pull origin master
Quick works of warning.
Make sure you are in the right directory!
Never put really big files into your git repository.
Full Description (working with your own repositories)
I want you to put your assignments for this course in a private git repository on GitHub. Git is a powerful version control system that has pretty much taken over that space. Fortunately, you don't need to know all that much about git in order to do what needs to be done for this course. There are lots of references for git available on the web, including a full book. At some point in the future, you should probably take the time to go through other things to learn more about git, but this page can give you the basic knowledge that you will need to get started.
The lab machines have git installed on them. If you plan to use git on your own machine, you will have to install it there. Once you are on a machine with git installed, you need to run two commands to set things up so that it knows who you are.
git config --global user.email "username@trinity.edu"
git config --global user.name "Your name"
You will need to start off by making an account at GitHub. I suggest you don't use the Google login as having a username and password is handy. Then you can create a repository. You should have one repository for each of the two projects. Give the repository a meaningful name that I can easily understand. After you create the repository, you will go to a page that has some instructions. You will go to where your code is to run the "git init" and "get remote ..." commands. It is very important that you are in the correct directory when you do this. I suggest that you do it in the project directory under your workspace for Eclipse. You should probably also add a ".gitignore" file to that directory. You can generate the contents of such a file at https://www.gitignore.io/. You should tell it you are using Scala and Eclipse.
Once you have things set up, you will run through a set of commands to stage, commit, and push the code. These are commands that you will do frequently. You can also run the command
git status
at any time in a repository to get information about where things stand.
When you have completed a programming task, you should stage and commit the code. This can be done by running the following commands.
git add -A
git commit -m "Commit message"
You might find it informative to run "git status" before, between, and after these to see how things change. The message that you use should be informative. In the case of this class, it is especially helpful if you tell when particular assignments are completed. The command git add -u will add all changes and also handle any files that you have removed.
The commit only adds the modified code to your local copy of the repository. When you are done working on a machine or have hit a significant stopping point, you should push your local copy up to the shared repository. You can do that with the following command.
git push origin master
After you have done this, you should go to BitBucket and look at the repository to make sure that your changes are there. The first time you have a repository in a state that I should look at it, you need to share it with me. You can do this from BitBucket and share it to my Trinity email address.
If you work on your projects from more than one place (note that all the CS Linux machines count as one place because of your shared user space), you will need to do some other things. When you first want to go to the other location, you will need to clone the repository. Do this with the following command using the URL that BitBucket gives you for your repository. Again, make sure that you do this in the proper location, probably inside of your Eclipse workspace.
git clone URL
You will also have to go into Eclipse and import that project after you have cloned it. After you make changes on that new machine, you will do the add, commit, and push commands to put those changes back into the repository.
Whenever you switch machines, you will have to do a pull to get the changes that were made elsewhere onto your current machine. Note that if you are working on a project with a group of people, you do pulls and pushes not because you move machines, but because you need the code other people have written and you need them to see your code.
git pull origin master
Lastly, if you do something really unhappy to your local code and you want to wipe it out and go back to what is in the repository, you can use the following two commands.
git fetch --all
git reset --hard origin/master
My guess is that most of you won't need these, but I find them helpful at times when grading, as I don't care about your old code if I edited something in it.