I tend to keep my PRs small enough to where several can be submitted within a day. This being said, I tend to keep my changes un-staged.
When I'm ready to commit:
1. `git diff` to get an overall picture of what changes were made. Which parts of this diff can be packaged into an isolated commit?
2. `git add -p` This is where I selectively stage bits.
3. `git diff --cached` to verify that the staged items are all in place
4. `git commit` with a detailed message.
5. Repeat steps 1-4 until all changes have been committed.
6. `git fetch origin main && git rebase origin/main`
7. Finally, `git push`
When PR feedback is left by peers, some teammates prefer you to not rewrite commits and force push. This makes re-review easier for them (especially if you use the Github features around PR review).
I opt for rewriting commits if it's okay with team members. This way you don't have "fix typo" commits getting merged into the main branch.
`[commit] verbose = true` in .gitconfig makes `git diff --cached` step unnecessary, as you then get the diff displayed in commit message editor (I'm baffled why this isn't the default)
When I'm ready to commit:
1. `git diff` to get an overall picture of what changes were made. Which parts of this diff can be packaged into an isolated commit?
2. `git add -p` This is where I selectively stage bits.
3. `git diff --cached` to verify that the staged items are all in place
4. `git commit` with a detailed message.
5. Repeat steps 1-4 until all changes have been committed.
6. `git fetch origin main && git rebase origin/main`
7. Finally, `git push`
When PR feedback is left by peers, some teammates prefer you to not rewrite commits and force push. This makes re-review easier for them (especially if you use the Github features around PR review).
I opt for rewriting commits if it's okay with team members. This way you don't have "fix typo" commits getting merged into the main branch.
Edit: formatting