From d6b6b5d63ac76d1983046e2b73a6c36d1c9ab456 Mon Sep 17 00:00:00 2001 From: Zeb Tim Girouard Date: Mon, 8 May 2017 10:43:56 -0600 Subject: [PATCH 1/3] Updating notes and tiing --- readme.md | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/readme.md b/readme.md index eaa2c8b..f215905 100644 --- a/readme.md +++ b/readme.md @@ -5,9 +5,9 @@ Location: SF ![](https://ga-dash.s3.amazonaws.com/production/assets/logo-9f88ae6c9c3871690e33280fcf557f33.png) - + - + # GitHub Collaboration @@ -39,7 +39,7 @@ Location: SF * **Use** git to stage and commit changes locally. * **Explain** what the following terms mean for GitHub: pull, push, fork, clone, pull request. - + ## Branches @@ -53,22 +53,21 @@ Terminology: HEAD is simply a reference to the current or most recent commit! -###Q. Why is branching an important part of git? - +### Q. Why is branching an important part of git? > A. Branches are useful for many reasons, but some of the most common ones: -> 1. To allow experimentation. By switching to a new branch, we can experiment, -and if the experiment fails, we can delete it and easily switch back to master -(or another branch of our choice). If it succeeds, we can merge those changes -into master. -2. To allow work to proceed on multiple features (or by multiple people) without -interfering. When a feature is complete, it can be merged back into master. -3. To allow easy bug fixes on a stable version while features are being developed. + 1. To allow experimentation. By switching to a new branch, we can experiment, + and if the experiment fails, we can delete it and easily switch back to master + (or another branch of our choice). If it succeeds, we can merge those changes + into master. + 2. To allow work to proceed on multiple features (or by multiple people) without + interfering. When a feature is complete, it can be merged back into master. + 3. To allow easy bug fixes on a stable version while features are being developed. - + ## `git fetch`, `git merge`, and `git pull` @@ -82,7 +81,7 @@ Fetching, merging, and pulling are related commands that you will frequently use ![image](https://cloud.githubusercontent.com/assets/6520345/15020568/663aa804-11d7-11e6-83f6-774e43bc2ea6.png) - + ## Collaboration Workflows @@ -98,8 +97,7 @@ There are two main scenarios for collaborating on coding projects: - - + ## Practice: Create and resolve a merge conflict @@ -122,7 +120,7 @@ What happens if two people on a team change the same file? Merge conflicts (oft - + ## Talking Points for Teams @@ -136,7 +134,7 @@ What happens if two people on a team change the same file? Merge conflicts (oft 5. When merge conflicts arise, it's up to the individual contributor to resolve them. But work with your team! Follow the steps for [resolving merge conflicts locally](#resolving-merge-conflicts-locally), make sure to delete any merge junk from your code, and then push your cleaned-up branch to GitHub. - + ## Resources From 9606922bd8f64a53ac841a6dd3da6435ed462282 Mon Sep 17 00:00:00 2001 From: Zeb Tim Girouard Date: Tue, 9 May 2017 10:50:36 -0600 Subject: [PATCH 2/3] Clarifying directions --- readme.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/readme.md b/readme.md index f215905..636c873 100644 --- a/readme.md +++ b/readme.md @@ -27,7 +27,6 @@ Location: SF *After this workshop, developers will be able to:* - - **Create** their own git branches and explain a pattern for using branches to develop a full application. - **Make** a new repository and add another developer as a collaborator. - **Resolve** a merge conflict. @@ -106,17 +105,18 @@ What happens if two people on a team change the same file? Merge conflicts (oft 1. Pair up. Pick one person to be Partner1 and one to be Partner2 throughout this exercise. 2. Have Partner1 create a brand new repository on GitHub. -2. Partner1 should now create a new project directory locally, generate one `index.html` file, create a `readme.md` with some content, and push the new app to the remote repository. +2. Partner1 should now create a new project directory locally, generate a boilerplate `index.html` file, create a `readme.md` with some content, and push the new app to the remote repository. 4. Partner1 should [add Partner2 as a collaborator](https://help.github.com/articles/adding-collaborators-to-a-personal-repository/) 3. Partner2 (the collaborator) should then clone this repository. -4. Each person is about to change the README completely, and add 2 elements to `index.html`. FIRST! Each person should start a new feature branch. (Name them different things, like `better-readme` and `best-readme`.) You can check that you have all of the branches with `git branch`-that will print all of the branch names. -5. Now, have Partner1 (repo creator) commit and push the work to GitHub on *their* branch. (E.g., `git push origin better-readme`.) Open a pull request from the new branch to the master branch. -6. Partner2 (the collaborator) should commit their changes and push the work to GitHub on *their* branch. (E.g., `git push origin best-readme`.) Open a pull request from the new branch to the master branch. -7. Accept Partner1 (repo creator)'s pull request first. It shouldn't have any merge conflicts with the master branch, so you can just merge it in on GitHub. -8. The second pull request should be a little more interesting. We hope that we have created at least one merge conflict. Partner2 (the collaborator) should get the latest code by `pull`ing the latest code from `origin master` (with Partner1's recently pulled-in changes). Then they should start at step 3 of [this guide for resolving the merge conflict locally](https://github.com/SF-WDI-LABS/shared_modules/blob/master/how-to/github-collaboration-workflow.md#resolving-merge-conflicts-locally) -9. Partner2 should push the fixed version to GitHub. -10. Finally, go back to the GitHub repository and accept Partner2's pull request (there should not be any merge conflicts any more). -9. Feel free to delete this practice repository from your local machine and from GitHub. This workflow was intentionally sloppy and I'm hoping that you learned a little bit of what *not* to do. +4. Each person should start a new feature branch. (Name them different things, like `better-readme` and `best-readme`.) You can check that you have the new branches with `git branch`-that will print all of the branch names. Make sure you **do all your work on your own branch**, NOT on `master`. +5. Each person should now change the README significantly, and add 2 elements to `index.html`. +6. Now, have Partner1 (repo creator) commit and push the work to GitHub on *their* branch. (E.g., `git push origin better-readme`.) Open a pull request from the new branch to the master branch. +7. Partner2 (the collaborator) should commit their changes and push the work to GitHub on *their* branch. (E.g., `git push origin best-readme`.) Open a pull request from the new branch to the master branch. +8. Accept Partner1 (repo creator)'s pull request first. It shouldn't have any merge conflicts with the master branch, so you can just merge it in on GitHub. +9. The second pull request should be a little more interesting. We hope that we have created at least one merge conflict. Partner2 (the collaborator) should get the latest code by `pull`ing the latest code from `origin master` (with Partner1's recently pulled-in changes). Then they should start at step 3 of [this guide for resolving the merge conflict locally](https://github.com/SF-WDI-LABS/shared_modules/blob/master/how-to/github-collaboration-workflow.md#resolving-merge-conflicts-locally) +10. Partner2 should push the fixed version to GitHub. +11. Finally, go back to the GitHub repository and accept Partner2's pull request (there should not be any merge conflicts any more). +12. Feel free to delete this practice repository from your local machine and from GitHub. This workflow was intentionally sloppy and I'm hoping that you learned a little bit of what *not* to do. From c46d9f3a2c672ed987e31b4d18b6f194d0cc8add Mon Sep 17 00:00:00 2001 From: ZebGirouard Date: Tue, 9 May 2017 11:24:40 -0600 Subject: [PATCH 3/3] First change --- readme.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/readme.md b/readme.md index 636c873..1ec12ac 100644 --- a/readme.md +++ b/readme.md @@ -5,6 +5,8 @@ Location: SF ![](https://ga-dash.s3.amazonaws.com/production/assets/logo-9f88ae6c9c3871690e33280fcf557f33.png) + +