Cloning the repository

Log on to Gitlab, add an ssh key, and then find your group's repository under the Projects tab.

Click your repository's name, and at the top of the page there should be a string you can copy of the form git@gitlab.cs.washington.edu:cse557-15sp/YOUR_REPO.git, where YOUR_REPO is your group identifier.

Copy that string, and in a shell (such as Git Bash or Git Shell), run:

$ git clone copied_string

This will create a directory named YOUR_REPO in the current directory

We recommend renaming the local copy of the repository to something more descriptive, by running:

$ git clone copied_string descriptive_name

This will create a directory named descriptive_name in the current directory

If you are prompted to enter your password that means you haven't set up your ssh keys in gitlab properly. Do that now to avoid repeated password prompts as you push and pull things from gitlab.

Committing the skeleton code

Navigate to the skeleton code, click on 'Download zip' on the top right and unzip the downloaded folder

Copy the contents of the unzipped folder (not the folder itself, just what's in it) containing the skeleton code into the repository you just cloned. Commit and push the code by running the following commands:

$ git add --all
$ git commit -m "initial commit"
$ git push origin master

Committing other changes to the repository

The commit and update process in git differs slightly from that of other version control systems that you may have used. To illustrate how it works, we'll make a minor change to one file and create a new file.

Copy the contents of pointBrush.h and paste into a new file called lineBrush.h. Replace all occurrences of 'point' with 'line'. In impressionistDoc.cpp, add lineBrush.h to the brush includes. (search for pointBrush.h if you're having trouble finding this)

Now run the git status command and observe its output:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   impressionistDoc.cpp

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        lineBrush.h

no changes added to commit (use "git add" and/or "git commit -a")

This output shows two things: first, you must explicitly add new ("untracked") files to the repository before they can be committed (as is true in other version control systems), and second, you must explicitly stage your changes before they will be committed (unlike subversion, which will automatically commit all of your changes if you just run svn commit). To further illustrate this, run the git commit command:

$ git commit -m "Adding the line brush header file."

This command will be a no-op: you should see the same output as from the git status command, ending in the same message: 'no changes added to commit (use "git add" and/or "git commit -a")'. To add your changes to the commit set, you must use the git add command on the changed files (whether they are new files or files already in the repository!):

$ git add impressionistDoc.cpp
$ git add lineBrush.h
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   impressionistDoc.cpp
        new file:   lineBrush.h

You can see that the change to the impressionistDoc.cpp file and the addition of lineBrush.h have now been staged for the commit. To commit all of the changes that you have staged, run git commit:

$ git commit -m "Adding the line brush header file."
[master 41a5c0d] Adding the line brush header file.
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 lineBrush.h

However, at this point you have committed some changes, but your commit is not yet visible to the other users of the repository. git separates the notion of committing changes from the notion of "pushing" your update to the central repository. This can be useful for an individual developer that wants to make many changes to the code in many small logical commits before pushing all of them to the central repository, but for your CSE 557 projects you will probably just want to push after every commit.

To push your commits to the central repository, simply run git push:

$ git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 312 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To git@gitlab.cs.washington.edu:cse557-15sp-impressionist/YOUR_REPO.git
   eb27358..c3615e1  master -> master

Updating your local repository

To update your local copy of the repository with commits that other members of your group have made, simply use the git pull command. It will either show:

$ git pull

Already up-to-date.

or something like:

$ git pull
...
impressionistDoc.cpp               	|    1 +
lineBrush.h               		|    1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 lineBrush.h

As with any version control system, pulling updates from the central repository may cause conflicts with changes that you have committed locally. Pay attention to the output from your pull command for instructions to resolve conflicts; generally, resolving a conflict entails opening up the conflicted file(s) in your editor, finding the conflicts (surrounded by the text markers <<<<<<<, =======, and >>>>>>>), fixing the conflicting code, staging the changes (git add) and committing and pushing again. For more information about resolving conflicts, the github user manual has a useful webpage.

Working with a GUI client

If you don't feel comfortable working on the command line, you can use a git gui client. The lab machines have Git Gui installed, but feel free to use any gui you feel comfortable with on your own machine. Here is a list of third party guis if you don't like Git Gui.

Cloning your repository

Git Gui requires that the repository be populated with something before cloning it. If you don't already have the skeleton code in your repository, complete the Cloning the repository and Committing the skeleton code steps above.

If you already have a local repository (if you've run the command git clone)

If you do not have a copy of the repository

Committing Changes

Copy the contents of pointBrush.h and paste into a new file called lineBrush.h. Replace all occurrences of 'point' with 'line'. In impressionistDoc.cpp, add lineBrush.h to the brush includes. (search for pointBrush.h if you're having trouble finding this)

Hit the 'Rescan' button to see your changes in the gui

We now want to stage the files we added/changed, then commit them. Hit the 'Stage Changed' button. You should see the files move from the 'Unstaged Changes' box on the top left to the 'Staged Changes' box on the lower left. Add a commit message, then hit the 'Commit' button.

Finally, we want to push this commit to the origin. Hit the 'Push' button. You should now be able to view your changes on GitLab, and your partner is set to pull the changes.

Updating your repository

Unfortunately, Git Gui does not support the git pull command, so we have to first do a git fetch followed by a git merge

.

Visualize Branch History

You can visualize your branch history by selecting 'Visualize master's History' or 'Visualize All Branch History' under the Repository menu.

---

If you find any bugs in this tutorial, please e-mail them to the CSE 557 staff. If you have any problems while using git that are not covered in this tutorial, try the man pages (man 1 git and git --help <command>) and the Git Community Book, and then contact the TAs. If you find any useful features of git that aren't mentioned here, post them to the class discussion board.

Author: Peter Hornyack (pjh@cs)

Edited by: Sunjay Cauligi (sunjayc@cs), Nat Mote (nmote@cs), Hal Perkins (perkins@cs), Sonja Khan (sonjak3@cs)

Adapted from the CSE 401 git tutorial