Skip to content

Change one #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ZebGirouard wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Change one #1

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d6b6b5d
Updating notes and tiing
ZebGirouard May 8, 2017
9606922
Clarifying directions
ZebGirouard May 9, 2017
c46d9f3
First change
ZebGirouard May 9, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 28 additions & 28 deletions readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,11 @@ Location: SF

![](https://ga-dash.s3.amazonaws.com/production/assets/logo-9f88ae6c9c3871690e33280fcf557f33.png)

<!--Actually 11:05 -->
<!--Useless comment-->

<!--1:30 5 minutes -->
<!--Actually 11:05 WDI2-->

<!--11:15 5 minutes -->

# GitHub Collaboration

Expand All @@ -27,7 +29,6 @@ Location: SF
<!-- specific/measurable goal for students to achieve -->
*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.
Expand All @@ -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.

<!--1:35 5 minutes -->
<!--11:20 5 minutes -->

## Branches

Expand All @@ -53,22 +54,21 @@ Terminology: HEAD is simply a reference to the current or most recent commit!

<img src="https://www.atlassian.com/git/images/tutorials/collaborating/using-branches/01.svg" width="70%">

###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.

<!--Actually 11:12-->

<!--1:40 5 minutes -->
<!--11:25 5 minutes -->

## `git fetch`, `git merge`, and `git pull`

Expand All @@ -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)

<!--1:45 5 minutes -->
<!--11:30 5 minutes -->

## Collaboration Workflows

Expand All @@ -98,8 +98,7 @@ There are two main scenarios for collaborating on coding projects:
<!--Actually 11:28 when devs reading -->
<!--11:37 to get started on lab -->


<!--1:50 50 minutes -->
<!--11:35 45 minutes -->

## Practice: Create and resolve a merge conflict

Expand All @@ -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.

<!--Actually 12:21 -->

<!--2:40 5 minutes -->
<!--11:20 5 minutes -->

## Talking Points for Teams

Expand All @@ -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.

<!--2:45 5 minutes -->
<!--11:25 5 minutes -->

## Resources

Expand Down