Using Git for the CS214 Folder
Setup, Iteration 5

A repository has already been created for you. Since you have content for the repository, it seems best to grab the remote repository first, and then copy what you have into the git project.

You cannot do this until I have add your public key to the git server on csforge.

Clone the Remote Repository

First, you have to clone the git repository from csforge:

unix-%  git clone git@csforge.calvin.edu:jdfrens_languages.git

See what you've got.

unix-%  cd jdfrens_languages
unix-%  ls
unix-%  git status

The README file is there just so that I had something to initialize the repository. The status should tell you that there's nothing to do: you have changed anything local, and you're up-to-date with the remote repository.

Copying Stuff Over

Let's get some content into your git project.

unix-%  cp -R ~/cs214/ruby .
unix-%  cp -R ~/cs214/haskell .
unix-%  cp -R ~/cs214/prolog .
unix-%  git status

The status should now tell you that there are some untracked files.

Preemptively Fixing Problems

Before you start tracking this new content, there's some preventative measures you should take. Firstly, ruby/ruby_koans is already a git project. Second, the haskell folder has some files that you don't want in the repository.

That takes care of the problem with ruby_koans. The Haskell files require a bit more work. If you look in the haskell/factorial folder (after you're ran rake), there will be interface files (ending in .hi), object files (ending in .o), and executables. Git will ignore files based on wildcard patterns in .gitignore files.

*.o

Since most (all?) compiled languages use .o as a file extension for object files, it's best to ignore this everywhere.

*.hi
*Test
*Main

As long as we hold to a convention of naming Haskell executables ending in Test and Main, this should do the trick.

Since Prolog and Ruby don't create any artifacts (since they're interpreted), there's nothing to ignore there (for now).

Add the Content to Git

Now it's time to add!

unix-%  git add .
unix-%  git status

You could replace the . on the git add with specific file names. The status should now indicate that there are "changes to be committed" (aka, "staged").

Committing

Staging just simply gets the files into a queue to be committed. Committing is a separate step.

unix-%  git commit

You'll see some feedback on committing your changes. If you run git status, you'll see that everything's been committed, but you project is "ahead by 1 commit" over the remote repository. This is because you committed your changes only on your local machine.

This is one of the greatest powers of git. Whenever you reach the smallest milestone, you're encouraged to commit your local changes—even if the tests don't all pass! It makes it much easier to see the evolution of your code and easier to rollback mistakes. It also allows you to work and commit without requiring an Internet connection.

Pushing to the Remote Repository

When you reach significant milestones (and preferably when your tests all pass), you can push your code up to the repository.

To see how this works, regardless of the state of your code (milestone or not, passing tests or not), push your changes:

unix-%  git push

You'll be prompted for your pass phrase. If you want to avoid this in the future, run ssh-add before you start working for the day.

Now a git status should tell you that you're all set and clean.

Future Workflow

As you make changes in this folder, you will have to add all changes (whether a new file or changes to old ones) with git add. Create and modify .gitignore files to ignore files appropriately. Use git commit to commit locally, and git push to push back to the repository.

Cleaning Up

You may now want to clean up your account a bit:

unix-%  cd ~/
unix-%  rm -rf cs214
unix-%  mv jdfrens_languages cs214