标签: squash

有时我需要从 Eclipse 合并南瓜。我知道我可以在命令行中完成此操作，但是在 Eclipse 中集成图形选项将非常有用。你知道该怎么做吗？

我已经阅读了一些有关--squashing提交的内容，但是它们似乎都与com并存--rebase。

我有一个功能分支，带有一组这样的提交：

(Feature)          A --> B --> C --> D --> E --> F --> G
                  /
(Master)  M1 --> M2 --> M3

假设我想合并回Master分支，但是我想先清理功能上的提交。

是否有可能：

• 选择提交B，E和F，并将它们压在一起作为一次提交？

要么

• 我是否只能压榨顺序提交的内容，所以压榨：（A，B和C）或压榨（D，E和F）等？

无论哪种方式，我都可以直接在自己的特征上进行挤压，而无需立即初始化Merge或Rebase使用它吗？

如果是这样，我该如何使用Git？

我收到了公关,并希望压缩提交,所以这很好.

我不确定我是否可以这样做或各自的作者必须这样做？当然,我希望保留作者的名字引用他们的壁球提交.

注意:这个问题不是关于我压缩自己的提交.

这是PR在Git中的样子:

或通过cli:

c:\Projects\Foo>git log --pretty=oneline
7fab9ae1031c13414909668f342582bdc8081f5a <Author - Red>
a02270b2014fd3995456773cd7badc7df0c72cf6 <Author - Blue>
6ae3d6c8b5a8b037c0e4dc88d24ec5598ff1933e <Author - Blue>
100f6513aacbe431b56f3082597749cddca284c8 <Author - Blue>
d263a5c8924053678f455b5ee8515bbb16aacf49 <Author - Blue>
c3cc5dbc13ac77e0a552a2d3132d255df3c7a6e4 <Author - Blue>
71f89b3f3dd583cd97d4a0806a973a4d1af64fe9 <Author - Red>
f14ef616a852f3a7311f4f7b9e05d460e0574422 <Author - Red>
015f30b3828828404b5549ee8a7df2aefdfa9424 <Author - Red>
9b22a4d2ded54cb754883d9d6418a39eb34df7cf <Author - Red>
33a10e9828d04cf82439a6c60b8cf4c0c2f122a3 <Author - Red>
4615c7747c4546809b29e063986c697c7c64cbc4 Added Specific naming rules, section.
b8ee154e38338022649caef40945c6f0297a59ce Added method parameters, section.
bc860c7609cc80caf41fc5944c1b39201019a80e Added Input and View Models, section.
ad6b3e4bee1cb9d8afcf9cd1fa8815769d80133b Fixed bad markdown formatting.
5929d5b38aad8bb7cc3da4976dd81883eab0f999 …

在做正常的合并，例如git merge <branch>，git创建一个合并提交并更新HEAD到提交当前分支。

git merge <branch> --squash但是，在进行壁合并时，例如，不会进行提交，而是说（在干净的合并中）：

Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested

这背后的原理是什么？对我来说，这似乎是普通合并和壁球合并之间的意外差异。如果正常合并和壁球合并之间的唯一区别是壁球合并壁球提交，对我来说将更直观。

如果我有这样的提交历史：

A-B-C-------G-H-J-K   (master)
     \     /
      D-E-F

如何将 A 和 K 之间的提交压缩为一个提交 Z：

A-Z-K   (master)

?

当我压缩分支中的提交（使用 git rebase -i）时，我总是很恼火，因为压缩的提交与旧的提交而不是新的提交结合在一起。

我不明白为什么要这样设计。当我提交正在进行的工作 (WIP) 时，它表示未编译或未完成的代码。当我最终承诺“它终于起作用了！” 在合并之前进行提交和压缩，将这些 WIP 提交合并到“它终于可以工作了！”中更有意义。提交，而不是与之前的提交合并。压缩 WIP 本质上是用我知道无法编译的代码“破坏”了之前的提交。

为了解决这个问题，我的工作流程是压缩来自“它有效！”的提交。一直回到第一次 WIP 提交之前的状态。但这不是很愚蠢吗？其他人在做什么，这使得将 WIP 压缩到之前的提交有意义？

我已经回顾了几个关于压缩最新提交和压缩根提交的相关问题,但这两个问题都不能帮助我压缩不是根本的非最近提交.

这是我的开始场景:

D---E---F---G---H---I---J master

和我想要的结果:

D---E---Z---I---J master

什么Z是壁球F---G---H,和F---G---H,D---E和,I---J可以是任意长的非分支提交序列.

第一种方法:

[lucas]/home/blah/$ git rebase -i D
rebase in progress; onto D
You are currently editing a commit while rebasing branch 'master' on 'D'.

No changes
You asked to amend the most recent commit, but doing so would make
it empty. You can repeat your command with --allow-empty, or you can
remove the commit entirely with "git reset HEAD^". …

我确实尝试过浏览类似的主题，但我似乎无法掌握这个概念。

我分叉了一个仓库，做了一些更改。加班的时候，我也用过git fetch upstreamandgit merge upstream/<branch>几次。有时，我会解决并重新测试一些冲突。

现在，当涉及到将更改推送到上游时，我想进行一次提交。我得到的指示是使用git fetch upstream和git rebase -i upstream/<branch>。

我不明白的是，我再次陷入解决冲突的困境。我不明白为什么当我的叉子与它的起源相同时我需要解决冲突。我可以备份所有修改过的文件，核对我的分叉，再次分叉，恢复备份，这样我就没有冲突需要解决并准备提交。这个过程似乎很机械，我不明白为什么我必须走这条艰难的路（再次解决冲突）。

有人可以帮我理解吗？

您好，我有一个稳定的分支，其中包含其他分支的合并提交。结构如下：

提交历史：

Commit 1 - Branch 1 commit 1 ------------- Hash Code 1
Commit 2 - Branch 2 commit 1 ------------- Hash Code 2
Commit 3 - Branch 2 commit 2 ------------- Hash Code 3
Commit 4 - Branch 2 commit 3 ------------- Hash Code 4
Commit 5 - Branch 3 commit 1 ------------- Hash Code 5

分支 1,2,3 被删除并已合并到 stable 中。有什么方法可以在提交历史记录中压缩提交 3 和提交 4。

期望的结果：

Commit 1 - Branch 1 commit 1 ------------- Hash Code 1
Commit 2 - …

我在 git 存储库中使用GitFlowmaster ，因此我有一个, developand （临时）release分支。

工作流程

1. develop我从（例如fix/fix-the-bug）创建一个新分支
2. 我将修复压缩为有意义的提交
3. 我将我的fix/fix-the-bug分支合并到develop
4. 一旦我合并了足够的分支，我就会创建一个（临时）release/x.y.z分支develop
5. 我对分支中的脚本进行版本升级release/x.y.z并标记提交
6. 当我想合并release/x.y.z到时master，我遇到合并冲突。似乎master不明白提交已经存在于master
7. release/x.y.z分支被合并到develop
8. 我删除release/x.y.z

有几点需要注意，不确定是否全部正确：

• 当合并到 master 时，我将我的提交压缩为一个提交
• 应该有一个 git 标签来master指示版本号，但不确定如果我压缩提交是否可以正常工作。

问题

我现在想知道：

• 我如何修复我的仓库，因为我认为我不应该遇到这些冲突。
• 欢迎对工作流程提出任何进一步的建议（例如，我在哪一部分可以最好地执行壁球）。