EECS448:Lab2

Navigation
Home
Information
Syllabus Schedule
Classwork
Labs Projects

Due Time

• This lab is due one week from the start of your lab session. Even if it didn't meet.
• For this lab only, attendance is not required for a grade

Lab Type

This lab is an individual lab.

Additional Resources

• git documentation
• Online tutorials in git and github on Udacity
• Github

Topics

Github

• cloning
• forking (github creation)
• pushing
• pulling

Overview

For this lab and for the remainder of the semester, you will be using github to publicly host your repositories. If you haven't already, make a github account.

After you have an account on github, you'll be able to create repositories of your own that others can access, or you can fork existing repositories and extend on someone else's work.

Cloning and Forking

Cloning

Last lab you made a clone of my git-command-line repository. The act of cloning accomplishes the following:

• A local copy of the repository is created
  • You see all the files and resources in the local copy
  • You can make changes to the local copy, but these changes won't be reflected in the original repository
• Creates a remote automatically
  • We'll talk more about remotes later

Thing that cloning does NOT do:

• Alter the original repository
• Give you control over the original repository in any way

Forking

In this lab you will fork a project of mine, called lab02. Forking a project accomplishes the following:

• Creates a clone of the original repository on github

Things forking does not do:

• Forking does not create a local copy of the repository, but you can still clone your fork of the project
• Give you control or alter the original project in any way

Cloning VS Forking

First of all, forking is entirely a github (not git) creation; there is no "fork" command. Forking is very convenient and useful because you can then clone or link people to the repository that you forked. In short, a fork is just a clone of a repository that github stores for you.

You have total control over your fork or clone of a repository, but you never have control over the original without permission.

Exercise: Creating Repository on Github

Last lab, you made a repository that you wrote a story in. This was not created or cloned from github - it was entirely local. To post this repository on github, do the following:

In a browser:

• Navigate to github
• Select the plus icon near your profile picture and select "create new repository"
  • DO NOT select the option to start with an initial readme
• Name the repository the same as your local one
• Make note of the "https" URL

Remotes

Here is the situation:

• We have a local repository with our story in it
• We have an empty repository on github

Our goal: copy the local repository to github for the world to see. Here's what to do:

In your local repository:

• Add a remote to your repository:

git remote add <name> <url>

Example:

git remote add origin https://github.com/jwgibbo/story.git

Notes:

• origin is a naming convention to refer to the github remote
• the URL will end in .git
• You can obtain the URL from github
• Adding a remote simply adds a remote label to git, we still need to copy our repository to github

Pushing

We have just added a remote to our repository. Now we will push our changes repository - to github.

git push <remote> <branch>

Example:

git push origin master

At this point, you'll be prompted to provide your github credentials. If you asked to interact with KSSHPASS, you can just close the prompts that pop up. After you give your credentials, your repository will be copied to github. \

After you push your local branch, go back to github to see your changes.

Note that push is NOT the same as cloning from your local repository to github. Cloning implies the copying of an entire repository. When you push, you push a single branch.

There is a way to push all your branches, but I only recommend doing that if you are adding some prexisting repository to github for the very first time. All other pushes should be a single branch. (Further reading on push: Git documentation)

Exercise: Forking

• Navigate to my lab02 repo
• Create a fork of the lab02 project by clicking the fork button in the upper right corner
• Navigate back to you profile page
  • You should see a listing for the lab02 repo under your profile now

What just happened? You created a fork of an existing github repository. Again, forking is an entirely github idea - nothing has changed on your local machine. Essentially, you cloned my repository but the clone is being housed on github instead of your local machine.

What do now:

• On your local machine:
  • Make a clone of your fork
  • Use the URL from your fork of your repository, not mine

Okay, now you have a local copy of your fork of my repository. Now you can work and make changes to the local copy and push them to your fork. If you and I were collaborating, you could make changes then create a pull request for me, which would allow me to review and potentially accept the changes you had made on your fork.

For the purposes of this lab, you simply modify your fork of the repository.

Exercise:

• In your local repository, create working method definitions for all Linked List methods that currently have dummy returns
  • Look for TODO notes in the LinkedList.hpp
• Create series of commits that represent logical changes to the code until you have a working a LinkedList class
• Use the provided test code to verify your changes work
• After you have it working locally, push your master branch to your fork

What to submit

Email your TA a link to your github profile. Follow the submission instructions below.

Rubric

• [25pts] Story Repository
  • [10pts] Contains a current Story.txt
  • [15pts] master log contains a commit history representative of lab 01
• [70pts] Linked List Repository
  • [50pts] The score produced by the Test Suite divided by 2
    • To get all 50pts, the Test Suite score must be 100
    • A Test Suite Score of 50pts would result in you getting 25pts for this section of the lab
  • [20pts] Commit history
    • Each commit represent a single logical change (e.g. You should NOT just have 1 commit that reads "Implement all the methods. Done"
    • At a minimum, you should have a commit per method definition
    • If you add or change any existing member methods or variables, that should be noted in a commit
    • Commits are descriptive and written in the imperative tense
• [5pts] Email Subject line matches requirements

Only repositories available through your github profile will be considered for a grade.

Submission Format

• Email Subject lines:
  • EECS448 LastName FirstName StudentID Lab##
• If a tarball is attached, format the file name of the tarball as follows
  • EECS448-LastName-FirstName-StudentID-Lab##.tar.gz

Lab 02 does not have a tarball component.