清理git历史记录，vs分支备份

在过去的几天里，我经常接触git，我想我已经了解了git如何工作以及如何拥有一个干净的工作流程。但我还有一个“问题”或一个问题需要理解：

Git rebase改变了历史。因此，在远程分支上使用它是不好的。是的，有git push--force，但是当其他人在远程分支上工作时，不应该使用它

这就是我的问题！远程存储库的好的一面是，您总是有您的工作的备份，并且如上所述，其他人也可以使用它。因此，对于项目的每个大特性，将master拆分为分支是一件好事，因为3个人可以处理origin/feature/，2个人可以处理origin/feature/等等。在最后将这些特性与origin/master合并（合并提交时是的）是完全正确的，并且可以查看最后的历史记录，查看哪个特性进入了项目的哪个版本（在master上标记了提交）。但每个分支下的级别如何

假设有3个人在功能1上工作，2个人在用户控件上工作。现在，人员A开始工作，遵循工作流程，并拥有其本地分支机构。现在，用户控件是一个更大的事情要做，在他的工作日内，他无法芬兰语，他的代码是无法构建的。B个人将继续A个人所做的事情，但是把不可构建的东西推到遥控器中是不好的

在这种情况下，我面临的困境是： 您有以下几种可能性：

您可以在远程：origin/feature/-chat上创建子功能分支

然后将无法构建的更改推送到该分支。B个人可以用你的东西

问题：如果不使用git rebase并强制将更改的历史推送到origin/feature/-chat，您将不得不（通过提交）将分支合并到origin/feature/中，从而使git历史再次无法读取

将不可构建的更改推送到原点/要素/分支中

问题：其他人可以提取您的更改，并且需要注释掉您的代码，或者将其本地功能/分支重置为提交之前的提交

与1相同。只是聊天结束后，会像往常一样使用rebase，但是远程分支来源/功能/-聊天在这些操作之后会被删除，因此不能再使用了

在我看来，第一件事并不是很好，因为你会再次陷入一段糟糕的历史。至少在远程存储库禁止强制推送时。 第二件事是可以的，如果一个人A将他的提交标记为不可构建（也许这里可以使用标记，所以所有可构建的提交都会得到一个特定的标记），但我仍然得到这样的警告：这不是很干净。 到目前为止，第三件事是我最喜欢的，但这意味着要删除很多分支，尤其是在远程分支上，如果用户没有获得删除权限，这可能会出现问题。尽管可以给出这些，但这将是选择的工作流程。但这真的是最干净的事情吗

因此，我的问题是：是否有第四个选项允许远程备份（通过远程分支）自己的更改和轻松的团队合作，同时保持git历史记录的干净性，将历史记录中最后列出的分支数量保持在最低限度？还是我给的第三个选择

B个人将继续A个人所做的事情，但是把不可构建的东西推到遥控器中是不好的

仅当远程分支预期是可构建的时

例如，在master中推送不可构建的代码是错误的。
但把它推到一个正在工作的分支机构，在那里它有望成为一项正在进行的工作，这并不是世界末日：你可以继续在这方面进行合作

为您的本地提交（）自动重新设置基础。
重新设置子特性的基址（并强制推送它）是可以的，只要需要使用同一分支的任何其他方都希望这样做

B个人将继续A个人所做的事情，但是把不可构建的东西推到遥控器中是不好的

仅当远程分支预期是可构建的时

例如，在master中推送不可构建的代码是错误的。
但把它推到一个正在工作的分支机构，在那里它有望成为一项正在进行的工作，这并不是世界末日：你可以继续在这方面进行合作

为您的本地提交（）自动重新设置基础。

---

重新设置子功能的基址（并强制推送它）是可以的，只要需要使用同一分支的任何其他方都希望这样做。

我喜欢这样说：如果使用该名称的每个人都事先同意以这种方式使用该名称，则重新设置基址是可以的。因此，在私人回购中，重新设定基准是可以的，因为你只需要与自己达成一致。但在公共回购中，如果其他所有人都同意该分支机构将被重定基期，那么这也没关系，因此知道该分支机构将被重定基期，以及当它发生时如何处理。我喜欢这样说：如果所有使用该名称的人都事先同意以这种方式使用该名称，则重定基期是好的。因此，在私人回购中，重新设定基准是可以的，因为你只需要与自己达成一致。但在公开回购中，如果其他所有人都同意该分支机构将被重定基期，并且因此知道预期情况以及发生时如何处理，也可以。因此，基本上这三个选项都可以，并且取决于团队决定执行的工作流程？所以没有第四种选择？@Apahdos我不知道。所以基本上这三种选择都是可以的，取决于团队决定执行的工作流程？那么就没有第四种选择了？@Apahdos我不知道。