-
Notifications
You must be signed in to change notification settings - Fork 5
lab 4
Sunday Oct 18 by Midnight.
This week we are going to practice using git remotes and merges to collaborate with our peers on some code changes. Instead of using GitHub's Pull Request feature, which automates the process, we're going to do this manually using just git.
To accomplish this we'll continue to add a new feature to our link checker repos. This lab will help you practice the following:
- creating branches to work on new features and fix bugs
- working on code changes in another project you didn't write
- using
git remoteand sharing commits withgit push,git pull, andgit fetch - using
git mergeand doing practice merges - fixing merge conflicts
NOTE: it is highly recommended that you watch this week's video on git remotes before you start this lab.
Users want to be able to run our link checker tools and be able to include an extra argument, a file of URL patterns to be ignored. This week's feature will add the ability to exclude URLs from our check based on a URL pattern file.
For example, imagine you want to check all the URLs in the file index.html, but you want to ignore all URLs that start with https://senecacollege.ca or https://learn.senecacollege.ca. First, create a text file that looks like this:
# Ignore All Seneca College URLs
https://senecacollege.ca
# Ignore all Learn@Seneca URLs
https://learn.senecacollege.ca/
The file is a simple text file where each line is either a URL (line starts with http:// or https://) or an optional comment (line starts with #, and can be ignored).
Assuming we saved that file to ignore-urls.txt, we could use it like this:
$ tool-name --ignore ignore-urls.txt index.htmlThis would check all URLs in index.html, but ignore and skip any URLs that start with https://senecacollege.ca or https://learn.senecacollege.ca/.
The --ignore, -i, \i flag is optional, and if present should take a filepath and use it to load and parse an ignored URLs text file. If the ignore file isn't found, give an appropriate error message. Otherwise, all URLs should be checked against this list to see if they need to be ignored.
Here are some example ignore files.
First, a file with only a comment is valid:
# 1. Empty file, nothing will be ignored
Second, a file with multiple comments and a URL is valid:
# 2. File with a comment and single URL that matches any URL
# that starts with https://www.google.com, for example:
#
# https://www.google.com/index.html would match
# https://www.google.com/ would match
# https://www.google.ca would NOT match
https://www.google.com
Third, a file that has no comments and only URLs is valid:
https://www.google.com
Fourth, a file with anything other than a comment (#) or URL (http://, https://) is invalid:
# This is invalid. It doesn't use http:// or https://
www.google.com
If the file isn't valid, give an appropriate error message and exit. Otherwise, use the file's URL patterns to test all the URLs being processed, skipping any that match.
You are asked to add this new ignore feature to another student's link checker repo. You may NOT add it to your own. Pick a repo from the 0.1 Submissions list, ideally one you haven't worked on before.
Only one student can add the feature per repo. Before you begin, check to see if an Issue is already filed for this feature. If not, file a new Issue in the other student's repo letting them know what you intend to do, and get their permission to start the work (e.g., via Slack or a comment in the Issue on GitHub).
If you notice two people filing the same issue in your repo, make sure you close the second (third, ...) one as a duplicate of the first.
Fork and clone their repo to your local machine.
Create a branch for this work. If you filed Issue 6, consider naming your branch issue-6.
Do all of your work on this branch, committing changes as you go.
You should also push your branch to your fork on a regular basis. To do so (substitute your branch name for issue-6):
$ git push origin issue-6Throughout the week, as you work on the feature, keep in regular contact with the owner of the repo. You are likely going to run into problems, have questions, or need advice on how they want something handled.
Remember, you don't need to do this all by yourself. Make use of the community, talk to people, share your ideas and questions. Open source is about collaboration. Use Slack and the GitHub Issue you filed to discuss your work.
As you work on the feature, commit and push all the changes on your branch to your fork:
$ git checkout issue-6
$ git push origin issue-6Let the other student know that you're done in the GitHub Issue, and ask them to add your fork as a remote, fetch, and test your branch (see Step 5 below).
They will likely have feedback for you as you go, and ask you to make some changes. They may also want to share a branch with you, based on your changes. Work with the repo owner to get the code ready to be merged.
Normally we use GitHub Pull Requests to review and merge work from collaborators. This time, we'll use git remotes instead. For this to work, we'll need to add remotes, and share commits and branches between each other.
If your repo is being worked on by another student, get them to tell you the name of their fork and the name of the branch they are working on. Next, add them as a remote to your local repo:
$ git remote add <name-of-student> <https://git-url-of-other-studnet-fork.git>Next, fetch their work into your local repo:
$ git fetch <name-of-student>Now set up a tracking branch in your local repo, so you can track the work on their branch (substitute the name of the student and branch for issue-6):
$ git checkout -b issue-6 <name-of-student>/issue-6Use this branch to review and test their work. Don't commit to it, though. We'll leave it "clean" of our changes.
If you ever need to update your local issue-6 branch to see new changes the other student has pushed to their fork, you can do that with git pull:
$ git checkout issue-6
$ git pull <name-of-student> issue-6NOTE: if you do want to commit something to it, start a new branch first (substitute the name of the student and branch for issue-6):
$ git checkout -b issue-6-fix <name-of-student>/issue-6
$ git add file
$ git commit -m "Fixing x, y, z..."
$ git push origin issue-6-fixYou can share this work with the other student by having them add your repo as a remote and fetching:
$ git add upstream <https://git-url-of-original-studnet-repo.git>
$ git fetch upstream
$ git checkout -b issue-6-fix upstream/issue-6-fixNow they can look at or test your work on the issue-6-fix branch. They might also decide to git merge it into their existing issue-6 branch:
$ git checkout issue-6
$ git merge issue-6-fixIf you have any trouble working with git during this process, make sure you ask for help in Slack.
When you have completed working on the feature, and fixed any issues your reviewer has made, commit and push all the changes on your branch to your fork:
$ git checkout issue-6
$ git push origin issue-6Let the other student know that you're done in the GitHub Issue, and ask them to look over your latest changes on your branch.
If they are satisfied, they can merge your work and push it to their upstream repo:
$ git fetch
$ git checkout master
$ git merge <student-name>/issue-6
$ git push origin masterCheck the original upstream repo's master branch, and make sure this new work is all there. If it is, close the Issue and complete the submission below. If it isn't, figure out what went wrong, and get help on Slack.
Write a blog post about the process of working on this new feature using remotes. First, how did the code itself go? Did you run into any problems? How did you tackle the work? Second, how did it go using git? Did you find any of it difficult? How did you get around this? What would you do differently next time? What did you learn from the experience?
When you have completed all the requirements above, please add your details to the table below.