Skip to main content

GitKit (Linux Desktop Edition): Learn git and GitHub in Context

Grant Braught, Lori Postner, Darci Burdge, Ruth Lamprecht, Stoney Jackson, Karl R. Wurst

Section 4.8 Let’s Do it Again

You’ve learned a lot about Git and GitHub. But, to become proficient with these tools takes a lot of repetition and practice. This section asks you to go through the process of finding an issue, fixing it and creating a pull request again. This is good practice but what you will be asked to do has also been carefully planned to set us up for the next chapter too!
🔗

Exercises

Subsection 4.8.1.1 Claiming Another Issue

1.
The issue tracker in the upstream FarmData2 repository being used for these tasks.
🔗
(a)
    Use the label dropdown in the issue tracker to filter for issues labeled with the “Round2” tag. How many issues are tagged with this label?
    🔗
  • 4
  • 6
  • 35
  • 40
Hint.
ADD HINT HERE
🔗
(b)
Clearly there are not enough “Round2” issues for everyone to have their own as was the case with the “Round1” issues. So, this time there will be multiple people working on the same issue.
🔗
Pick one of the “Round2” issues to work on and make a comment on it to indicate your interest in working on it. Note it is not necessary that the issue be assigned to you this time. Try to spread out across the issues so that multiple people have commented that they are working on each one. Give the Issue # and title that you chose.
🔗
🔗
🔗
🔗

Subsection 4.8.1.2 Fixing the Issue and Upstreaming Your Changes

2.
Now you will go through the process of fixing the issue and making a pull request. You will use the same process that you used for your “Round1” issue earlier. That process had a number of steps. They are listed below in a jumbled-up order, determine the proper order.
Hint.
HINT HERE.
🔗
3.
Use the process that you outlined in Exercise 4.8.2 to fix your “Round2” issue and create a pull request to the upstream for your changes.
🔗
Be sure to:
🔗
  • Use a descriptive name for your branch.
  • Use a meaningful message when committing your changes to the feature branch.
  • Provide a useful title and description when creating your pull request.
  • Include a “Closes” or “Fixes” line in your pull request description so that the associated issue number will be closed automatically if your pull request is merged.
🔗
(a)
Hint.
Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
🔗
(b)
    Which of the following would be the best name for a feature branch for issue #37 that adds a link to the NSF award in the Acknowledgements section?
    🔗
  • issue37
  • This branch name doesn’t provide enough information. What is issue 37?
  • adding-link
  • This branch name is too generic.
  • adding-nsf-link-acknowledgement
  • Correct! This branch name describes the work to be done in the branch.
  • nsf-acknowledgement
  • This branch name doesn’t specify what is being done with regard to the NSF acknowledgement.
Hint.
Refer back to the section on creating branches Section 3.2 for information on branch names.
🔗
(c)
    Which of the following would be the best commit message for the fix for issue 38 that adds a link to the GNOME Community Engagement Challenge in the acknowledgements?
    🔗
  • Added the URL for GNOME to the acknowledgements section of the REAMDE file.
  • Correct! This commit message briefly but completing describes the change made.
  • Added URL.
  • This commit message doesn’t provide enough information about the URL added.
  • Updated README.
  • This commit message doesn’t provide enough information about what has been changed in the README file.
  • Fixed typo.
  • This commit message is too generic and does not describe the change for this issue.
Hint.
Refer back to the section on creating branches Section 3.6 for information on commit messages.
🔗
🔗
4.
Give the following information about your pull request. Hint: You can revisit the prior sections to refresh your memory on the terms Base Repository, Head Repository, Base Branch and Compare Branch.
🔗
(g)
The line number of the README.md file that you changed. Hint: use the diff you saw in the prior chapter.
🔗
🔗
🔗
5.
Because there were a limited number of “Round2” issues, other students will have been simultaneously making changes to fix the same lines in the same files. Describe in a few sentences how this might create a problem in the future.
🔗
🔗
🔗
🔗
You have attempted 1 of 15 activities on this page.
🔗
PrevTopNext