如何在一个多分支的项目中，避免因代码格式化导致的 git 冲突？

加钩子 强制格式化

没懂，代码格式化为什么会导致代码冲突？别人也改了这行？

加一些 format check 到 pre commit hook 中？

idea 可以在提交之前 reformat code, 保持大家的设置一致即可

@luckyrayyy
如果别人的代码没有格式化，插件就会修改那些行。虽然内容没有变，但是空格、换行之类的仍然会导致冲突。

统一格式化方式 强制格式化

lz 的这个问题的根本原因在于，代码作者提交的新代码没有经过格式化，这新代码合并到主干分支后，如果别人再格式化的话容易导致合并冲突

解决办法就是从根本上禁止提交没有经过格式化的代码，这样就能保证所有人提交的新代码都格式化过

首先强制每个人使用统一个代码格式化风格，然后在每次提 pull request 或 pr 有新提交的候用 GitHub action 强制校验代码风格，如果校验失败（比如 pr 提交的代码没有没格式化或不符合风格）的话，直接禁止 pr 合并，只有代码风格检验通过才行

@luckyrayyy 格式化经常性动的不止是一行，可能整个文件都动了，大括号的位置，空行的调整之类的。整个文件都改了的话，这提交上去非常大几率会合并冲突。

楼上已经说得很好，可以用 pre commit hook 来做格式化的琐碎事情，或者 jetbrains 系的 ide 都可以设置在 commit 之前做 code cleanup

建议专门找个时间按照统一标准把整个 repo 都按照统一的标准格式化了，以绝后患

首先团队内要统一格式化的配置文件,然后 git hook 强制格式化检测

ci, fmt

提交之前统一格式化代码

@Kamitora 也有脚本可以只 format 当前 commit 修改过的代码，不 format 其他已有代码

从刚开始就统一用 flake8 检查

代码格式化应该就是编程规范

这个首先应当从流程上杜绝，不允许未格式化的代码提交。其次需要统一团队所有人的格式化工具和方法

加 linter, 不格式化不准合并

前端项目有很成熟的工具链完成这个保障：
husky + lint-staged + eslint + prettier

husky 负责 git hook
lint-staged 负责使用指定 linter 对有变更的文件进行检查
eslint 负责代码检查
prettier 负责代码风格管理

启用后基本可以杜绝格式化导致的冲突。

linter + git hook 呀, 不符合规范不让提交

建议做个宏，把 ctrl+s 变成格式化+保存

从管理上解决问题，技术是第二个要做的。我合作的时候也遇到过和别人格式不同，拉下来一个快捷键格式化就全变了

我用的 prettier 提供的一套方案，还挺好，再也没有每次提交一堆没用的格式化 diff 信息。

我提一点：有时候冲突是避免不了的（格式以外的），你也可以从解冲突工具入手，比如 beyond compare，jetbrains IDE 基本都有自动解冲突功能，省时省力。

风格和格式的统一是项目开发的基础，就像要准备好 .gitignore 一样。不同的语言会有对应的格式配置文件，在项目初始化的时候就要带进去。

checkstyle 了解一下？可以做格式化以及代码检查

@luckyrayyy 我实习的时候就这么干过，我用 idea 习惯性的使用格式化代码的快捷键，一个类的代码就会被格式化，缩进的变动也会有记录。然后结果就是提交的时候一个类全是修改，被主管一通骂，自那以后再也不敢直接全局格式化，都是选中自己写的代码块之后再格式化。

@zjq07 项目团队应该共用统一的配置，这样代码格式才能一致。
反过来，修改 code style，最好也是团队投票的结果。
先确定下来 code style，然后完成对应的 lint，最后同步给所有人

1.统一团队代码风格, 建议基于 google 风格提供的 idea 配置文件定制(4 空格缩进, 120 行宽)
2.在项目没有开发分支是全局格式化掉
这样以后怎么格式化大家都一样了