我最近将我们的代码库更新为ES6。在此之后，我正在改进linter规则，并努力在代码库中设置一个标准。我的计划是提交一个初始分支，其中只有eslint和更漂亮的设置。然后直接跟随提交另一个分支与eslint --fix和更漂亮的运行。 （我们没关系，这最终会搞砸很多git责备）。这种转变的一个主要变化是从4个空间（和许多地方的标签）转移到2个项目范围的空间。
计划是任何现有的分支都能够提取其中包含更漂亮工具的提交。他们可以在进行中的功能上运行更漂亮的/ eslint然后应该能够合并。
我遇到的问题是，在测试运行中执行此操作后，功能分支中存在的每个更改都会出现合并冲突。大多数情况下，合并冲突根本就没有。
此问题仅影响存在且当前正在处理的分支，它不会影响在提交linting之后创建的任何分支。
我尝试使用不同的算法进行差异/合并。差异看起来不错，但合并后仍然会出现冲突。
有没有人有将这些现有项目转换为这样的新缩进或做任何更漂亮的/ eslint的经验 -
答案 0 :(得分：0)
我在寻找同一问题的答案时遇到了这个问题。我想分享我的计划方法：
与团队合作，将所有分支同时汇聚回可以合并的主人。一旦所有分支合并（或接受修剪），执行linting。每个人都拉出了linted版本，并且能够再次分叉到他们自己的分支。
我喜欢有一种方法可以记录Git的在线增量，但在那之前我们必须要有点创意。
答案 1 :(得分：0)
处理这种情况的技巧是使用合并工具，在合并之前将格式修复应用到文件，例如：
https://github.com/emilio/clang-format-merge
通过这种方法，人们可以将旧分支变基并合并到最新格式更新的主分支上，并且不会发生单独由格式引起的冲突。
答案 2 :(得分：0)
以下是我的团队成员在升级 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 采取类似的方法。