Il pattern fork-and-PR

La maggior parte delle piattaforme si aspetta questo flusso: fork del repo upstream, clonare il proprio fork, branch per il cambiamento, push, aprire una pull request.

Setup

git clone [email protected]:you/project.git
cd project
git remote add upstream https://github.com/org/project.git
git fetch upstream
git checkout -b fix/typo upstream/main

Restare aggiornati

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin fix/typo

Costruire i commit

git commit -s -m "fix(parser): handle empty input

Reject empty buffer with InvalidInput rather than panicking. Adds a
regression test in tests/parser/empty.rs.

Closes #1234"

Progetti su mailing list

Per progetti come Linux, usare git format-patch e git send-email.

Recensire feedback

git commit --fixup=<sha>
git rebase -i --autosquash upstream/main
git push --force-with-lease

Sign-off e trailer

git config --global format.signOff true
git commit --amend --no-edit --trailer 'Reviewed-by: Alice <a@x>'
git interpret-trailers --in-place --trailer 'Cc: maintainers@list' COMMIT_MSG

Errori comuni

Branch dal main del proprio fork quando e mesi indietro; sincronizzare sempre da upstream prima.