Git Lab

An intro lab on git

This lab's goal is to get you started and reasonably comfortable with the basics of git. Do this lab from one of the department Macs. While you can access the git server from other machines, there's a little more effort involved in setting it up. Do this from a department machine first to make sure everything is working before trying to do it on your own computer.

Before starting this lab, you should have already set up your private and public ssh keys so that you can connect to the department git server. Talk to your prof or Mike if you haven't done this yet.

There is a lot of online documentation about git, which you may want to check out if you get stuck in any of the following steps.
For your project, Mike Tie and his student workers have created a git group. You'll need the name of your group to do the rest of this lab; see someone for help if you don't know the name of your group. For the rest of this tutorial, we'll assume that the name of your group is cs251-f11-squeakymouse, but you should use your own group name wherever you see that.
All members of the team should obtain a "clone" of the repository. To get started, have at least two members of the team log into their account and issue the following command:
```
git clone git@teal.mathcs.carleton.edu:cs251-f11-squeakymouse.git
```
After cloning the project, use the "cd" command to navigate to the cloned directory, have one team member (and only one) create a file called notes.txt, and put some text into it. Note that anytime you add a new file, you need to use the "git add" command. Issue the following:
```
git add notes.txt
```
Then, commit the change locally, then push it to the server:
```
git commit -a -m "Changed a local file"
git push
```
Now that somebody has changed the project, the other clones are not up to date. Have a different team member that has cloned the repository pull down the most recent updates using:
```
git pull
```
Do you see the other person's changes?
Have one team member delete the notes.txt file with the "git rm" command, and then commit and push the changes (note that "git rm" does not change the repository--it changes your local information, and the changes will be made to the repository when you next commit and push). Verify that the other team member can do a pull and see that the file is gone.
Both you and the somebody-else should now make changes to different portions of the same file (e.g. one person should change a word on the first line of the file, while the other person adds a line to the end of the file). One of you should commit and push the project. After doing so, the other person should commit and try to push the project. When doing so, that person will receive a warning about "fast-forward updates," indicating that a change has been made in the repository. To resolve the problem, that person should first issue a "git pull" command, then try "git push" again. This should work. Finally, the original person should issue a "git pull" command to bring down the other person's updates. Both people should look at the file. Are both changes present on each person's copy?
Now, both of you should change the same portion of the same file (e.g. each person should modify the same line of the file). Now, only the first person should commit and push his/her changes.

Here's where it gets entertaining. The copy on the git server is now identical to the copy held by the first person. But that copy is inconsistent with the copy held by the second person. The second person should now pull via "git pull". This should raise an error message, indicating that a commit must be done first so as not to lose the local change. Ok, commit, then pull. What messages do you get from the pull operation? The second person should open up the file with the conflict. What do you see?

The second person should now repair the file by actually speaking with the first person and agreeing on the appropriate changes. Then, the second person should commit and push the changes.

There are some important lessons here:
- Always do "git commit" before "git pull".
- Pay attention to the messages you get during commit, push, and pull operations.
- Keep your eyes open for conflicts.
- Incompatible changes can only be resolved by human intervention, often only after some conversation between two or more people.
Git is intended mostly for use with text files, but your projects can include binary files. For example, suppose you want to include an image file. Add such a file to your project. Generate a conflict by having different users push different binary files with the same name. To resolve the conflict, you'll have to pick one of the two versions. Here are commands to to that:
```
git checkout --ours -- filename
git checkout --theirs -- filename
```
where filename is the name of the file with the conflict. Once you've checked out of the local repository the right name, you can commit and push the update.
When you do just "git commit -a" without the "-m" flag, what happens?