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
