user: pull-request: add section on reviews

This commit is contained in:
Earl Warren 2023-11-15 23:27:14 +01:00
parent 927d806dbc
commit 05de9ce86a
No known key found for this signature in database
GPG key ID: 0579CB2928A78A00
4 changed files with 17 additions and 3 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 73 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

View file

@ -4,7 +4,7 @@ license: 'CC-BY-SA-4.0'
origin_url: 'https://codeberg.org/Codeberg/Documentation/src/commit/7bb8fa5ca559073c028805888195ee31b1f3d9c2/content/collaborating/pull-requests-and-git-flow.md' origin_url: 'https://codeberg.org/Codeberg/Documentation/src/commit/7bb8fa5ca559073c028805888195ee31b1f3d9c2/content/collaborating/pull-requests-and-git-flow.md'
--- ---
## Benefits of a pull-request based workflow ## Benefits of a pull request based workflow
> **_TLDR:_** _Keep an eye on your repository and organization permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners have permission to merge them._ > **_TLDR:_** _Keep an eye on your repository and organization permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners have permission to merge them._
@ -13,7 +13,7 @@ Although it is perfectly possible to use a Git project on Codeberg just as singl
- The "hot" project repository requires only very few maintainers with full rights to sign off pull requests. Contributors can easily work on forked repositories. - The "hot" project repository requires only very few maintainers with full rights to sign off pull requests. Contributors can easily work on forked repositories.
- Each pull request collects the full edit history for a fix or feature branch. Contributors can squash this, or keep it, just as they prefer. - Each pull request collects the full edit history for a fix or feature branch. Contributors can squash this, or keep it, just as they prefer.
## Create a pull-request ## Create a pull request
Let's say, you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/knut/examples). Let's say, you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/knut/examples).
@ -53,6 +53,20 @@ This button is automatically shown if:
- The push must occurred within the last 6 hours - The push must occurred within the last 6 hours
- There is no open PR for this branch - There is no open PR for this branch
## Reviews
On the pull request page, the `Files Changed` tab shows a `Review` button that can be used to approve the pull request or request changes.
![Review a pull request](../_images/user/pull-request/pull-request-review-global.png)
Next to each changed line, a `plus` button allows to add a comment on that specific line, for instance to suggest a modification.
![Review comment on a line](../_images/user/pull-request/pull-request-review-line.png)
When a pull request contains multiple commits, the button to the left of the `Review` button can be used to only review a single commit.
![Review a single commit](../_images/user/pull-request/pull-request-review-commit.png)
## Keep it up-to-date: rebase pull requests to upstream ## Keep it up-to-date: rebase pull requests to upstream
Sometimes the upstream project repository is evolving while we are working on a feature branch, and we need to rebase and resolve merge conflicts for upstream changes into our feature branch. This is not hard: Sometimes the upstream project repository is evolving while we are working on a feature branch, and we need to rebase and resolve merge conflicts for upstream changes into our feature branch. This is not hard:
@ -79,7 +93,7 @@ That's it. You can now push your changes, and create the pull request as usual b
Please keep in mind that project owners can do _everything_, including editing and rewriting the history using `force-push`. In some cases, this is a useful feature Please keep in mind that project owners can do _everything_, including editing and rewriting the history using `force-push`. In some cases, this is a useful feature
(for example to undo accidental commits or clean up PRs), (for example to undo accidental commits or clean up PRs),
but in most cases a transparent history based on a pull-request based workflow is surely preferable, but in most cases a transparent history based on a pull request based workflow is surely preferable,
especially for the default branches of your project where other people rely on intact history. especially for the default branches of your project where other people rely on intact history.
**Warning** If you accidentally leaked sensitive data, say, leaked credentials, **Warning** If you accidentally leaked sensitive data, say, leaked credentials,