在推送时让 git 重新格式化源代码答案

【问题标题】：Having git reformat source on push在推送时让 git 重新格式化源代码
【发布时间】：2013-03-10 23:00:49
【问题描述】：

我正在管理一个开发团队，每个人都使用 Eclipse 和相同的格式设置。

现在一些开发人员有理由切换到其他 IDE，这些 IDE 的源代码格式不同。因此，当他们现在推送到 git origin repo 时，git 注意到了很多外观差异。不幸的是，这对一些开发人员来说是个大问题。

有没有办法让 git - 也许通过使用钩子 - 重新格式化推送或最好提交的所有内容，所以 repo 中的代码总是独立格式化 IDE？

我假设我们不是 git 历史上第一个遇到这个问题的团队，所以我希望有一个预制解决方案或至少一些最佳实践。

【问题讨论】：

【解决方案1】：

可靠地做到这一点的唯一方法是在服务器端（出于安全原因，在克隆期间不会自动设置客户端挂钩，因此如果您按照其中一个 cmets 中的建议在客户端执行此操作，每个开发人员必须手动设置一次该挂钩）。

在那里，理论上你可以操纵收到的更新……但这是一件相当复杂的事情。然而，实际的问题是，一旦完成，您在本地就有自己的、未触及的提交，并且在服务器上有修改过的提交——这是自找麻烦。如果您现在要进行拉取/合并，git 会将未修改的历史记录与修改的历史记录结合起来，突然间您将所有提交都两次。

如果您想确保只有格式正确的代码最终在存储库中，那么如果您拒绝格式不正确的代码，这会容易得多并且导致的问题更少。当然，这在实践中可能会相当烦人，但这是您必须做出的权衡。

假设您可以让您的开发人员进行本地钩子设置，那么本地预提交钩子几乎肯定会更容易编写并且在实践中减少麻烦 - 但它可以通过各种方式绕过，所以有没有铁定的保证。

【讨论】：

这样的项目使用多种语言 - Java、JS 和 HTML + 一些 bash 脚本和奇怪的 txt 和 xml。拒绝并不是一个真正的选择，因为这样每个人都必须手动调整他们的代码。我们有一位非常直言不讳的开发人员，如果事情看起来不像他认为的那样，他根本不会让其他人工作。
这很可悲，但它并没有改变技术上的可行性。要么你使用没有保证的本地钩子，要么你拒绝。或者，每当在服务器端重新格式化某些内容时，您都会产生大量额外的工作（并且可能会出错）——从长远来看，拒绝实际上可能比在服务器端重新格式化更便宜。
附言。一个我知道的项目在提交被拒绝时输出一个用于修复格式的差异。不过，拒绝仍然很烦人。
我同意上述观点。您正在查看“push 置于版本控制之下”（à la CVS、SVN 及其同类产品），git 是 commit 将东西置于版本控制之下。最好确保每个人在格式方面都在同一页面上。其他任何事情都会在以后招来无尽的悲伤。
我们已同意根据每个 IDE 的相同规则为每种类型的项目和格式使用一个 IDE。