Skip to content

Guidelines for Creating a Good Pull Request

Martine Lenders edited this page Jun 15, 2018 · 9 revisions

Before you publish

  • Make sure you have followed the code convention and the coding convention for CPP. Use uncrustify to get most of the code compliant to the convention.

  • Try your best to document how the provided code is intended to reach this goal. If the reviewer has difficulties to understand your approach, try to improve the documentation.

  • Split your Pull Request (PR) up into logical pieces. E.g. formatting changes or accompanying tests should go into separate commits. Be aware that each commit title is only allowed to have 72 characters at maximum, but actually try to stay below below 50, as this is Git best practice. A longer commit message may be written in the commit message body. A commit list could look like this.

cpu/common/<CpuName>: changes for <CpuName>
cpu/<CpuName>: initial <CpuName> support
board/boardname: Initial <BoardName> support 
examples/* : blacklisting for <BoardName>
tests/* : blacklisting for <BoardName>

Sidenote: git cheatsheet

// Reset branch commit log to the first commit to your branch
// clean last three commits.
git reset --soft HEAD~3
// Add specific folders for commit
git add cpu/common/<CpuName>
// Commit with message
git commit -m "cpu/common/<CpuName>: changes for <CpuName>"
// Continue building the commit history ...
// Finally force the new history to the remote branch
git push <RemoteName> +<LocalBranchName>:<RemoteBranchName> 
  • Rebase your branch to the latest master

Sidenote: git cheatsheet

// Update your master branch from Riot OS remote
git pull <RemoteName> master
// Rebase Branch to master, branch will be checked out afterwards.
git rebase master <BranchName>
// Finally force the new history to the remote branch
git push <RemoteName> +<LocalBranchName>:<RemoteBranchName> 

Creating the Pull Request (PR)

  • Keep pull requests as small as possible. The smaller a PR, the more likely it gets reviewed in short time.

  • The title and initial description of a PR should describe its basic idea and what goal is intended to be achieved in a brief and comprehensible manner.

Initial support for board <Name>
  • Support your reviewer! Try to react as quick as possible to your reviewer's comments - and if only by letting her/him know, that you have currently no time to incorporate her/his feedback. Also, let the reviewer know if you do not plan to continue to work on a certain PR. Furthermore, if your reviewer don't react for some days, remind him!

Sidenote: git cheatsheet

When changes have to be applied while a PR. Adding a change to a specific commit can be achieved by interractive rebasing.

// Interacive rebase last five commits
git rebase -i HEAD~5
// Follow the instructions displayed. 
// Choose e to edit code or r to just reword the commit message.
// Change the code and amend it to previous commit
git add <Changes>
git commit --amend
git rebase --continue
...
// Finally force the new history to the remote branch
git push <RemoteName> +<LocalBranchName>:<RemoteBranchName> 
Clone this wiki locally
You can’t perform that action at this time.