Pull Requests - How to properly submit multiple requests


(cpradio) #1

Okay, so I’m not “new” to source control, but I’m definitely green when it comes to git and things just work differently.

For example, Pull Requests are still a black box for me, and as such, you’ll see I’ve made a bit of a blunder, but I think it will work out “this time”.
https://github.com/discourse/discourse/pull/2715

What I intended to do was submit 2 separate PRs. However, when I pushed my search changes to my master branch, it automatically made those commits part of the previous PR from that branch. :frowning:

From my basic searching, it seems I should have just pushed a new branch to my forked repo, and then created a PR from that branch to the discourse/master.

Is that correct? I apologize for the “confusion” this may have caused. Chalk it up to a learning experience and I’ll definitely perform these differently moving forward.


(Sam Saffron) #2

The trick is create a branch per pull request.

git checkout -b my_awesome_feature

Then submit it via the branch :slight_smile: that way you can have multiple PRs going at once


(Dave McClure) #3

The CONTRIBUTING.md step by step has some more details in case that comes in handy.


(cpradio) #4

Yeah, I’ve read that. But being green to git, it didn’t really tell me what it was doing, so I figured the steps I was doing were still “okay”. However, I never see this option in GitHub: Click “Update Commit Range”. I haven’t a clue what that is supposed to be referring to :confused:


(Kane York) #5

Here’s my general workflow:

  • checkout master, pull origin master, update.sh (bundle install, then bundle exec rake db:migrate for both RAILS_ENV={development,test})
  • Starting a new branch/PR:
    • write some code
    • git checkout -b branch-name
    • git add -p
    • git diff --cached # review the diffs, edit & fix as necessary
    • git commit
    • git push riking branch-name
    • go to github, compare, review diffs again, submit PR

Creating the branch and writing the code are interchangable, as long as the branch is created before I make the commit.

If you mess up the master branch, such that git pull origin master --ff-only (fast-forward only) fails, then you do a git reset --hard origin/master && git pull origin master.


(cpradio) #6

New question, as I just ran into this.

I have two enhancements going on right now. The setting of focus for the hamburger and profile menus and new keyboard bindings for Dismiss New, Dismiss Posts and Dismiss Topics.

The changes both involve keyboard_shortcuts.js
Should I wait for one to get approved and merged before submitting the second as a PR? Otherwise, they would handle the changes to keyboard_shortcuts.js differently right? As the first PR would lack the changes of the second PR and the second PR lacks the changes of the first PR (or am I over thinking this?)

So it seems this just works. I occasionally have to rebase, but usually the PRs just flow right through :smile: