在每次提交中更改邮件地址
这个问题在这里已经有了答案：
既然你只有一些提交而不是整个历史，我会用git rebase -i -p和git commit --amend --author "a.jard <a.jard@mail.com>" 。
它涵盖在这个答案中，这不是被接受的答案，而是具有双倍的票数。
至于为什么你得到的结果是你的脚本，这是由于git的性质以及rebase如何工作。 重写不会重写历史，它不能。 在git中提交是不可变的。 提交的ID与提交本身的内容相关，包括日期，日志消息，作者和提交者等元数据。 rebase写新的历史。
拼图的另一个关键是提交的ID使用其父母的ID进行计算。 不改变孩子也不能改变父母。 如果我告诉你我已经犯了ABC123，并且如果你犯了ABC123，我们都知道我们有相同的历史记录，所以这使得git推拉效率非常高。
例如，假设您有一个简单的存储库，其中有五个提交。 主人和出身/主人都指向E.
A - B - C - D - E [master] [origin/master]
B有错误的电子邮件地址。 A，C，D和E都很好。 你运行你的filter-branch命令。 它会看着A，看到没有变化，并保持独立。 它会查看B，更改提交者，然后用A作为父进行新的提交。 我们称之为B1。
A - B - C - D - E [master] [origin/master]
B1
现在它看着C.没有什么可以改变的，但它需要它的父母给B1。 由于该ID包含父母的ID，因此必须进行新的提交。
A - B - C - D - E [master] [origin/master]
B1 - C1
和D和E一样。
A - B - C - D - E [master] [origin/master]
B1 - C1 - D1 - E1
完成后，过滤器分支将[master]移动到E1。
A - B - C - D - E [origin/master]
B1 - C1 - D1 - E1 [master]
这就是为什么在过去改变一次提交会导致它后面的所有事情发生分歧的原因。
由于该脚本的作者并未指示您限制git-filter-branch应该过滤哪些修订，因此它完成了当前分支的整个历史记录。
幸运的是，您可以通过将主设备移回原点/主设备来撤消此操作。 有几种方法可以做到这一点。 git branch -f master origin/master是最简单的。
更新这涵盖了你的新问题，你的开发分支留在过滤的分支上。 让我们从头开始。 你有这样的情况...
A - B - C - D - E [master] [origin/master]
你运行git author-rewrite并结束了这个。
A - B - C - D - E [origin/master]
B1 - C1 - D1 - E1 [master]
你分出主，并开始进行新的提交。
A - B - C - D - E [origin/master]
B1 - C1 - D1 - E1 [master] - F - G - H [devel]
你运行git branch -f master origin/master来撤消你的过滤器。 git中的分支只是指向提交的标签，所以只有主标签被移动。 您的devel分支仍然悬挂已过滤的提交。
A - B - C - D - E [origin/master] [master]
B1 - C1 - D1 - E1 - F - G - H [devel]
现在你需要开发，F，G和H挂掉主人。 业务的第一步是把发展移到主人。 如果我们这样做，将难以再次找到F，G和H. 你可以写下身份证，或者你可以用标签取出一些保险。 git tag tmp devel 。
A - B - C - D - E [origin/master] [master]
B1 - C1 - D1 - E1 - F - G - H [devel] <tmp>
现在移动devel以使用git branch -f devel master 。 tmp标签保持过滤的分支可访问。
A - B - C - D - E [origin/master] [master] [devel]
B1 - C1 - D1 - E1 - F - G - H <tmp>
现在你可以使用git cherry-pick将每个单独的更改复制到开发版。 提交的内容不会改变，但父母是，所以他们必须复制。
git checkout devel
git cherry-pick F^..tmp
为了解释F^..tmp部分，我们希望从H到F的所有内容F..H表示包括H的父母，但排除F的父母，这只是H和G.因为我们想将F该列表中，我们使用F^排除F^的父母。
你结束了这个。
A - B - C - D - E [origin/master] [master] - F1 - G1 - H1 [devel]
B1 - C1 - D1 - E1 - F - G - H <tmp>
一旦检查完成，使用git tag -d tmp删除tmp标签。
A - B - C - D - E [origin/master] [master] - F1 - G1 - H1 [devel]
不要担心，如果你搞砸了，在垃圾收集之前，这些提交仍然会在那里数周。
现在你可以看看devel并使用上面提到的rebase技术来修复你的提交。 你会结束这件事。
A - B - C - D - E [origin/master] [master]
B2 - C2 - D2 - E2 - F2 - G2 - H2 [devel]
用git branch -f master E2手动移动master到git branch -f master E2 。
A - B - C - D - E [origin/master]
B2 - C2 - D2 - E2 [master] - F2 - G2 - H2 [devel]
你仍然会有分歧。 推动你的改变仍然需要被迫，其他人将不得不强制拉。 这部分是无法避免的。 被推动后改变历史总是很混乱。
还有很多其他的方法来完成这一切。 使用git filter-branch的好处之一是它会移动所有标签和分支。 对于像你这样的小改动，对于新用户，我更喜欢小步调整。 理解正在发生的事情更容易。