我想清理一个回购的历史记录,它有一年的提交量,总共大约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
来解决冲突,但是我不想这样做几百次。我可以自动化这个操作吗?
1条答案
按热度按时间wqlqzqxt1#
两个问题的答案:
git filter-repo
和相关工具lint-history
求解:重命名前端目录:
清理JS文件:
更漂亮
我需要编写一个名为
maybe-prettier
的辅助脚本,因为一些提交中有一些带有未解析合并符号的坏文件(<<<<<<<< HEAD
等)。Prettier无法格式化这些文件,并返回错误,从而停止了filter-repo
的进程。为了解决这个问题,maybe-prettier
首先检查一个文件是否可以格式化;它总是成功地退出。也许更漂亮