我们希望在 git 上有per-developer 分支。换句话说，开发人员会从“开发”分支分支出来，创建一个本地“功能”分支来继续工作。
当他们对自己的工作感到满意时，他们可以切换到devel，确保他们有最新的文件，然后 merge 到他们的“feature”分支，并在处理后将结果推送到origin与任何冲突。
然而，有一个问题——这使得提交历史变得非常困惑。
如果你执行 git log --graph，“feature”分支不会出现，这正是我们想要的。但是，开发人员所做的每一次提交现在都显示在 devel 分支上。那太丑了。如果有 10 位开发人员，并且在他们全部 merge 到 devel 之前，每个人都对他们的功能分支进行了 30 次提交，则 devel 现在显示总共 6 个功能的 180 次提交的历史记录。如果历史记录只显示 6 次 merge 到开发中的消息，那就更好了。
有什么方法可以避免让历史变得“困惑”并在 merge 时忽略本地分支的历史吗？或者这只是与 git 的斗争太多了？
我意识到这听起来可能很奇怪，但他们非常不喜欢所有这些对象最终出现在远程仓库中的想法。
最佳答案
正如您的团队所观察到的，如果您养成将初稿工作与其所有初始错误和糟糕的组织以及几乎足够好的实验和修复 merge 的习惯，那么您的历史将成为沼泽的邪恶恐怖。
不要那样做。
在您的本地存储库中完成初稿工作¹。然后完全重写初稿历史以供发布，git rebase -i 是为此推荐的常用命令，但我发现了 git reset --soft 后跟git add --patchs 更方便地创建可审查的历史记录，适合公众使用。然后完全返工，因为反馈使任何不当之处变得明显，并发布/merge 干净的结果。
对于其他人来说，开发者存储库本地的初稿提交系列除了读出他们的编辑器撤消缓冲区历史之外没有用处。事实上，这就是 Git 历史初稿的本质:一个项目范围的编辑器撤消缓冲区，带有注释以帮助解决下周不可避免的“我在想什么？”问题。没有其他人需要看到那些。它们是你 table 上的笔记，工作产品，出生时注定要扔进垃圾桶。
¹ 有一个沼泽存储库很好，开发人员可以在其中推送他们的 WIP 内容以实现可见性和协作，重要的是不要将 WIP 历史视为可丢弃的笔记，无论谁有副本。你管理它们的方式与你管理任何已投入生产的东西的方式非常非常不同
关于git - merge 和推送到远程时，有什么方法可以忽略本地提交历史记录吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56994822/