我们目前正在使用git，我试图为人们提供合理的工作流程，但目前有一个问题我不知道如何解决。如果在我们将合并返回到主分支时发生冲突，我们将丢失压缩的提交消息中的历史记录，这是我们想要保留的内容。目前的工作流程如下：
git pull - 这应该在主分支上完成。git checkout -b TASK-ID - 为任务创建一个新分支。 TASK-ID 类似 TASK-101 git checkout master git pull - 获取自上次拉动以来所做的任何更改。git merge --squash TASK-ID - 这会将分支中的所有提交视为合并时的一次提交。git commit - 在提交消息中添加任何其他信息，特别是 TASK-ID 。应该注意的是，包含了来自分支的所有提交消息，因此在合并发生时它们不会丢失。git push - 将更改推回服务器。一些背景：我们目前没有很多人在研究这个问题，我们不经常看到冲突。压缩提交的原因是我们为每个任务都有一个提交。这样，如果我们的Bamboo服务器发现构建有问题，我们可以轻松地将其绑定回任务并让开发人员修复它。此外，它保持主历史更清洁，因为我，至少，倾向于做出很多提交。是的，我知道如果我们开始与更大的团队打交道，这可能需要改变，但这是将来的。
现在，我确实意识到在这种情况下，我们可以简单地在合并之后进行拉动，但这并不能完全解决问题，因为我们的开发人员可能不得不临时切换分支来修复以更高的优先级发布或工作。我希望看到的是我们如何在不失去压缩合并中的提交历史的情况下实现我现在所获得的目标。我已经研究了几种使用rebase的解决方案，但它们都不是我想要的。
总而言之，我的要求是：
答案 0 :(得分：1)
也许我误解了，但我通常所做的就是让我的主人始终保持平等或者在主人之后。这样，当我做一个git pull，它从来没有任何合并要做（因为主人的历史永远不会在我的团队中被覆盖）。 在我执行git pull之后，我转到TASK-101分支并将master的结果合并到此分支中。所以task-101将拥有我的提交，master中的提交，以及可能的合并提交。每当我觉得有必要更新我的工作回购时，我都可以这样做。
当我准备好提交时，我最后一次这样做，然后我去掌握并压缩来自任务101的提交，并在之后做一个dcommit，以避免因为时间窗口而发生冲突的可能性在最后一次拉动和推动之间是非常小的。（在我的团队中从未发生过一次。如果它发生了。如果它发生了，我可能必须通知团队并重写历史）。
答案 1 :(得分：1)
您必须明白merge --squash有一些缺点：
正确的做法是this answer中详细说明。我说显然是因为我还没有测试过 - 我会尽快为myself做这个答案 要从TASK-101分支获取提交消息，请尝试建议here
修改：对于原始问题.git/SQUASH_MSG