在过去的几天里，我对git进行了大量测试，我想我已经了解git的工作原理以及如何拥有干净的工作流程。但是我仍然有一个“问题”或一个我需要理解的问题：
Git rebase更改了历史记录。因此，在远程分支上使用它是不好的。是的，有git push --force，但是当其他人在远程分支上工作时，不应该使用它。
这里我的问题开始了！远程存储库的好处是，您始终要备份工作，并且如上所述，其他人也可以在该工作上进行备份。因此，针对项目的每个主要功能将master分成多个分支是一件好事，因为3个人可以处理origin / feature /，2个人可以进行origin / feature /等，依此类推。最终将那些与origin / master合并（是的，与commit合并）是完全可以的，并且可以查看末尾的历史记录，并查看哪个功能进入了项目的哪个版本（master上已标记的提交）。但是每个分支下的级别如何？
让我们说在Feature1、2上工作的那3个人应该在用户控件上工作。现在，人员A按照this工作流程开始进行工作，并拥有其本地分支机构。现在，用户控件是一件大事，在工作日内，他无法完成它，并且代码不可构建。 B人将继续执行A人所做的事情，但是将不可建造的东西推入遥控器是不好的！
我因这种情况而陷入的困境是： 您有以下可能性：
您在遥控器上创建一个子功能分支：起源/功能/聊天
然后将无法生成的更改推送到该分支。 B人可以使用您的东西。
问题：如果不使用git rebase并强制将更改的历史记录推送到origin / feature / -chat，则必须将分支合并（带有提交），使其成为origin / feature / -历史再次无法读取。
您将无法生成的更改推送到origin / feature /分支中。
问题：其他人可以拉出您的更改，并且需要注释掉您的代码，或者将其本地功能/分支重置为您之前的提交。
与1.相同。只是在聊天完成后，照常使用rebase，但是在这些操作之后删除了远程分支的起源/功能/聊天，因此不再可用。 / p>
在我看来，第一件事并不是很好，因为您将再次陷入糟糕的历史。至少然后，当远程存储库禁止强制推送时。 第二件事是可以的，如果Person A将其提交标记为不可构建（也许可以在此处使用标签，因此所有可构建的提交都具有特定标签），但是我仍然觉得这不是很干净。 到目前为止，第三件事是我的最爱，但这意味着很多分支删除操作，尤其是在远程，如果用户没有获得删除权限的话，可能会出现问题。即使可以给出这些，但如果这是选择的工作流程。但这真的是最干净的事情吗？
所以我的问题通常是：是否有第四个选项允许（通过远程分支）对自己的更改进行远程备份和轻松的团队合作，同时通过保留分支的数量使git-history保持干净，最后在历史记录中列出了最低限度？还是我给的第三个选择？
答案 0 :(得分：0)
人员B应当继续进行人员A的操作，但是将不可构建的东西推入遥控器是不好的！
仅当预期远程分支是可构建的。
例如，在master中推送不可构建的代码是不好的。
但是，将其推向一个有望在进行中的工作分支并不是世界末日：您可以继续进行协作。
为您的本地提交（with Git 2.6+）自动完成重新设置。
只要需要与同一分支合作的任何其他方都希望对子功能进行重新设置基序（并强制对其进行推送）。