【发布时间】：2021-11-03 17:23:39
【问题描述】：
我们是一家软件公司，我们将致力于客户（CompanyA）的现有软件产品。 他们为我们提供了访问他们现有存储库的权限。 我们将专门从事该项目。 但是，该客户过去曾从我们团队中聘请了一些高级人员，这对我们产生了重大影响。 因此，我们不希望他们知道从事他们产品工作的人员的姓名/电子邮件，因为他们肯定会尝试雇用他们。
我们计划在内部复制 repo。 我们的员工通常会使用他们的姓名/电子邮件提交内部回购协议。 我们计划定期与 CompanyA 的存储库同步。
我们希望用更通用的“开发团队”和 Developers@ourCompany.com 替换我们在 CompanyA 存储库中提交的所有作者。
这是我们的想法：
- 最初在我们的内部 Github 上推送/复制 CompanyA 的现有存储库。
- 创建 master_OurCompany，它将基于他们当前的 master 分支。我们的开发人员会将其用作他们的主存储库。
- 我们计划每小时创建（然后销毁）一个基于 master_OurCompany 的名为 master_OurCompany_rebased 的分支。
- 在 master_OurCompany_rebased 上，我们计划使用
git filter-branch --commit-filter命令将该分支中的作者替换为我们想要的信息。 - 然后将 master_OurCompany_rebased 与 CompanyA 的 master 分支合并。
但是，我们发现git filter-branch --commit-filter 使用起来很危险，并且有a plethora of pitfalls。我们不希望任何不幸的事情发生，我们无法从中恢复过来。
有什么更安全的方法可以满足我们的上述要求？
【问题讨论】：
-
我认为围绕两个内部存储库
git format-patch和git am构建的解决方案可能是更好的选择，但这似乎是您在尝试使用技术工具解决社会问题，并且我怀疑任何程序化解决方案都不能真正解决正确的问题。 -
如果他们不尊重您的条款，那就不要与他们合作。