I am trying to change committer name using:
https://stackoverflow.com/a/3042512/6097074.
I have commit to branch A taking pull from 'B' and after pull I got conflict to resolve but I wrongly commit from the other user.
Now I am trying to rebase it, but it is not showing that commit(merge commit after conflict resolve) in editor to change PICK to EDIT.
Below is my gitk image I want to change commit in Yellow highlight.
(Note: if you have access to Git 2.18, you can try the fancy new rebase. See VonC's answer here. I do not know if it will work for this particular case.)
Rebasing removes merges, as the usual point of rebasing is to eliminate the need for merges.
There is a form of git rebase that re-creates merges (it just runs git merge again), but it's not the right way to do this for your case. For your case, the right way to do this is for you to run git merge again—or perhaps for you not to do it at all.
Remember, git pull just means run git fetch, then run git merge. (Or, if you tell it to run git rebase as its second Git command, run git fetch, then run git rebase.) If you are a beginner to Git, I personally recommend avoiding git pull. Run the two separate commands instead. The results will make more sense.
You can use git reset to move your current branch name back to the point where the git merge has not yet occurred. This will have the rather unfortunate, but crucial, side effect of tossing out all the subsequent commits as well, and of wiping out uncommitted work if you use git reset --hard. That's a sign to help you realize that what you are doing is quite drastic. Before you start, you will want to set up a name—a branch or tag name—to remember all the original commits, so that after git reset --hard, which drops all those commits from the current branch, you can still get to the original commits (which are now only on the new branch or tag name you just set up).
Having removed the merge, you can now run git merge again to re-perform the merge. This time you can use a different committer name, if you wish. Note that you get a different commit, with a different hash ID.
Having re-performed the merge, correctly this time, you can now copy all the subsequent commits. You can do this one commit at a time, using git cherry-pick and their commit hash IDs. Each copied commit gets a new committer name and time-stamp. (Note that git cherry-pick re-uses the original author and author time-stamp by default, but you become the new committer.) These new commits get new, different hash IDs from the originals. This is necessary! They sit atop the new and different merge commit, and hence they are different commits and need different IDs.
To copy all those commits faster, you can use git rebase! This is in fact what git rebase does: it copies commits, so that the new ones come after wherever you are standing when you start the rebase. (This is why it eliminates the need for merges.) But for educational purposes, it makes more sense for you to use git cherry-pick. That makes it clear how git rebase achieves its result.
Now that you have copied all the original commits to new, improved commits with different hash IDs, you can git push the new commits elsewhere. However, anyone who already has the original commits is now forced to switch from the old (wrong) commits to the new (corrected) commits. This is precisely why—and when—this kind of "rewriting history" is bad: when it makes more work for other people, who are now all annoyed with you for making them do all this work. If you have never pushed those commits, no one else has them, so no one else gets annoyed; or, if you have made arrangements with everyone else in advance, no one else is allowed to get annoyed.
So in these two situations—originals never handed out, or you do a "history-rewrite" using git push --force but all parties have already agreed to deal with such pushes—this kind of rewrite is OK. In other situations, you can still do this, but you may have to hope for forgiveness.
