Workflows and best practices for pull requests?

[Mojca Miklavec]

Dear Kevin,

On Wed, 14 Jul 2021 at 05:05, Kevin Horton wrote:
>
> I'm new to working with a team of committers, and I'm a very basic git user, so I'm struggling to figure out workflows and best practices when making a pull request and reviewing comments on a pull request.
>
> Questions:
> 1. One of the checkboxes when making a pull request is "squashed and minimized your commits".  I tend to make many small commits when working on my personal projects.  What is the best way to squash those commits before making the pull request?  Google seems to suggest an interactive rebase is the way to go.  Comments?

The idea of "squashing and minimizing" applies to the case when someone:
- makes a change
- finds an issue
- commits a fix
- finds another issue
- commits another fix
- etc.

Basically we want to prevent a long list of bugfixing.

It's generally still preferable to use atomic commits for unrelated
changes, it's just desirable to squash "bug fixes for previous faulty
commits".

> 2. I'm completely baffled by the GitHub interface for dealing with comments on a pull request.  Assuming I have made and testing the changes suggested by reviewers, what is my next action?  Make a new pull request?  Is there a way to modify the existing pull request?

No, the best way to handle suggestions is to push changes to the same
branch, which will update the existing pull request.
If you made some mistakes (that others warned you about), the idea is
to amend the commit and force push to that same branch.

Opening a new pull request is counter-productive as you then lose
older discussions.

Mojca