我最近将我们的代码库更新为 ES6。在此之后，我正在改进 linter 规则，并努力在代码库中建立一套标准。我的计划是提交一个初始分支，其中只有 eslint 和更漂亮的设置。然后直接使用 eslint --fix 提交另一个分支并在其上运行更漂亮。（我们没关系，这最终会搞砸很多 git blame）。此过渡的主要变化之一是从 4 个空格（以及许多地方的制表符）移动到 2 个空格项目宽度。
计划是任何现有的分支都将能够提取其中包含更漂亮工具的提交。他们可以在他们正在进行的功能上运行 prettier/eslint，然后应该能够合并。
我遇到的问题是，在测试运行中执行此操作后，功能分支中存在的每一个更改都会作为合并冲突出现。大多数时候，合并冲突根本没有任何意义。
此问题仅影响存在且当前正在处理的分支，不会影响提交 linting 后将创建的任何分支。
我尝试过使用不同的算法进行差异/合并。差异看起来不错，但随后合并仍然会出现冲突。
有没有人有将他们现有的项目转换为像这样的新缩进或做任何更漂亮/eslint --fix 的经验？
处理这种情况的技巧是使用合并工具，在合并之前将格式修复应用于文件，例如：
https://github.com/emilio/clang-format-merge
使用这种方法，人们可以将旧分支变基并合并到最新格式化更新的主分支上，并且不会发生仅由格式化引起的冲突。
以下是我的团队成员在升级 Prettier、更改其配置、首次添加等之后所做的事情，以防止在他们的分支上出现合并冲突问题：
git fetch origin master:master
# rebase against stage, choosing your code in case of a conflict, and then running the new prettier after each commit
git rebase -i master -X theirs \
--exec 'yarn && $(npm bin)/prettier --write $(git diff --name-only head^ | xargs) && git commit -a --amend --no-edit'
lint-staged我认为，您可以采用类似的方法。
我在寻找同一个问题的答案时遇到了这个问题。我想分享我计划的方法：
与团队一起将所有分支同时聚合回可以合并的master。一旦所有分支都合并（或接受修剪），执行 linting。每个人都拉出 linted 版本，并且能够再次分歧到他们自己的分支中。
我希望有一种方法可以用 Git 记录内联增量，但在那之前我们必须有点创意。