Tag: pull requests

How to have pull requests added to an Issue’s timeline – 045

You might have noticed that when you create a pull request that refers to an issue, you’ll get an autocomplete dropdown.

If you just type in the item number, e.g. #3 (no issue title needed), or click on the desired Issue from the list, you’ll see in the preview that the #3 is automatically hyperlinked. Hovering over the hyperlink shows the Issue title as the tooltip.

After you’ve saved your edits (or created the pull request), go over to the Issue in question and you’ll see the pull request added to the Issue’s timeline.

How to create a pull request for a bug fix on a branch on a forked repo that you’ve pushed to GitHub – 044

This might be my greatest worst blog post title ever.

In previous tips, you’ve created pull requests as part of the commit workflow when you’ve edited or added files directly on GitHub. In other tips, you’ve cloned repos, created branches, made bug fixes, and pushed those changes up to your forked GitHub repo. Now you’ll submit those bug fixes to the base repo via a pull request.

First, switch to the branch that contains the changes you wish to propose to the base repository.

Now to the right of the branch: switch button, click New pull request.

And you’ll see the familiar Pull Request form on the base repo. Remember, PRs are open on the base repo, and not on your forked repo. In fact, you can’t find the pull request tab on your forked repo!

Fortunately, our changes have no conflicts, so we are good to go!

In the forms below, you’ll want to provide a helpful comment. The title of the PR is just the name of the branch as a placeholder, so provide something more meaningful.

Once the PR form is filled out, clicked the Create pull request button, and volia!

The base repo now has a Pull Request created, and there was much rejoicing!

You might notice that it says #4 when there’s only been 2 other pull requests for this repo. Issues and Pull Requests share the same number listings. At the time of this writing, the order in which things were created in this repo are as follows: #1 PR, #2 PR, #3 Issue, and #4 the PR you’re looking at now.

How to still create a Pull Request for a branch in your forked repo if the recently pushed branches button isn’t showing – 037

Suppose you no longer see the message to Compare & pull request your recently pushed branches (as shown below), but you still want to create a Pull Request.

There are 2 other ways to create a Pull Request.

Option #1 – use the Branches list in your repo

You can go to the Branches listing in your repo,

and for the branch you wish to create a new pull request for, click on the

And now you’ll be shown the Open Pull Request form with the same defaults as before. Note again as yesterday, you’re taken to the base repo to open the pull request.

Option #2 – Manually create a Pull Request via the Pull Request tab

I like doing thing manually to truly appreciate what is happening behind the scenes.

First, in your forked repo (e.g. saraford-tips/your-moment-of-github-zen) go to the Pull Requests tab.

Then click on the New pull request button.

Yeah, I’m Captain Obvious here with that above screenshot! But notice what happens. You are again taken to the Open Pull Request page on the base repository.

How to submit a pull request to a forked repo whenever you are ready – 035

Continuing yesterday’s scenario of how to submit a new or updated README.md file to a repo that you’ve forked, let’s say you weren’t ready to fill out the Pull Request. You cancelled the Pull Request form by navigating away from that page. Perhaps you wanted to fix some typos, or you wanted to see how other people filled out their Pull Requests to provide the base fork repo maintainer the most adequate information possible.

Today, you’re ready to submit your changes.

Using saraford-tips/your-moment-of-github-zen as an example, you should still see Your recently pushed branches message bar at the top of your repo. A future tip shows how to manually generate the pull request if you don’t see this message bar.

If you click, Compare & pull request, you’ll see the following screen.

My biggest ah-ha! moment when working with pull requests came to me when I finally noticed that the repo name changes when creating a pull request. Notice in the screenshot that you are no longer on your repo. You are now in the base repo (e.g. saraford/your-moment-of-github-zen).

Remember, a Pull Request is the start of a conversation, and you’re starting that conversation on the base repo. You are going to where they are to start the conversation, versus having them come to you.

The second ah-ha! moment came after I learned to chill out seeing all these dropdowns!

Unlike previous tips where you handled your own merges (via a Pull Request, since that’s the only way to merge via GitHub.com UI), you only saw the base: and compare: branch dropdown boxes. But remember, this time you’re involving a different repo. Because you now need to specify the repo for each branch, there’s twice as many dropdown boxes involved!

Aside: Something that drives me crazy is that I keep thinking the base fork branch should say created-readme, instead of master, because I’m thinking that I want my created-readme branch to show up as a branch on the base fork. It’s like I’m scared the PR will do an automatic merge or something. The best way to understand what is happening when you create a Pull Request is to see it from the maintainer’s point of view, which we’ll get to in future tips. But for now, trust that the defaults are correct. And to skip ahead, what will happen is after the PR is created, you might think that people (either the contributor or maintainer) will see the created-readme as a branch off of the branch: switcher, but this is not the case. The branch isn’t part of this repo. For the maintainer to see the branch, they have to actually clone it from the forked repo, (i.e. user saraford will have to pull from saraford-tips forked repo to get the code for the branch.) So again, a Pull Request is the start of a conversation that says, “Hey maintainer! Go over to this contributor’s repo and pull down their branch from over there!” Another way to think about why the base branch should be master and not created-readme, think of your merges via GitHub.com UI within your own repo. You wouldn’t try to merge created-readme to created-readme. You’d want to merge created-readme into the base branch master, exactly like you’re trying to do here, except that this time it is across repos. Hopefully my thinking out loud is helpful to someone!

The pull request form you see below will be what people will see when they go to the base repo (in this case saraford/your-moment-of-github-zen) and open the pull request item listed in the pull request tab.

The defaults suggest using the content of the last commit, just so it isn’t a blank Pull Request. However, I tend to write my pull requests like I write my text messages, although IRL I use emojis, I swear!! #olds Smile

Now click Create pull request to open the Pull Request in the base repo, as shown in the image below.

Note the image below is from the contributor’s point of view (e.g. in this scenario it is from saraford-tips point of view).

If you don’t see the Compare & pull request message box shown above (the first image in this blog post), it’s no big deal. You can still manually create a Pull Request via the Pull Request tab. Stay tuned. My design goal for the Tip of the Day is One tip == One button click, ideally.