diff --git a/readme.md b/readme.md index eaa2c8b..1ec12ac 100644 --- a/readme.md +++ b/readme.md @@ -5,9 +5,11 @@ Location: SF ![](https://ga-dash.s3.amazonaws.com/production/assets/logo-9f88ae6c9c3871690e33280fcf557f33.png) - + - + + + # GitHub Collaboration @@ -27,7 +29,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. @@ -39,7 +40,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 +54,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 +82,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 +98,7 @@ There are two main scenarios for collaborating on coding projects: - - + ## Practice: Create and resolve a merge conflict @@ -108,21 +107,22 @@ 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. - + ## Talking Points for Teams @@ -136,7 +136,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