docs: Clarify when to rebase a non-conflicting PR and how (#5514)

## Issue being fixed or feature implemented
Issues with rebasing non-conflicting pull requests on top of the updated
target branch:
1. It's ~impossible~ _annoying_ to run `gfd` _on each rebase_ to verify
that it was indeed a clean rebase ~if you did not pull the
original/previous version~ (it is possible actually, must use full
commit hash)
2. Github GUI is pretty much useless if a target branch update was huge 

Because of (1) and (2) if a rebase was done in the middle of your review
you have to basically start your review from scratch which is super
annoying and should be avoided. Rebasing a conflicting PR or rebasing on
top of the same `HEAD` as before is ok.

cc @kittywhiskers @vijaydasmp @knst 

## What was done?

## How Has This Been Tested?

## Breaking Changes

## Checklist:
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
This commit is contained in:
UdjinM6 2023-08-01 20:18:35 +03:00 committed by GitHub
parent 63b00440e0
commit bf87bb61cf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -148,6 +148,12 @@ pull request to pull request.
When a pull request conflicts with the target branch, you may be asked to rebase it on top of the current target branch.
The `git rebase` command will take care of rebuilding your commits on top of the new base.
Avoid rebasing a non-conflicting pull request on top of the updated target
branch if you requested a review already. If you need to tweak some commit in
the middle, please rebase your branch on top of the same commit it was
originally based on. Non-conflicting pull requests should be rebased on top of
the current target branch by maintainers only.
This project aims to have a clean git history, where code changes are only made in non-merge commits. This simplifies
auditability because merge commits can be assumed to not contain arbitrary code changes. Merge commits should be signed,
and the resulting git tree hash must be deterministic and reproducible. The script in