Pull Requests are used to review code that will be merged from your development branch to the main branch of the repo.
Start your title with a 3rd-person singular verb (eg,
Fixes) and end with the Ticket ID for which the changes are for.
Adds Save Feature to UserUpdateForm [MYTICKET-12]
If you have additional changes to add to the branch, place [WIP] in front of the name to prevent your branch from being merged until you're finished...
[WIP] Fixes Save Feature to UserUpdateForm
You may use this template for writing a PR Description
## Changes <!-- Keep Changes short and clear yet complete, avoid leaving out small changes --> * Adds Save Button to UserUpdateForm * Submits PUT request to save the form fields to Database * Displays Popup with Response Message ## Screenshots\Gifs <!-- Upload Screenshots or Gifs here if changes have a visible effect, avoid uploading images of codes here. --> ## References <!-- URL related to the Pull Request, such as Jira Ticket --> * https://myproject.atlassian.net/browse/MyProject-99
Please keep the size of your pull request manageable. Remember that people who review your code are also busy with their own tasks. We recommended a maximum of
800 additions and / or 800 deletions.
There will always be certain instances when this isn't enough. For unavoidable BIG pull requests, we would recommend this pattern:
awesome-feature O --- \ ----- O awesome-feature-frontend \ ----- O awesome-feature-backend \ ----- O awesome-feature-misc
Breakdown your main branch (awesome-feature) into mini children branches (awesome-feature-frontend, backend, misc). These children branches are for REVIEWERS only and will not be merged back to the main branch. This way, the people reviewing your code will see smaller glimpses of your BIG pull request.
Here is a sample list of commands to break down your awesome-feature:
$ git checkout awesome-feature $ git checkout -b awesome-feature-backend $ git reset --soft <first commit of your pull request> $ git add <all backend files> $ git commit -m "backend fixes"
Also note that all fixes requested in the children branches will be done in the main branch, then cherry-picked to the affected child branch.
We recommend this as a last resort, given the amount of work that you'll be doing. Remember that your pull request is your responsibility. Making the reviewers understand and accept it is part of it.