2

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

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

在这种情况下，我们还有一个包含重要和看似不重要的功能分支（当天提交等）

我将功能分支合并到 dev 分支上，因为我不介意 dev 分支上的噪音。但是，现在我将 dev 分支合并到 master 上，我宁愿不要从我的功能分支中获得所有噪音。

我认为 merge --squash dev_branch 是答案，但这似乎表现得好像我突然灵光一现，并在一个晚上完成了所有工作，完全没有提及它是合并的事实，而在 gitk 中没有提及完全属于功能分支。

我想进行更改，以便在 gitk 中您看到的只是“合并的功能”或“合并的 dev_branch”，但没有下面的所有噪音

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

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

只需发表评论“查看功能分支以获得更详细的历史记录”

我会以错误的方式解决这个问题吗？我真的应该担心“噪音”你能折叠在某个分支下所做的更改吗？

所以它不完全是Git：将来自另一个分支的所有更改合并为单个提交

4

3 回答 3

2

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

  1. 我在本地功能分支（未推送）上的自己的仓库中工作。
  2. 我经常将更改拉到 master 上。
  3. 我时不时地将我的功能分支重新设置在 master 上。如果我愿意，我会以交互方式进行并修复历史。
  4. 功能完成后，我会进行最终的 rebase，然后合并到 master--no-ff以强制合并提交。

最终结果是一个包含合并提交的历史记录，易于理解，但仍清楚地表明逻辑上独立的工作已在分支中完成。

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

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

于 2013-06-07T18:35:12.867 回答
2

我已经决定使用：

gitk --first-parent

从文档：

--first-parent :: 在看到合并提交时仅关注第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概览，因为合并到主题分支往往只是不时调整到更新的上游，并且此选项允许您忽略引入的单个提交通过这样的合并你的历史。

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

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

于 2016-08-12T16:32:27.927 回答
0

您是否已经推送了 dev 分支并因此与其他人共享了它？

如果没有，交互式变基会做得很好

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>
于 2013-06-06T19:04:28.743 回答