1 of 18

Issues
Labels
Milestones
GitHub for Collaboration
Projects & other tools

Outline - 2nd Half

2 of 18

Issues

Issues are your “to-do’s” - they are the tasks you need to perform, the bugs you need to fix, and things you want to accomplish.

https://github.com/tiimgreen/github-cheat-sheet

3 of 18

GitHub Issues

Issues help you keep track of the work happening on your project; you can use labels to organize issues.

4 of 18

5 of 18

6 of 18

Collaborators

Have permission to make changes to files w/o your approval
People you’ve invited in. Your inner circle.

Contributors

Can make suggested changes but you have to approve them before they are published.
Anyone can be a contributor.

Collaborators vs Contributors

Okay… who is a collaborator? Here’s where you’re all going to pair up and start collaborating on GitHub.

Everybody find a partner. Each of you open a new tab or window and go to your partner’s repository and click on the Issues tab.

Create an issue on your partner’s repository just like you did in your own.

Once you have submitted it, you are now a contributor. You have contributed a suggestion in the form of an issue to their repository. Now this is just an issue. Not a change to any files, so you did not have to get their approval. If you had wanted to change one of the existing files in their “code” tab, you would have needed their permission through something called a “pull request”. We’ll get to that in a bit. Since this is just making a comment in an issue, you’re not changing files so don’t need permission.

Now, go back to the tab or window for YOUR repository, and you should see you have a new issue submitted by your partner.

7 of 18

8 of 18

9 of 18

10 of 18

11 of 18

Forking a repo

Forking means making your own copy of a repo

Once you fork a repo, you can do whatever you want to it, without affecting the original repo

12 of 18

13 of 18

14 of 18

15 of 18

At the top, it is showing that you are attempting to merge into the original repository, the changes you made in your copy of the repository.

You will see the name of your partner’s repository first and it is comparing it to the changes you made in YOUR copy in YOUR repository.

If there are no conflicts (meaning nobody else has changed the file you changed since you forked it), it will tell you, you are able to merge these two versions into one and you will get a green Create Pull Request button.

Once you do that, it is going to ask you to explain the changes you made. If you did a good enough job with your commit message, don’t worry about this. If you’d like to explain a little more, go ahead. Then hit the green Create pull request button.

Now you should both receive notifications that someone has submitted a pull request to your repository. Go into your repository… NOT your cloned repository or your partner’s repository, but your original repository you’ve been working on all day. Click on your Pull Requests tab and you should see a Pull Request listed there. Go ahead and click on it. Then click the Green Merge Pull request button… and yes, confirm the merge if it asks you.

Now, if you go back and look at your README, you will see the line that was added by your partner now appears in your README… because you gave them permission by accepting their pull request.

Now… I’m going to stop there and see if there are any questions.

16 of 18

Checkpoint

How did that go?
Where did you get stuck?
What was intuitive?
What was not?

17 of 18

Projects

(https://github.com/daniellecrobinson/fellows-class-2016/projects/2)

18 of 18

Bringing it all together

https://github.com/mozilla/global-sprint