On Wed, Mar 07, 2018 at 12:42:52PM -0800, Timothee Cour via Digitalmars-d wrote:
> There are lots of articles on this topic, eg:
> https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
> (note that squashing down to 1 commit shouldn't be necessary but at
> least rebasing should be done)
> github UI also allows to rebase (instead of merge)
> would really simplify things like visualization / understanding
> history, git bisect. It shouldn't matter at what commit was a feature
> started, only thing that matter should be when it was incorporated
> into master.

On the contrary, I find using merge is easier to understand, because it
shows clearly individual commits within a single PR, and also a linear
series of merged PRs if you traverse down master.  In fact, in my own
projects I sometimes purposely use `git merge --no-ff` to force a merge
commit, because it shows distinct lines of development more clearly.

But I suppose this is one of the things reasonable people will disagree


Customer support: the art of getting your clients to pay for your own 

Reply via email to