合并一个分支，但不要让gitk充满杂音，但不要隐瞒它的来源

Question

我可能做错了或者误解了这里的某些东西，但基本上我不想让我们的主分支充满噪音，但我不想在我的历史上撒谎。

所以我们有一个master分支和一个dev分支

在这种情况下，我们还有一个特性分支，既有重要的，也有看似不重要的(当天提交等)

我将feature分支合并到了dev分支上，因为我不介意dev分支上的噪音。然而，现在我正在将dev分支合并到master上，我不希望所有的噪音都来自我的feature分支。

我认为merge --squash dev_branch是答案，但这看起来好像我突然灵光一闪，在一个晚上完成了所有的工作，完全没有提到这是一个合并的事实，并且在gitk中根本没有提到功能分支。

我想带来一些改变，这样在gitk中你看到的只是“合并的特性”或者“合并的dev_branch”，而不是所有的噪音。

我可以在dev_branch上使用git rebase来清理来自feature分支的提交，这样我仍然可以保留feature中的更改，没有任何谎言，并在dev_branch...but中美化它这似乎也是错误的

到目前为止，我想出的最好的解决方案是做git merge --squash dev_branch

并且只需注释“查看特性分支以获取更详细的历史记录”

我是不是走错路了？我真的应该担心“噪音”吗?你能将某个分支下所做的更改折叠起来吗？

所以它并不完全是Git: merge all changes from another branch as a single commit

Answer 1

我有时会使用以下工作流程，它可能适合您：

1. 我在我自己的存储库中使用本地功能分支(不是推送的)。现在，我将更改拉到主frequently.
2. Every，然后我会将我的功能分支重新设置为
3. 。如果我想这样做，我会交互地做，并修复历史记录。
4. 当功能完成时，我做了最后的rebase，然后我用--no-ff合并到master，以强制合并提交。

最终结果是包含合并提交的历史记录，很容易跟踪，但仍然清楚地表明在分支中已经完成了逻辑上独立的工作。

|
|
*   merge commit
|\
| \
|  *
|  |
|  *
|  |
|  *
| /
|/
*   common ancestor
| 
|

如果您愿意，您还可以获得一个合并提交，该合并提交可用于git revert整个功能。

Answer 2

我决定使用：

gitk --first-parent

从文档中：

-- first -parent :：在看到合并提交时只关注第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概述，因为合并到主题分支往往只是为了不时地调整以更新上游，并且此选项允许您忽略由此类合并带来的单个提交。

有时我会有长时间运行的特性分支，它们必须从主线合并(只合并，没有squash或rebase)更改。

gitk --first-parent非常好。不是完美的，但可以完成工作。

Answer 3

您是否已经推送了dev分支并将其与他人分享？

如果不是这样，交互式rebase会做得很好

git checkout devbranch
git rebase -i master

Git rebase将让你有机会通过编辑提交来清理你的历史记录，将它们挤压在一起，拆分它们，甚至跳过一些。

上面的代码将会把devbranch的提交直接放在master之后的历史记录中。如果你觉得这太“谎言”了，那么你可以在它自己的基础上重新建立devbranch的基础，这样你就可以重写历史，但仍然可以把它作为一个分支从以前的位置开始。

git merge-base master devbranch
git rebase -i <hash output of previous command>