Par Anonyme (non vérifié) , 29 avril 2026

Le pattern fork-and-PR

La plupart des plateformes attendent ce flux : forker le repo upstream, cloner votre fork, brancher pour le changement, push, ouvrir une pull request. Git le traite comme un workflow triangulaire avec deux remotes.

Configuration

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

Rester à jour

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

Concevoir des commits

git commit -s -m "fix(parser): gérer entrée vide

Rejeter buffer vide avec InvalidInput au lieu de panic. Ajoute
test de régression dans tests/parser/empty.rs.

Closes #1234"

Projets mailing-list

Pour des projets comme Linux, utilisez git format-patch et git send-email.

Revoir le feedback

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

Sign-off et trailers

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

Erreurs courantes

Brancher depuis le main de votre fork quand il a des mois de retard. Force-push sans --force-with-lease.