Git commits history conventions in PR #1365
Replies: 2 comments 10 replies
-
I will write here my opinion again: From git best practices, one should commit often and regularly to be able to maintain his code better. One thing that squashed commits will help in is during the CR process to have better understanding of the code written and the connections between files and packages, but I think that using good division to packages and files it will be clear as well. A suggestion was to create a local branch with all the commits and squash them to the remote branch. This way you can preserve your commit messages but pushing a clean history. So the solutions in my opinion are the following:
Tell me what you think :) |
Beta Was this translation helpful? Give feedback.
-
If the commits are crafted well and according to the concept I mentioned before, it can be much easier to review by commits (especially in big PRs) |
Beta Was this translation helpful? Give feedback.
-
I want to create a consensus about the conventions of how should the commit log history look like when opening a PR in the project.
We have a consensus that all PR commits should be squashed to 1-3 commits (according to PR size) before merging the commit to main.
However, during the CR cycle it is a different issue.
There are two major options:
I am opening this discussion to continue the discussion from #1103
Beta Was this translation helpful? Give feedback.
All reactions