我想清理一个回购的历史记录，它有一年的提交量，总共大约4000次。

• 有一位贡献者一直不同意格式标准，并反复修改Prettier配置文件，或者根本不使用Prettier。结果，git的历史就像是一场拉锯战，表面上的修改有着巨大的差异，真实的的修改很难找到。
• 前端目录的名称在某个时候被重命名了，我们从该目录中加载项目，这使得从VSCode访问早期的git历史记录变得很麻烦。
• 在某个时候添加了一个TypeScript转发器，为项目中的每一个file.ts生成一个file.js和file.js.map。这些文件的生成并不一致（有时它们在结尾有一个特定的注解，有时没有），这增加了git历史记录中的噪音。

我的初步计划是重新设置所有内容的基础：

为了以防万一，我将保留一个repo的备份，然后在每次提交时执行以下操作：

• 应用一致的Prettier设置;
• 如有必要，请重命名前端目录;
• 删除所有不必要的file.js和file.js.map文件。

然后，我们的团队将转移到新的回购协议。
具体而言：

GIT_SEQUENCE_EDIT=cat git rebase
  --strategy recursive --strategy-option theirs --rebase-merges \
  --exec '../cleanup.sh && git add . && git commit --amend --no-edit --no-verify --allow-empty' \
  e709bcd1

其中e709bcd1是一个很好的开始位置的SHA，使用脚本cleanup.sh：

#! /usr/bin/env zsh
setopt nullglob

echo $(git rev-parse HEAD) > commit.log

# If both directories exist, assume old_front_end is the real one,
# so delete new_front_end to allow us to rename old_front_end.
# (Otherwise, `mv` will move the one directory into the other.)
if [[ -d "old_front_end" ]] && [[ -d "new_front_end" ]]; then
  rm -rf new_front_end
fi

# Rename old_front_end if necessary
if [[ -d "old_front_end" ]] && [[ ! -d "new_front_end" ]]; then
  mv old_front_end new_front_end
fi

if [[ -d "new_front_end" ]]; then
  # Clean up JS files
  for file in "new_front_end/src/**/*.ts"; do
    [[ ! -e $file ]] && continue  # skip following if no such file
    rm "${file%.*}.js"
    rm "${file%.*}.js.map"
  done

  # Apply consistent Prettier settings
  prettier --config ~/external_source_of_truth/.prettierrc -w "new_front_end/src/**/*.{js,ts,svelte,gql,css,scss}" || true
fi

问题：

• 我没有太多的经验，或者写shell脚本。这是一个合理的计划吗？它会有不幸的后果吗？
• 我试着运行这个脚本，它经常因为合并冲突而卡住。看起来我总是可以简单地通过执行git add . && git rebase --continue来解决冲突，但是我不想这样做几百次。我可以自动化这个操作吗？