让我直接明确地回答您的观点：
我们的问题是长期的分支机构-在这种情况下，您需要几个人在与分支机构分离的分支机构中工作，我们会发展几个月，而当我们达到一个里程碑时，我们就会将两者同步。
通常，您几个月都不想让您的分支不同步。
根据您的工作流程，功能分支已经分支了。master为了简单起见，我们称之为它。现在，只要您致力于掌握，就可以并且应该git checkout long_running_feature ; git rebase master。这意味着，根据设计，您的分支始终保持同步。
git rebase这也是正确的做法。这不是hack，也不是奇怪或危险的东西，而是完全自然的。您丢失了一点信息，这就是功能分支的“生日”，仅此而已。如果有人认为这很重要，可以通过将其保存在其他地方（在票务系统中，或者如果需要的话在git tag...中）来提供。
现在，恕我直言，处理此问题的自然方法是将侧枝压缩为单个提交。
不，您绝对不想要那样，您想要一个合并提交。合并提交也是“单个提交”。它不以某种方式不将所有单个分支提交“插入” master。这是一次带有两个父级的提交- master合并时的头和分支头。
当然，请务必指定--no-ff选项；--no-ff在您的情况下，严格禁止不合并。不幸的是，--no-ff这不是默认值。但我相信您可以设置一个选项。看看git help merge有什么--no-ff作用（简而言之：它激活了我在上一段中描述的行为），这一点至关重要。
我们不会将数月的并行开发追溯到大师的历史中。
绝对不是-您永远不会将某些内容“转储到”某个分支的历史记录中，尤其是不要使用合并提交。
而且，如果有人需要更好的分辨率来解决分支机构的历史，那么，当然，所有这些仍然存在-它不是大师，而是分支机构。
有了合并提交，它仍然存在。不在母带中，而是在分支中，作为合并的父项之一清晰可见，并应保持永恒，如其应有的那样。
看看我做了什么？你描述你的壁球所有的事情都承诺在那里与合并--no-ff提交。
问题出在这里：我只使用命令行工作，而我团队的其他成员则使用GUIS。
（旁注：我几乎还专门使用命令行（嗯，这是个谎言，我通常使用emacs magit，但这是另一个故事-如果我不方便使用单独的emacs设置，我更喜欢使用命令线也一样）。但是请不要自己一个忙，至少尝试git gui一次。它是如此采摘线路，帅哥等添加更加高效/撤销补充道。）
而且我发现GUIS没有合理的选项来显示其他分支的历史记录。
那是因为您试图做的完全违背了精神git。git从核心建立在“有向无环图”上，这意味着很多信息都在提交的父子关系中。而且，对于合并，这意味着真正的合并是由两个父母和一个孩子提交的。只要使用no-ff合并提交，同事的GUI就可以了。
因此，如果您达成壁球承诺，说“此开发已从XYZ分支压缩”，那么去查看XYZ中的内容将是巨大的痛苦。
是的，但这不是GUI的问题，而是南瓜提交的问题。使用壁球意味着您将要素分支头悬空，并在其中创建了一个全新的提交master。这从两个层次上破坏了结构，造成了很大的混乱。
因此，他们希望合并这些大型的，长期的开发分支，并始终使用合并提交。
他们是绝对正确的。但他们不是“合并的 ”，他们只是合并。合并是一个真正平衡的事情，它没有将“合并”为另一侧的首选面（除了微小的视觉差异（如分支被交换等）外，其他git checkout A ; git merge B都完全相同）。git checkout B ; git merge Agit log
他们不需要任何无法从master分支立即访问的历史记录。
这是完全正确的。在没有未合并功能的时候，您将拥有一个master具有丰富历史记录的分支，其中囊括了曾经存在的所有功能提交行，git init从一开始就回溯到提交（请注意，我特别避免使用术语“在该段的后半部分“分支”，因为当时的历史不再是“分支”，尽管提交图会非常分支。
我讨厌那个主意；
然后您会感到有些痛苦，因为您正在使用所使用的工具。这种git方法非常优雅和强大，特别是在分支/合并区域。如果您做对了（如上文所提到，尤其是使用--no-ff），则它比其他方法（例如，具有分支的并行目录结构的颠覆性混乱）优越得多。
这意味着平行发展历史的无尽，不可逾越的纠结。
无尽，平行-是的。
无法导航，纠结-不。
但是我没有看到我们有什么选择。
为什么不git每天都像发明家，您的同事和世界各地的发明家那样工作？
除了不断地将分支机构与合并提交合并到主分支之外，我们这里还有其他选择吗？还是有一个原因导致不断使用merge-commits并不像我担心的那样糟糕？
没有其他选择；还不错
