Merge strategy rebase or merge #31

To minimize and simplify discussion of code quality #5, let us discuss merge strategy here

The result slice of code will be the same. The question is only about git history and how to work with it. This is part of history of this project where merge approach is used:

This requires more attention at navigate through - merge commits has more than one parents.

There are at least two commit in history which has different features and does not include both.

Search commit that has an error become more complicated, it may appear and disappear in linear order (for example image above commit 558 appears at af6 and ff0 but not appears between them at b4d). Fortunately git has a tool to simplify search.

By the way GitHub hides this branches from user, in opposite bitbucket shows them.

If we try to take a look to merge commit it is empty in most cases but may contain conflict resolution or some else (what? the question for discuss also). Empty merge commit is correct due to changes actually present in parent branches but little confusing and involve to navigate to other commits in parent branches.

From the other side branches shows how works moves and they represent itself some sort of formatting or division for fragments the works.

This the part of linear history identical rebase approach (taken also from this project):

However top commits a285 and 88a6 may be was made by merge strategy but actually has one parent commit (but actually created by rebase or just empty generic commits), and they are empty. It is possible to create empty generic single parent commit also. But what is the reason and how that commits actually created it is not clean for now. But the topic is not about that coimmis but about merge strategy.

That is the thought I would like to share in addition to what may be found in web.