Skip to main content

GitKit (2nd ed.): 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. The exercises in this section ask you to repeat the process of finding an issue, fixing it and creating a pull request as you did in Chapter 3 Working Locally and Upstreaming Changes. This will give you more good practice. But also, the issue you will be fixing this time has been carefully planned as a setup for the next chapter too!
🔗

Subsection 4.8.1 Process of Fixing an Issue

Before you get into the work of fixing a new issue, it will be helpful to review the steps that you’ll need to use and they were and how they fit together.
🔗

Exercises

1.
The steps you carried out in Chapter 3 are listed below in a jumbled-up order, drag them to the right to arrange them the proper order.
Hint.
Think about the full process that you worked through from claiming your Round1 issue through making a pull request for your changes.
🔗
🔗
🔗

Subsection 4.8.2 Claim a Round2 Issue

Now it is time to find a new issue to work on.
🔗

Exercises

1.
    Go to the issue tracker in the upstream FarmData2 repository that you are using for your course.
    🔗
    Use the "Labels" dropdown in the issue tracker to filter for issues labeled with the “Round2” tag.
    🔗
    How many issues have the Round2 tag?
    🔗
  • 4
  • Correct.
  • 6
  • Be sure you have selected the "Round2" label.
  • 35
  • Be sure you have selected the "Round2" label.
  • 39
  • Be sure you have selected the "Round2" label.
Hint.
Make sure you have the Round2 tag selected in the "Labels" dropdown. The "Labels" dropdown is between the "Author" and "Projects" dropdowns.
🔗
2.
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 as it was in Round1. Try to spread out across the issues so that multiple people have commented that they are working on each one.
🔗
Give the number of the issue you chose.
🔗
🔗
🔗
🔗

Subsection 4.8.3 Fix the Issue

Now that you have an issue to work on, it is time to fix it. But before you actually start fixing the issue, let’s review some of the Git commands and a few other important ideas you’ll need to use to carry out the steps from Exercise 4.8.1.1.
🔗

Exercises

1.
(a)
Hint.
The command reference that you created in Section 3.9 may come in handy here.
🔗
(b)
    When creating branches you should always use a name that describes what is being done in the branch, without being too long. This will help you to remember the purpose of the branch, but not make it onerous to type.
    🔗
    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 identifies the issue but you would have to remember what that issue is to know what the branch does.
  • adding-link
  • This branch sort of describes what is being done, but isn’t specific enough to know what the branch really does.
  • link-nsf-award
  • Correct. This branch name has enough context to describe what the branch does without being excessively long.
  • add-link-to-nsf-award-in-acknowledgements-section
  • This branch name is very descriptive but seems excessively long. Can you imagine typing that over and over again?
Hint.
Refer back to Section 3.2 Creating a Feature Branch for information on branch names.
🔗
(c)
    When writing commit messages for the git commit the message should be descriptive of what the changes in the commit do.
    🔗
    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?
    🔗
  • Adds the URL for GNOME to the acknowledgements section of the REAMDE.md 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.md.
  • This commit message doesn’t provide enough information about what has been changed in the README.md file.
  • Fixed a typo.
  • This commit message is too generic and does not actually describe the changes that would be committed for this issue.
Hint.
Refer back to Section 3.6 Committing to Your Local Repository for information on commit messages.
🔗
🔗
🔗
🔗

Subsection 4.8.4 Upstreaming the Changes

Now that you have fixed the issue and pushed your feature branch, the last thing to do is to make a pull request.
🔗

Exercises

1.
Make a pull request for your feature branch to the upstream repository for your course.
🔗
Enter the full URL of your PR below.
🔗
🔗
2.
Because there were a limited number of “Round2” issues, other students in your class will have worked on the same Round2 issue as you id. Thus, they will also have made pull requests that contain changes to the same line(s) in the README.md file as you did. The tasks below will ask you some questions about this situation.
🔗
(a)
    Assume for now that the maintainers have not merged any pull requests that fix the Round2 issue that is addressed by your pull request.
    🔗
    Which of the following statements best describes this situation.
    🔗
  • GitHub will indicate that your PR can be merged automatically because it does not contain any conflicts with the upstream main branch.
  • Correct. While your PR changes the same lines of the README.md file as the other PRs, none of those PRs have been merged into the upstream main. Thus, your PR will not contain any conflicts with the upstream main branch.
  • GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream main branch.
  • While your PR changes the same lines of the README.md file as the other PRs, none of those PRs have been merged into the upstream main. Thus, your PR will not contain any conflicts with the upstream main branch.
  • If your PR was the first one submitted for your Round2 issue, GitHub will indicate that it can be merged automatically, otherwise it will indicate that it cannot because there is a conflict with the upstream main.
  • The order in which the PR’s are created does not matter. A conflict will only arise after the changes in one of the PRs are merged into the upstream main. Thus, because no PRs have been merged there is no conflict between your PR and the upstream main at this point.
  • GitHub will indicate that your PR can be merged automatically because it does not contain conflicts with any of the other PRs that have been submitted for your Round2 issue.
  • Your PR and the others for your Round2 issue change the same lines, so in some sense your PR conflicts with the other PRs. However, none of them have been merged into the upstream main yet. Thus, there is no conflict between your PR and the upstream main at this point.
Hint.
Visit your PR in the upstream repo and see what GitHub tells you about whether it can be merged or not.
🔗
(b)
    Now assume that the maintainers have merged one of the other pull requests (not yours) that fix your Round2 issue.
    🔗
    Which of the following statements best describes this situation.
    🔗
  • GitHub will indicate that your PR can be merged automatically because it does not contain any conflicts with the upstream main branch.
  • Your PR will have changed the same lines in README.md as the merged PR. The changes from the merged PR are now in the upstream main branch. Thus, your feature branch will now have conflicts with the upstream main branch and will not be able to be merged automatically.
  • GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream main branch.
  • Correct. A PR for the Round2 issue you were working on has been merged into the upstream main. Your PR contained changes that changed the same lines of the README.md file as the merged PR. Thus, your PR will have conflicts with the upstream main branch and will not be able to be merged automatically.
  • If your PR for your Round2 issue was submitted before the other one was merged, GitHub will indicate that your PR can be merged automatically.
  • The order in which the PR’s are created does not matter. GitHub reevaluates whether there is a conflict each time you visit the PR page. Thus, because the other PR was merged, and it changed the same lines in README.md as your PR, your PR will now contain a conflict with the upstream main branch.
  • GitHub will indicate that your PR cannot be merged automatically because it contain conflicts with all of the other PRs that have been submitted for your Round2 issue.
  • Your PR will in some sense contain conflicts with all of the other PRs for the same Round2 issue. However, only the conflict with the upstream main branch matter here. That conflict was created when the other PR for your Round2 issue was merged.
Hint.
Visit your PR in the upstream repo and see what GitHub tells you about whether it can be merged or not.
🔗
🔗
🔗
🔗
You have attempted 1 of 10 activities on this page.
🔗
PrevTopNext