正如你的团队所观察到的，如果你养成了一种习惯，把初稿和它最初的错误、糟糕的组织、几乎足够好的实验和修正合并在一起，你的历史将是一个邪恶的沼泽地。
不要这样做。
在你的本地存储库中完成第一稿工作。然后完全重写第一稿历史以供出版，git rebase -i是推荐的常用命令，但是我发现git reset --soft后面跟着git add --patch s更方便创建一个可审查的历史，一个适合公共消费的历史。然后完全重写它，因为反馈会使任何不正确的地方变得明显。并发布/合并清理结果。
对于开发者repo本地的提交序列初稿，对于其他人来说，只不过是读取他们的编辑器撤销缓冲历史而已。事实上，这就是Git历史初稿的本质：一个项目范围的编辑器撤消缓冲区，其中的注解可以帮助解决下周不可避免的“我在想什么”问题。没有人需要看到这些。它们是你桌上的注解，是工作产品，注定要在出生时被扔进垃圾桶。
¹有一个沼泽式的存储库，开发人员可以在其中推动他们的WIP材料以实现可见性和协作，重要的是不要把WIP历史当作除了可丢弃的注解之外的任何东西，不管谁有一个副本。

• 如果执行git log，“feature”分支不会出现，这正是我们想要的。然而，开发人员所做的每一次提交现在都会出现在devel分支上。*

默认情况下，git log会显示一个简单的线性版本的历史记录，并且是false。Git历史记录不是线性的。分支实际上是分支。
而不是这个...

A - B - C - D - E - F - G - H [devel]

你的历史真的像这样。

A ---------- E ----- H [devel]
 \          / \     /
  B - C - D    F - G

你可以用git log --graph或像Gitup这样的Git可视化工具来查看。
每个“特性气泡”都是来自每个分支的提交。使用真实的历史记录，你可以看到作为一个特性的一部分开发了什么提交。虽然这看起来很“混乱”，但这对理解代码很重要。它与git blame一起使用沿着特别有用。

• 有没有什么方法可以避免把历史记录弄得“混乱”，并且在合并时忽略本地分支的历史记录？或者这只是与git的斗争太多了？*

我的建议是习惯它，并学习如何导航它。例如，git log --merges只会显示合并提交。一个好的Git可视化工具会有很大帮助。
另一个是鼓励开发者在提交之前清理他们的分支。如果你有很多“错字修复”、“哎呀”和“破坏测试”的提交，这些都是没有价值的。They can use git commit --amend to change the previous commit, and git rebase -i "fixup" to merge existing commits together。这确保了所有的提交都是有一定后果的。
如果你真的想这样做，你可以做一个“squash merge”，git merge --squash，而不是保留完整的提交历史，这将把所有的修改和分支中的所有提交消息粉碎成一个提交。
虽然这会产生一个“干净”的历史记录，但它会丢失很多关于代码是如何开发的粒度信息。例如，如果分支中有30个提交，而你执行git blame来理解某段代码，你会得到所有30个提交的提交消息，但却无法知道哪一个适用于该代码。
你所看到的“混乱”是对 * 为什么 * 代码是这样写的有价值的见解。这对任何一个处理代码的人来说都是***黄金***。一旦被破坏，就再也不能恢复了。

• 有没有什么方法可以避免把历史记录弄得“混乱”，并且在合并时忽略本地分支的历史记录？或者这只是与git的斗争太多了？*

当然。简单地说，不要合并任何东西。有一个公共的回购，你可以单独挑选提交。一种方法是通过像Gerrit这样的审查系统。
挑选樱桃将确保您有干净的，线性的历史没有合并混乱。
但是，重要的是要得到个别的变化：例如，如果开发一个特性需要15次提交，那么15次提交应该被记录下来。这一点很重要，原因有很多。其中之一是多次较小的提交更容易发现和隔离git bisect的bug。如果一次修改了一行代码的小提交被认为是导致回归的原因，这比将具有300个改变的提交暗示为相同的回归更容易弄清楚。
值得鼓励的是，开发者在合并之前清理他们的特性分支。例如，不要提交那些只修复微不足道的编译器错误的代码（“忘记了parse_descriptor中的分号，哎呀！”）。或者提交那些“清理”代码，这些代码最初只是因为相同的特性开发而变得混乱。也不鼓励提交那些“偏离主题”的特性分支。
一个好规则是每个提交都应该构建;任何一个提交都不应该破坏任何东西，这样它就需要一个后续的提交。2这样的提交应该被挤压在一起。
每个人都应该了解如何使用git的交互式rebase来重新排序、压缩和纠正提交。

只提交工作分支并不总是可行的。也许你指的是“合并到master”，我同意：仅提交工作代码（至少通过了所有测试）欺骗其他团队成员的最好方法之一就是把损坏的代码放进他们最终要合并的东西里。你最终会得到一个混乱的局面，特别是如果损坏的代码没有立即揭示它的问题，更多的提交堆积在它上面，这时你需要使用git-bisect来找到哪个提交破坏了构建，因此您需要一个未压缩的历史记录，以便能够找到导致问题的确切提交。
但是有各种各样的理由在一个单独的分支中提交未完成的工作。
1.在尝试新的工作之前保存当前的工作区，因为新的工作可能不起作用，您可能需要轻松地恢复工作区。
1.您需要停止使用一台计算机，并在另一台计算机上处理工作，就像下班回家一样。
1.你可能已经在某个特性上做了一些未完成的工作，但最终没有被使用，但是你为支持新特性而编写的实用函数在以后可能会很有用。通过将它放在分支中，你可以避免将“你所做的所有工作”放在主产品中。
压缩的问题是，每隔一段时间，你就会遇到一个非常严重的bug，你需要做一个git bisect（提交的二分搜索）来找到导致bug的提交。Git已经成为一个代码组织者，而不是一个版本控制系统，因为所有这些关于压缩和干净提交的狂热。你总是可以

git log --simplify-by_decoration

如果您只想查看重要的或主要的提交。
您可以在合并到母版之前创建一个单独的挤压分支，但保留旧的未挤压分支不变，这样可以两全其美。反之亦然，创建一个未挤压分支，并在合并到母版之前挤压原始分支。
如果需要的话，您可以查看单个提交，但不要弄乱您的主分支。