In a sense, Git (and forges like GitLab, GitHub, and Codeberg) are communication tools.
When you author a commit, merge request, or pull request, you are taking responsibility not only for updating codebase, but for updating the mental models of people you collaborate with.
Use the branch history and merge/pull request to teach your collaborator about the change.
Changes are committed to two places!
Put yourself in the shoes of your collaborator and think carefully about how to help them absorb the new information.
- Commits should be grouped into logical batches - AKA atomic commits.
- The commit history for a branch should tell a natural story of how the changes evolved. It is worth rewriting your commit history in order to achieve this. Retcon and other GUIs can help.
- Merge requests or pull requests should be as small and simple as possible.
- It is better to have many tiny, stacked merge/pull requests than to have one large one.
- Learn to stage specific hunks rather than entire files when necessary. Git GUIs are great for this too.