When I work on two different features (on two different branches created from the master) it is quite annoying that I will not have the commit history when I procee
Use rebase instead of merge. From the tutorial:
If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
I imagine that the changes from your Branch-B cannot be merged using fast-forward merging into the master. In such cases a three-way-merge is done:
Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.
I would always rebase my commits before commiting them into the master to keep the linear history.