我喜欢卢克的回答,除了需要手动指定基础提交或使用重新基于工作流程的限制之外,你需要将历史线性化。我提出的修改不需要额外的参数,也不会改变您的提交图拓扑结构。以下是一个Shell命令示例:
git rebase --whitespace=fix --onto $(git merge-base HEAD @{u})
作为一个~/.gitconfig别名:
ws = "!git rebase --whitespace=fix --onto $(git merge-base HEAD @{u})"
我喜欢这种方法,因为有时候我想要变基我的修改,但是如果我认为可能会出现合并冲突,我更愿意合并,这样我的原始修改和解决冲突的记录都会被记录在历史记录中。这样我以后可以重新考虑冲突解决方案,如果需要的话可以重新执行。
考虑到我并不总是变基,我不喜欢把空格修复和变基混在一起;因此,我修改了Luke的答案。
此外,我启用了默认的预提交挂钩,它会在出现空格错误时中止操作:
cp .git/hooks/pre-commit.sample .git/hooks/pre-commit
这里提供了以下工作流程,我喜欢它,因为它足够手动化,让我知道正在发生什么,但自动化程度又足够高,不会妨碍到我:
- 进行编码,引入空格错误
- 尝试提交
- 由于预提交挂钩而提交失败,出现空格错误
git commit --no-verify
进行提交
git ws
使用别名进行修复
关于使用
--onto
的说明:这里并不需要,但我发现这样更容易理解rebase的工作方式。在Luke的版本中,
HEAD~3
是man页面中的
<upstream>
,而在我的版本中,
<upstream>
保持其默认值为分支的真实上游。无论哪种方式,最终结果都是相同的。
git add -Ae
根本没有添加新文件" 吗?还是说:"文件已经被添加,但没有被固定"? - VonC