In git merge/rebase how not to loose authors for git blame

Problem:

• all changes from tasks/pbi appear to belong to the PR owner, so git blame shows our release manager owns like 80% on the code.
• impossible to find who changed the code and why

TL;DR: We have a master branch,from which a pbi(feature) branch is created, each single author has their own task branch from the pbi. merge squash into the pbi (PR), and merge the pbi into master (PR).

Our development flow looks like this:

Workflow

PBI Life cycle

1. PBIs are containers of tasks.

2. Create a PBI with relevant description and acceptance conditions.

3. When actual work is started for a PBI, create a branch with master as target branch, and naming convention features/123-my-feature-name.

4. While work is in progress, it is the owner's responsibility to merge the PBI's branch with master.
5. When all tasks of a PBI are completed (see task workflow below), create a pull request (merge) to master, assign for code / product review and QA, and move to the Resolved state.
6. Post-resolution changes:
   1. Create a new task inside the PBI that facilitates the required fixes / changes.
7. After review and QA, approve the pull request and merge to master. This will close the PBI and move it to the Done state.

Task Life cycle

1. Tasks are the smallest work items, to be executed by a single developer.
2. Create a task with relevant description and acceptance conditions.
3. Tasks start their life in the To Do state.
4. When starting to work on a task:
   1. Create a branch with the parent PBI's branch as target branch, and naming convention tasks/123-my-task-name.
5. Commit and push code as frequent as possible. Develop a discussion on the task's work item in Azure DevOps.
6. It is the task's owner's responsibility to rebase the task's branch on top of its parent PBI's branch, whenever it is needed.
7. When work is completed:
   1. Create a pull request back to the PBI's branch, and assign an owner for code review.
8. After code review is completed, the reviewer approves the change, and merges it (rebase-squash) back to the PBI's branch. This will close the task and move it to the Done state.

Completion requirements

1. All component-level tests (e.g. unit tests) must pass
2. Code review must comply

You are squash-merging. A squash-merge commit can only reference a single author. The squash-merge commit is created by GitLab at the time of merging through the GitLab UI. This will use the author information from the current user session, which seems to be the release manager in your process.

To keep the original authors of each line, do not create squash commits. Instead, use a real merge and keep the history of the single commits (each with separate author information).