Session 4 Readings and Responses

The readings and responses listed here should take you approximately 50 minutes total.

To start this assignment:

1. Click the button in the upper right-hand corner that says Fork. This is now your copy of this document.
2. Click the Edit button when you're ready to start adding your answers.
3. To save your work, click the green button in the bottom right-hand corner. You can always come back and re-edit your gist.

Assignment 1 (30 min)

Read Turing Instructor David Whitaker's article on Git and GitHub

• Use the article and outside resources (Google!) to describe the general process of a collaborative git workflow in the space below.

  When working on a communial GitHub project, your process as a collaborator follows these basic steps.

  ---

1) Create your branch

• First a collaborator creates a branch of the git repository of the branch master. A branch allows you a safe enviornment to expierment with new ideas and features you would like to add to the project. At first I thought a branch and fork were the same thing, but after researching I learned branches are the more offical way registered collaborators work on a project. Whereas forks are pure clones of a project, branches are independent clones of that project that are tracked and closely related to the offical project. Offical project participants create branches, where non-members would create forks of the repo.

2) Add your commits

• Once the work begins on the users fork, they begin adding their commits after adding, changing, or deleting files. Commits allow the collaborator to track the incremental changes they have made to the fork, allowing them to create some transparency in their work history. Each commit is a small unit of change that can be viewed on GitHub.

3) Pull Requests

• Once the user is ready to have their work reviewed, they initiate a pull request. Once a pull request is made other collabortors can review the new changes and discuss their potential implications to the project. The project manager may review the code to see if adheres to company guidelines, or point out potential errors or bugs in the code.

4) Deployment

• Once the branch is ready to go into final testing it is deployed into production. This is the final phase of testing, and if issues occur in this phase the collaborators can roll back to previous deployments.

5) Merge to Master

• After testing and review, if the new branch is still a go it will be merged with the master branch. The changes have now been offically made, and the pull request will keep record of the changes that were made with this merge.

Assignment 2 (10 min)

• Watch Tim's video on classes and objects.

• In the space below, come up with your own example of a class (like "bottle") and several objects (like "spray bottle", "nalgene", etc.):

(Class) Keyboard

---

Objects

• roland_Keyboard
• yamaha_keyboard
• akai_keyboard

---

Attributes

• color
• weight
• number_of_keys
• outputs

Assignment 3 (60 min)

Skim this intro to Markdown. It's not necessary to memorize because you can always come back to it as a reference.

Next, a new gist of your own by clicking the New Gist button in the upper right-hand corner of the screen. Create a "Beginners Guide to Git" documenting your git knowledge so far using Markdown. Incorporate each of the following features into your Gist:

• at least two headings of different sizes

• at least one numbered list

• at least one bullet point list

• at least one bold word/phrase

• at least one italic word/phrase

• at least one code block

• at least one inline code block (greyed text)

• at least one image

• Paste the link to your gist here: https://gist.github.com/tylorschafer/2a81091cfd370cc252d741094598da81