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
