Michigan, USA
Ravi is a software engineer in the UAV industry. He has worked on a variety of problems such as UAV sensor software integration, DevOps, digital signal processing and applying machine learning to problems. He's always on the lookout for new and interesting software tools for his work and hobbies. Some of his favorites topic areas include Python, C#, Unity and containers. He likes writing and sharing nuggets of what he has learned along the way with the open source community.
Authored Comments
Thanks for bringing up some important points for discussion!
The workflow discussed in this article, particularly about rebasing and squashing, apply to the use case where each developer works on a separate feature branch and has force push permission for the feature branch. In your Git usage where there are multiple contributors to one feature branch, I agree that this combination of squashing and rebasing won't apply.
I agree that commits associated with refactoring of existing code or other significant code changes to facilitate the new feature shouldn't normally be squashed together with, say, commits associated with new files added for the feature.
Typically, each feature branch will result in a handful of commits after squashing. A few will be due to the things you mentioned (e.g. refactoring existing code). And one or two commits will be the result of squashing together commits related to new files associated with the new feature.
I'm not sure about your comment regarding the pull request being a single commit. The pull request can be submitted for the handful of commits in the feature branch. The approver can then perform a merge commit that will include the multiple pull request commits, plus the additional commit that represents the merging of the pull request from the feature branch.
I agree with your concern that we shouldn't generalize too much, etc. Indeed, explaining the purpose of specific techniques should be part of onboarding new team members with the understanding that it might take some experience before the concepts sink in. (For instance, I think one has to struggle a bit with some Git logs during bug fixing to really appreciate the value of having a good, well-ordered Git commit history.) I guess I was just thinking about "best practices" in this case as a good workflow for this common use case with Git. This workflow certainly won't apply to every Git-based project.
Yes, that's a great idea! Thanks.