我目前正在和不同的开发人员一起做不同语言的开发项目（TS，TSX）。此外，我们使用Prettier/ESLint，但这是一个细节。
有些开发者习惯用2缩进来开发，并使用空格。而有些则使用4缩进，并更喜欢使用制表符。
问题是，当我们从github获取代码时，缩进可能是另一个开发者的缩进，而不是对应于我们的缩进。当一个开发者检索缩进为2的代码时，使用缩进为4的缩进，整个文件被检测为被git修改。
是否可以在克隆/拉/取的时候执行代码的格式化以匹配我们的偏好？在创建拉请求/推/提交的时候，格式化代码以使其与仓库中的代码相对应？
我们尝试了几种方法来解决这个问题，但都没有成功：
- 我们尝试使用清洁和涂抹，但从来没有工作：
Can git automatically switch between spaces and tabs?
- 我们试过github的动作，问题是要找到一个具体的修改，根本不实用。
2条答案
按热度按时间gcxthw6b1#
推送和获取并不是格式化代码的关键点，因为Git只是推送或获取已经存在的数据。除了删除和压缩数据外，它不会以任何方式改变发送的数据。
然而，大多数组织这样做的方式是建立一套代码标准和一个lint工具来执行它们。例如，在Rust中，你可能会使用4个空格和
rustfmt来格式化代码。然后，你设置你的CI来运行lint或样式检查，如果不正确就失败。因此，如果代码不符合代码样式，就不能合并。虽然我们欢迎每个人对如何格式化代码有自己的偏好，但当你们在一个项目中一起工作时，要求每个人都同意一套标准是完全正常和合理的。不是每个人都必须喜欢它：Go语言团队明确同意标准的Go语言风格不是每个人的最爱，但它是一个固定的标准，每个人都遵守它。我自己也严格执行了代码风格的更改，这些更改与我喜欢的风格不同，只是因为每个人都使用相同的风格更重要。
如果你有一个自动格式化代码的工具，这会变得更容易，因为每个人都可以运行这个工具，它可以被自动检查，而不需要在代码审查中考虑它。它要么通过CI，要么没有。
请注意，如果你愿意，你可以提供预提交钩子，但你不应该要求它们，因为它对于用户在高级工作流中创建格式不正确的临时提交非常有用。由于Git FAQ提到开发者机器上的钩子不是一个有效的控制，所以无论如何你都需要设置CI。
eagi6jfj2#
您可能会发现this article很有帮助;作者展示了如何通过本地预提交工作流（或钩子）以及PR操作使用clang-format来实施代码样式。
作为最低限度，
.editorconfig文件是一个好主意，只要团队成员在进行更改后明智地运行一个简单的自动格式，缩进样式和空格就不会成为问题。对我来说，运行自动格式快捷方式很快就像CTRL+S一样成为习惯。