Add a note about not modifying the git history to the quick guide

[DahlitzFlorian]

Closes: #579

• Add a note to the quick about not modifying the git history
• Explicitly state not using force-pushing at point "7. Review and address comments on your Pull Request"

@aeros What do you think about it?

[aeros]

Thanks for the PR @DahlitzFlorian. I think it has the right general idea, but I would recommend a couple of changes:

[aeros]

With the latest revisions, it looks good to me.

However, I would like to give some time for others to take a look at the PR prior to merging it; especially since it's adding to a part of the devguide that's highly visible. Would you care to take a look @Mariatta and/or @willingc?

[terryjreedy]

The one sentence is an improvement; I suggested another to consider.

The other (usually bad) reason people do force-pushes is to synchronize a branch to master. This is normally not needed and may destroy the PR by introducing 100s of spurious commits. But I don't know if recent changes have properly promoted 'git merge origin/master' as the proper way or not.

[willingc]

@DahlitzFlorian Thanks for the PR. The existing wording in the PR is fine.

Personally, I don't find force pushes to a branch to be an issue when doing a rebase of your branch to the current head of master. I agree that changing commits and squashing make it more difficult to review.

I often use the following on many projects to avoid merge conflicts and continue development:

git push origin pr-branch # origin is my github account and a PR is opened.
# Time goes by then I do the following
git fetch upstream # upstream is cpython repo
git rebase upstream/master
git push origin pr-branch -f 

This method brings all commits of the PR to the HEAD of master. In my personal workflow, I never use merge.

[willingc]

Approving as-is or with my suggested comments. Thanks @DahlitzFlorian.

[aeros]

Great points @terryjreedy and @willingc.

The other (usually bad) reason people do force-pushes is to synchronize a branch to master. This is normally not needed and may destroy the PR by introducing 100s of spurious commits.

I've certainly done this at least once in one of my early PRs before I discovered the approach that Carol mentioned w/ rebasing. I only do that though when the lifespan of a PR is particularly long, otherwise I just deal with the conflicts directly.

[aeros]

Thanks again for working on this @DahlitzFlorian! :-)

[willingc]

Thank you @DahlitzFlorian. I appreciate your help.