CSET-115 Week 3

Project: Git Collaboration

Last week you all worked on your own versions of the Adventure Game and converted it to work with JavaScript and the DOM. This week, we'll improve those projects. But not our own.

Instead, we'll practice the commands we learned to collaborate using git. We'll follow the workflow encouraged by GitHub and used for many open-source projects by creating Issues and submitting Pull Requests to your classmates' projects.


Setup

Note: You should have done this during the code review, but here's the steps to view the code of a team mate's fork in your local repo in case you didn't or you forget them.

  1. Open your terminal and change to your DOM Adventure Game repo: cd code/dom-adventure-game
  2. Make sure your repository doesn't have any un-committed changes: git status
  3. Go to GitHub and find their fork of the code on their account. Copy the git URL as if you were going to clone it.
  4. Add their remote repo: git remote add <their-name> <their-url>
  5. Download their commits: git fetch <their-name>
  6. Make a new local branch to store their commits: git branch <new-branch> <their-name>/<their-branch>
    • Remember that the / character separates a remote and a branch name, so we shouldn't use it in new branch names.
    • An example is zachfedor/main which means the branch named "main" on a remote named "zachfedor".
    • A good branch name is short and concise, so your branch might be name "zachs-main" to represent your local copy of a remote branch.
    • You can't call it "main" too since you already have a "main" branch.
  7. Checkout their commits: git checkout <new-branch>

To return to your branch, make sure the working directory is clean with git status and then use checkout to see whatever branch you want, like git checkout main.


Instructions

  1. During the code review for this project, you probably ran into something that could be improved on a classmate's project. Go to their repo on GitHub and submit at least 2 separate Issues for these improvements.
    • Improvements can be a bug fix, refactored code, or a new addition.
    • When writing issues, be respectful. You're trying to help the maintainer, and if they don't appreciate your comments then your issue won't be taken seriously.
    • Keep each issue atomic, or standalone. For example, "fix flexbox style and broken button" are really two separate issues, while "fix indentation problems" might be a bunch of changes across many files but is one overarching issue.
  2. While working on your local branch of their code, try to fix one of these issues. Imagine it's now your project, what do you need to do to satisfy the requirements of the Issue? Add and commit on their branch like normal.
  3. When you're done, push your commits to your repo on GitHub. You can't push to theirs since you don't have access.
  4. Visit their repo on GitHub and open a Pull Request.
    • Make sure you are targeting the correct remotes and branches. The arrow should point from your new code to their old code.
    • In the description, create a link to the original Issue you posted.

To submit the project, post a link to the open Pull Request page that you created to your Slack channel. From there, the maintainer and I should be able to find the link to the original Issue.