如何进行进行中的重构？

因此，我有一个大项目，正在由我进行重构。我正在更改很多东西，因此没有机会让它尽快编译。我住在我命名的特殊git分支中cleanup（master当然，最终将合并到该分支中）。

问题是，我/我们有一个永远不要提交非编译代码的策略（理想情况下，它也应该起作用，但至少必须编译和链接）。因此，在完成这项艰巨的任务之前，我什么都做不了（审查或簿记）。
这不是我喜欢的工作方式（我相信大多数人每天至少要做一次）。

你怎么看？我有没有解决的办法？
以后可以告诉git汇总提交或其他内容吗？只要它们停留在cleanup分支中，我就可以忍受未编译的提交。

编辑

关于推送/提交的主题：我知道这是一个巨大的差异，但是稍后，当我将自己的内容合并到中时，修订版本将不完整master。因此，如果您浏览历史记录（或git bisect...），那么“本地”修订将可在世界范围内访问。因此，仅在本地提交而不进行推送不是最佳解决方案，因为这将在以后（当主题关闭并忘记一段时间后）给您带来麻烦。

简而言之：本地提交将最终被推送。全局历史记录不应显示未编译的提交。

该git merge --squash命令允许您在当前分支之上创建一个提交，其作用与合并另一个分支相同。该命令将更新工作树并分阶段更改索引，因此接下来要做的就是提交：

git checkout master
git merge --squash cleanup
git commit -m "Merge cleanup branch"

该git rebase -i命令还可以压缩提交，但需要更多工作。

重写不是重构

我意识到您对如何使用Git感兴趣，但是我认为您应该考虑比使用Git来改变重构方式（尽管我确实认为Git可以帮助您）。

Martin Fowler将重构定义为：

一种用于重组现有代码主体，更改其内部结构而不更改其外部行为的有纪律的技术。

它的核心是一系列小的行为保留转换。每个转换（称为“重构”）几乎没有，但是一系列转换可以产生重大的重组。由于每个重构很小，因此出错的可能性较小。每次进行少量重构后，系统都将保持完整的工作状态，从而减少了系统在重组期间可能严重损坏的机会。

如果应用此方法，则可以定期提交（和推送）。

您可能会认为这是不切实际的，并且不适用于大规模的项目。这是Mikado方法可以提供帮助的地方。通过创建依赖关系图，可以将大型重构分解为一系列小型重构。该方法是递归的，请尝试进行更改，不要破坏任何内容，否则请还原您的更改并记下先决条件。您一步一步地修复了这些必备的重构，直到可以实现主要的重构目标。

Git确实可以帮助这种方法。您可以保留本地（中断）分支。当您提交（并推动）子目标时，您可以rebase将主目标分支移至您刚刚进行的提交之上，直到不再被破坏为止。

查阅手册页，了解git rebase，尤其是git rebase -i变体。它使您可以对历史记录中的任意数量的提交进行重新排序，删除或压缩，这听起来像您正在寻找的内容。我一直在您所描述的情况下一直使用它：进行许多不适合公众使用的小提交，然后将它们一起压入单个“重构”提交中，然后再推送到共享存储库。

您正在使用Git，因此提交并不一定意味着要推动您的更改。

恕我直言，并且与Git一起工作，即使不进行编译，也可以提交您的工作，这是非常好的……因为，毕竟，一旦提交了更改，就没有人可以使用该代码（直到您将其推送）。当然，在推送它之前，必须确保它运行良好并可以编译，以便其他人可以毫无问题地获取并合并您的更改。

另外，您在与主分支不同的分支上工作。因此，如果您愿意（我建议这样做），则永远不会推送分支。重构完成后，只需签出master分支，合并更改并推送master分支。

编辑

在这种情况下，您可以使用git cherry-pick或玩转git rebase