2

I'm quite new to GitHub and I'm not sure how I should behave about the number of pull requests I send to a certain project. Is there such a thing as too many or too frequent pull requests? Are there general guidelines to follow?

Amal K
  • 4,359
  • 2
  • 22
  • 44
AnotherUser
  • 29
  • 1
  • 4
  • 1
    If they have that many issues, send a pull request for each. Dont send pull requests that have lots of changes together, and make sure you send clean pull requests. – exussum Jun 02 '14 at 16:07
  • Thanks. How do I go about pull requests to implement additional features? – AnotherUser Jun 02 '14 at 16:08
  • usually they have a separate section for that - an RFC section. If they dont i would open an issue before working on it. If its gone down well / had no reply send it. Saves you spending time making features that are not wanted – exussum Jun 02 '14 at 16:10

2 Answers2

1

The naming convention for a pull request is your own to make.

The idea is to make a small coherent change that can easily be merged back and tested.

By "coherent", I mean "which introduces only one change or new feature".

It is best to isolate that change in its own branch, that you will push to your fork, and from which you open a new PR: see "couple of tips for PR".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

You usually should have one pull request per issue. You should also squash your pull requests to a single commit. Your commit message should be very specific.

Anubian Noob
  • 13,426
  • 6
  • 53
  • 75
  • Squashing is subjective. If team needs every single commit to be retained they can go for merge, if they need the timeline to be clean and doesn't worry about every single commit then they can go for Sqash merge. – Chandraprakash Jul 08 '22 at 10:08