IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2025-02-25 18:55:37 -06:00
Code Issues Packages Projects Releases Wiki Activity

Docs: Update merge a pull request guideline (#43273)

Browse Source 
Co-authored-by: achatterjee-grafana <70489351+achatterjee-grafana@users.noreply.github.com>
This commit is contained in:
Marcus Efraimsson 2021-12-20 10:37:16 +01:00 committed by GitHub
parent 30d00b9b86
commit 85f134969e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
contribute/merge-pull-request.md
View File

@ -21,9 +21,13 @@ The following checklist/summary should give you a quick overview of what to ask/
Before actually merging a pull request there's a couple of things to take into consideration.
### Status checks
Before you can merge a pull request, it must have a review approval, and all the required status checks must pass.
### Format the pull request title
Make sure that the pull request title is properly formatted according to `<Area>: <Summary>` and try to make the summary short and understandable for the community as a whole.
The pull request title should be formatted according to `<Area>: <Summary>`. Keep the summary short and understandable for the community as a whole.
All commits in a pull request are squashed when merged and the pull request title will be the default subject line of the squashed commit message. It's also used for [changelog/release notes](#include-in-changelog-and-release-notes).
@ -31,9 +35,9 @@ See [formatting guidelines](create-pull-request.md#formatting-guidelines) for mo
### Assign a milestone
It's recommended to add a milestone to every pull request. This makes it easier to track what changes did go into a certain release. Without this you're basically left with going through git commits which could be a lot harder.
A milestone **should** be added to every pull request. Several things in the Grafana release process requires at least pull requests to be in a milestone, for example [generating changelog/release notes](#include-in-changelog-and-release-notes).
There's also various tooling built that in some cases requires a pull request to be assigned a milestone, for example [generating changelog/release notes](#include-in-changelog-and-release-notes).
This makes it easier to track what changes go into a certain release. Without this information, release managers have to go through git commits which is not an efficient process.
### Include in changelog and release notes?