-
Notifications
You must be signed in to change notification settings - Fork 5
lab 3
Friday Oct 9 by Midnight.
This week we are going to practice using git to manage multiple simultaneous changes, and git merges. To do this we'll continue to add some features 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 parallel
- adding features to existing code
- using
git merge - fixing merge conflicts
- how to find and identify commits on GitHub
You are going to make changes to your repo. Pick at least 2 of the following features to add to your project:
- Make sure the program honours the
CLICOLORenvironment variable. IfCLICOLOR=1is set, the program can use colours in the output. IfCLICOLOR=0is set, do not output any colour. - Make sure that the program exits with an appropriate error code. If there are no errors (all links are good), exit with
0. Otherwise, exit with a non-zero exit code. - Add a
-j,--json, and/or\jflag, which causes the program to output JSON. The JSON output should look like[ { "url": 'https://www.google.com', "status": 200 }, { "url": 'https://bad-link.com', "status": 404 } ] - Support
--all,--good, and--badflags. The--allflag is the default, and if none of these are present, it will display good and bad URLs. The--goodflag causes only good URLs to get displayed; the--badflag causes only bad URLs to get displayed.
In your project's GitHub repo, file Issues for each of the features, and discuss the changes you will make.
For each of your features, create a new branch. For example, if you filed Issue #10 and Issue #11 you need to create 2 new branches off of master:
$ git checkout -b issue-10 master
$ git checkout -b issue-11 masterAll work for Issue #10 should happen on the issue-10 branch. All work for Issue #11 should happen on the issue-11 branch.
None of your work should happen on master! All work should be done on one of the topic branches you just made.
Throughout the week work on your two features. You are free to discuss strategies and ideas with your classmates, but you must do your own work in the respective branches you created above (no pull requests this time, sorry!).
Your two features will likely involve modify the same code. This is fine and to be expected. Resist the desire to share any code between branches! Keep all work for each feature in its own topic branch, and touch as little code as possible in each branch.
You can work on the features one after the other, or in parallel. With software, it's common and often helpful to do more than one thing at a time: if you get stuck on one, you can switch to the other.
When you have completed both features, and each branch contains the necessary code, it's time to merge.
Switch to your master branch and merge the first feature branch (e.g., issue-10):
$ git checkout master
$ git merge issue-10This merge should go smoothly, and assuming you haven't changed anything on master since you created your branches, git will do a fast-forward merge. Confirm that it did. If it didn't, determine why not.
After you've merged your first branch, it's time to merge the second (e.g., issue-11) into master:
$ git checkout master
$ git merge issue-11This merge will likely require a three-way recursive merge, since git can't fast-forward your master branch. You may also need to deal with merge conflicts.
Make sure you fix any/all merge conflicts before you complete the merge.
When you're done, the master branch should contain the code for both feature branches, and both features should be working. Make sure your merges didn't break anything!
Test, test, test, and test again. Is the master branch still working? Do you need to fix anything before going to the next step? If so, commit to master to correct the problem(s). Keep track of this, and discuss in your blog below.
Push your fully merged and tested master branch to GitHub:
$ git push origin masterClose your original issues, and provide a link in the comments to the merge commit on GitHub that closes the feature. On GitHub the URL for a commit follows this format:
https://github.com/username/project-name/commit/commit-sha
For example, the ddeaf180 commit for this repo is at:
When you close your issue, add a comment like this:
Write a blog post about the process of working in parallel branches in your project. In your post, include links to everything you discuss (e.g., the project repo, your issues, your merge commits).
Discuss what you did, the changes you made for your features, and the process of doing your merges. What problems did you have? What did you learn? What would you do differently next time?
When you have completed all the requirements above, please add your details to the table below.