Сhange author of commit

4 Easy Steps to Change Author Name of a Commit After Push

Rebase the repository to the previous commit of the one you want to change by running:
```
    git rebase –i {{previous-commit-hash}}
```
The script above prompts you with a list of your commits in descendent order. On this vi/vim view, replace the word pick to edit per each commit you want to edit. Then quit and save.
When the rebase process starts, change the author of a commit by running:
```
git commit --amend --author="Author <email@email.com>"
```
Then, continue to next commit using: git rebase –continue
Once the rebase process finishes, push your changes by running:
```
git push -f origin branch
```

The steps above will change the author of a commit. But what is the meaning of each commands above and what it means to change a git repository’s history?

I came across this question recently after changing the settings on GitHub page and seen that commits were logged with invalid an invalid name. Reading through Git’s documentation made it tricky to find the answer. This Stack Overflow answer nail it but I still decided to write about it to review the concepts behind scenes.

What does the rebase commit do?

The rebase command basically integrates changes from one branch into another. It is an alternative to the “merge” command. The difference between rebase and merge is that rebase rewrites the commit history and creates a linear succession of commits, while merging adds a new commit to the destination branch. The image bellow perfectly shows a visual representation of both processes.

Git amend command

The amend command allows git users to change details of a commit. The amend structure is simple:

git commit –amend

This will prompt a vi/vim view where the details of a git commit can be changed:

update changelog file

It is possible to change the author of a git commit directly as seen before:

git commit --amend --author="Author < email@email.com > "

Change git history… Caution!

Those who are familiar with rebasing know how powerful the tool it is. It might be tempting to use it all the time as well.

When getting conflicts during a rebase, Git pauses on the conflicting commit and allows to fix conflict before proceeding. However, solving conflicts in the middle of a long chain of commits is often confusing and another source of potential errors.

Rebasing creates this linear mind-set and give less priority to the actual goal of git. That is why it is not recommended to change the history of a git repository unless there is no alternative to it.

In my case, I was the only user interacting with the repository so it was safe. However, when multiple developers are working on multiple branches, change to the git history can become a real source of problems.

References

Source