One thing shall be clearly noted to understand most of rebase problems:
A rebase is hidden merge.
The first direct consequence is that a rebase result shall be tested (with assigned tests) and verified (at least visually).
The second one is that conflicts found in rebase are principally the same found in merge. But, as far as people usually think easier in a sequential history, rebase result is simpler to read later on. More so, git automatically shows single-parent commits as diffs but doesn't do this for merge commits - they require separate cumbersome actions to find their changes out.
And, well, rebasing of published changes is, at least, a tricky action. Some sources afford this constantly (Linux kernel development trees). There is a section "Recover from upstream rebase" in Git manuals. Anyway, this is the true aerobatics:)
One thing shall be clearly noted to understand most of rebase problems:
A rebase is hidden merge.
The first direct consequence is that a rebase result shall be tested (with assigned tests) and verified (at least visually).
The second one is that conflicts found in rebase are principally the same found in merge. But, as far as people usually think easier in a sequential history, rebase result is simpler to read later on. More so, git automatically shows single-parent commits as diffs but doesn't do this for merge commits - they require separate cumbersome actions to find their changes out.
And, well, rebasing of published changes is, at least, a tricky action. Some sources afford this constantly (Linux kernel development trees). There is a section "Recover from upstream rebase" in Git manuals. Anyway, this is the true aerobatics:)
Well said! Thank you. I learned a lot from your comment