Merge pull request #50 from githubtraining/new-graphics

[WIP] Add New Graphics

Author: brianamarie

book/09_merging_pull_requests.md

@@ -6,6 +6,8 @@ Now that you have made the requested changes, your pull request should be ready
 
 When you merge your branch, you are taking the content and history from your feature branch and adding it to the content and history of the `gh-pages` branch.
 
+![Merging Pull Requests](img/merging-prs.png)
+
 Many project teams have established rules about who should merge a pull request.
 
 - Some say it should be the person who created the pull request since they will be the ones to deal with any issues resulting from the merge.

book/13_workflow_review_project_github_games.md

@@ -4,6 +4,8 @@ In this section, we will work on a project repository called `github-games`.
 
 A `github-games` repository has been created for you in the githubschool organization. You can access the repository at `https://github.com/githubschool/github-games-username`.
 
+If you're using the Fork and Pull Workflow, [don't forget to look in the appendix for a more thorough explanation](app_fork_workflow.md).
+
 ### Workflow Review: Updating the README.md
 
 Now you will practice the GitHub Flow from beginning to end by updating the link in the README to point to your fork of the repository.

book/14_git_bisect.md

@@ -14,6 +14,8 @@ Using a binary search, `git bisect` can help us detect specific events in our co
 
 `git bisect` works by cutting the history between two points in half and then checking you out to that commit. You then check whether the bug/feature exists at that point and tell Git the result. From there, Git will do another division, etc until you have located the desired commit.
 
+![Git Bisect](img/git-bisect.png)
+
 > When you are doing a bisect, you are essentially in a detached head state. It is important to remember to end the bisect with `git bisect reset` before attempting to perform other operations with Git.
 {: .warning}
 

book/SUMMARY_CICDONLY_CIRCLE.md

@@ -39,4 +39,8 @@
 
 ## Appendix
   * [Day 1 Activity Instructions](app_Day_1_activities.md)
+  * [Day 2 Activity Instructions](app_day2_mergeconflict.md)
   * [Workflow Guide](App_a_workflow_guide.md)
+  * [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md)
+  * [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md)
+  * [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md)

book/SUMMARY_CICDONLY_TRAVIS.md

@@ -37,6 +37,10 @@
   * [Travis CI](35_travisCI.md)
   * [Partner Activity](37_partner_activity.md)
 
-## Appendix
-  * [Day 1 Activity Instructions](app_Day_1_activities.md)
-  * [Workflow Guide](App_a_workflow_guide.md)
+  ## Appendix
+    * [Day 1 Activity Instructions](app_Day_1_activities.md)
+    * [Day 2 Activity Instructions](app_day2_mergeconflict.md)
+    * [Workflow Guide](App_a_workflow_guide.md)
+    * [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md)
+    * [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md)
+    * [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md)

book/SUMMARY_CICD_FULLGH4D_CIRCLE.md

@@ -46,5 +46,8 @@
 
 ## Appendix
   * [Day 1 Activity Instructions](app_Day_1_activities.md)
+  * [Day 2 Activity Instructions](app_day2_mergeconflict.md)
   * [Workflow Guide](App_a_workflow_guide.md)
+  * [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md)
+  * [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md)
   * [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md)

book/SUMMARY_CICD_FULLGH4D_TRAVIS.md

@@ -46,5 +46,8 @@
 
 ## Appendix
   * [Day 1 Activity Instructions](app_Day_1_activities.md)
+  * [Day 2 Activity Instructions](app_day2_mergeconflict.md)
   * [Workflow Guide](App_a_workflow_guide.md)
+  * [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md)
+  * [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md)
   * [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md)

book/SUMMARY_GH4D.md

@@ -39,4 +39,5 @@
   * [Day 2 Activity Instructions](app_day2_mergeconflict.md)
   * [Workflow Guide](App_a_workflow_guide.md)
   * [How to Generate Jekyll Sites Locally](app_how_to_generate_locally.md)
+  * [Fork and Pull Workflow and Multiple Remotes](app_fork_workflow.md)
   * [End of Training: Cleaning Loaner PCs](App_clean_loaner_pc.md)

book/app_fork_workflow.md

@@ -0,0 +1,23 @@
+## Fork and Pull Workflow
+
+Let's distinguish between a few vocabulary words in Git and discuss a common workflow that involves forking.
+
+As in the picture below, all of our work generally starts from one parent repository. We call this the **parent** repository, but we can sometimes call it different things depending on _how_ we work with it.
+
+For example, when we **clone** a repository by creating a local copy on our machine, we refer to that original remote repository as **origin**.
+
+When we create branches, we can create them on our local **clone** _and_ on the remote **origin**.
+
+![Clone vs Branch vs Fork](img/clone-branch-fork.png)
+
+Things start to get tricky when we start talking about forking. A **fork** is a remote copy of a repository with a different owner. When you have a new remote **fork**, you would refer to the parent remote as **upstream**.
+
+![Fork Workflow](img/origin-upstream.png)
+
+If you cloned the fork, you would refer to your own fork as **origin**, and the parent as **upstream**.
+
+![Fork Workflow](img/fork-from.png)
+
+When you want to return work back to the **origin** or **upstream** repositories, you would push back to **origin**, then open a pull request between the remote forks.
+
+![Fork Workflow](img/fork-to.png)