问题标签 [squash]

我的主题分支在我分支之前大约有 20 个提交。

我想自动将所有这些提交压缩到分支之后的第一个提交中。

我知道我可以使用 rebase 交互地执行此操作，但我不想交互，只需触发命令即可。

我已经使用Git Extensions有一段时间了（太棒了！），但我还没有找到以下问题的简单答案：

有时，在输入提交信息时，会出现拼写错误。我的朋友向我展示了如何通过以下方式修复它（在 Git 扩展中）：

右键单击提交 > 高级 > 修复提交

然后我只需选中“修改”框并重写我的信息，瞧！我的提交信息是固定的。

然而，另一个选项“Squash commit”......我一直想知道它的作用是什么？！

我的问题是：

有人能简单地解释一下Git/Git 扩展中的Squash 提交和Fixup 提交之间的确切区别是什么吗？他们看起来有点……和我“相似”：

我的 git 对象图如下所示。我想将提交、、、2fb14b7和39224ad压缩fe9252d到3e7a060一个提交中。

以下是我尝试过的（但不明白为什么它不起作用）。

Q1。为什么这不是壁球？

Q2。这对我的存储库有什么影响？

我在 branch_A 上工作并将其合并到 branch_B （都是本地分支）

1. 在 branch_A 中压缩提交是一个好习惯吗？
2. 如果我要将 branch_A 推送到公共 repo 并且我的主人将来会获取它怎么办？

我正在使用 git flow 方式来管理我的仓库中的分支，如下所述： http: //nvie.com/posts/a-successful-git-branching-model/

因此，我应该使用的命令序列如下：

但是，在某些情况下，我想做不同的一件事：

我想在我的功能分支 ( mybranch) 上保留我的所有提交，但在合并到develop.

所以这就是我认为的命令序列应该是：

--no-ff如果我要与 结合，我会做错事--squash吗？

我犹豫要不要尝试这一点，因为“压缩”和“保留历史”是正交要求 - 请参阅将我的所有提交（包括合并）压缩到一个提交中而不改变历史

我的理由是我想在一个分支 () 上保留历史记录mybranch并在另一个分支 () 上保留 suqash develop--> 因为这些操作是在单独的分支中执行的，所以可以。

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

所以我们有一个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：将来自另一个分支的所有更改合并为单个提交

对我们来说，一个常见的开发工作流程是检查分支b，向它提交一堆，然后将所有这些提交压缩成一个（仍然打开b）。

但是，在rebase -i压缩所有提交的过程中，经常会在多个步骤中发生冲突。

我本质上想将分支更改为一个提交，该提交代表最终提交时存储库的状态b

我已经进行了一些搜索，但我没有找到我正在寻找的确切内容。我不想这样做，merge --squash因为我们想在合并之前测试压缩的特性分支。

我与一个使用“合并工作流程”的小团队合作，我们最近根据Sandofsky 的文章切换到了“rebase 工作流程” 。

我们当前的工作流程：

1. git checkout master, git pull origin master
2. git checkout -b feature_branch，做一些工作和 git commit -am "msg for feature branch"
3. git checkout master, git pull origin master, git rebase master feature_branch
4. git checkout master, git merge --squash
5. git commit -am "msg for master branch", git push origin master

在 rebase 特性分支之后，我们将其压缩并合并到我们的 master 中。如果我们改用 --no-ff 会发生什么？git merge --squash和 和有什么不一样git merge --no-ff？

当我在分支中压缩提交时（使用 git rebase -i），我总是对压缩的提交与旧提交而不是新提交相结合感到恼火。

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

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

我做了一堆提交，我应该只有一个。最近的提交是我想要推送的提交，但我需要将其全部压缩为一个提交。当我尝试时，rebase -i我必须处理大量的合并冲突。

有没有办法将提交压缩成一条消息，同时将代码保留在最近的提交中？

基本上，如果有冲突，我只希望最近的承诺每次都能获胜。我该如何做到这一点？