Hi, thats an excellent queston! I dislike squash commits for several reasons. First, history gets lost and second it changes authorship of the commit which is really bad as credits for the code should go to the author.
For PLC4X we have no special rule but usually do not squash at all but we merge most of the branches ourselves. In Apache Calcite every PR should be squashed beforehand and then gets only merged without a squash. I think this is a good rule of thumb. If there are specific reasons why a squash is not necessary / bad then one can state that as comment for the reviewer. I personally like to squash my branches from time to time to keep the history clear and without those "nearly finished" commits : ) But if a branch has a good and clean commit history there is no need to throw that away. But generally I at least DISLIKE squash commits for the reasons stated above. Julian Am 11.07.19, 02:33 schrieb "Xiangdong Huang" <[email protected]>: Hi, I also think that squashing all commits into one is not so good for the branch `feature_async_close_tsfile`... Maybe a choice is that let committers squash their commit history to guarantee all the commits are meaningful. Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 RUI, LEI <[email protected]> 于2019年7月10日周三 下午10:53写道： > Hi all, > > > I think it is worthwhile to spend some time discussing and hoping to reach > a consensus on what a good Git workflow should be. > > > Here is the thing. The branch 'feature_async_close_tsfile' that I have > recently been working on with others was merged into the master branch a > few days ago. When I try to examine the Git history of some code, I find > that the squash merge was used and thus all commit history on the branch > 'feature_async_close_tsfile' is squashed into a single commit. > > > I understand that squash merge keeps the master branch history clean and > easy to follow. However, is it too clean for a NOT lightweight feature > branch like 'feature_async_close_tsfile'? > > > Is squash merge a standard practice in any situation? Should we make each > develop branch small enough so that it can be squashed comfortably before > merged to the master branch? > > > If the develop branch is inevitably large, in order to make the code > history as simple as possible but not simpler, would rebase merge be a > better choice, compared with merge and squash merge? > > > Apart from the final merge choice, I think it is as important that an > individual looks closely at his/her Git workflow to keep the commit history > both clean and meaningful. > > > Sincerely, > Lei Rui
