我有我希望的不是一个不可能解决的问题而不必手工完成。
最近，我正在进行的一个项目决定一劳永逸地解决我们所有的空白行李，并通过一次提交清理它们。我们决定使用GNU缩进来执行此操作，以便我们能够轻松地就将来的格式达成一致。结果是我有一个脚本可以正确格式化所有代码。问题是我们还有各种开发人员在功能分支上工作，其补丁现在都有冲突。
我想要的是一种修改这些补丁的方法，而不必解决每个补丁上的冲突，直到我在所有补丁上运行脚本为止。当我通过运行清理脚本依次修改每个提交时，下一个补丁仍然存在大量冲突，因为它期望所有空格都与当前空格不同。
有没有办法使用此脚本修改这些提交，并在执行此操作时忽略任何格式更改（可能不是因为我们正在使用格式化脚本分解代码行）？或者使用脚本修改补丁本身？
答案 0 :(得分：0)
更新 - 在原始答案之后添加了另一个选项
您可以配置merge的默认策略，以忽略仅限空白的更改。如果这样做，它将忽略它们 - 如果它们发生冲突，可能会在合并中撤消它们。但是，如果你将清理脚本应用于所有分支，也许这样就可以了（因为git可能会忽略你在这里添加了一些空格，但是这样做是为了支持你更改代码并添加相同的空格< / em>在另一个分支上。）
git merge -X ignore-space-change feature
（根据您想要忽略的空白，实际上有几种不同的选项可供使用;请参阅“合并策略”下的git merge文档，在“递归”一节中。）
如果你分裂线，这可能无法避免冲突;但是，如果它删除了90％的手工作品，那总比没有好。
我将包括我通常的警告，提供更改合并结果的选项可能是一件坏事，特别是如果默认合并选项会产生非冲突结果。但在您的用例中，默认选项会产生冲突;如果你只是在两个分支上完成清理工作，那么行为的改变就“有意义”;所以这里可能不是那么糟糕。
现在，我可能没有正确地关注你关于重新分支的评论，因为我不清楚为什么“他们是未合并的功能分支”意味着“所以我必须重新安排”...但是如果你说的话无论如何，你打算重新设置（或在任何意义上重写）功能分支，那么你还有其他选择。
例如，假设你有
x -- x -- x -- C <--(master)
\
F -- G <--(feature)
其中C是master上的清理提交;你的目的是将feature重新定义为master小费。你可以做点什么
git rebase master^ feature
包含非清理更改，为您提供
x -- x -- x -- C <--(master)
\
F' -- G' <--(feature)
然后执行“重新定位”操作以重新定位feature提交而不更改其内容（即，不进行合并操作）。你会使用git filter-branch; --parent-filter文档中的filter-branch示例提供了几种方法来执行此操作。 https://git-scm.com/docs/git-filter-branch
x -- x -- x -- C <--(master)
\
(F"-C) -- (G"-C) <--(feature)
在这里，我将新提交标记为(F"-C)以表示，而F"将是第二次放置F' C的结果，在此C如果featuer更改隐式“撤消”，则会重新显示而不是重新定位。
哪个没问题，因为现在在feature提示您重新运行清理脚本。由于合并master到C现在有资格快进（或等效，因为合并基础现在位于x -- x -- x -- C <--(master)
\
(F"-C) -- (G"-C) -- C2 <--(feature)
），因此不存在冲突。
def execute():
time.sleep(random.randint(0,9))
现在，您的历史记录显示了在导航序列化分支时弹出和执行代码的清理工作;对我而言，与基于rebase的工作流程所产生的线性历史并非毫不含糊地“清洁”或“整洁”一样清楚地说明了这一点。但这主要是一个单独的问题。