问题标签 [git-squash]

我在功能分支上工作了几天，现在可以合并到dev. 在开发此功能时，我已合并dev以接收补丁。我的历史是这样的：

我想将整个分支压缩成一个提交，合并dev然后快进dev。问题是，当合并发生在它们之间时，E不能被压扁。C唯一的选择似乎是 squash E，B并且C（调用新的 commit F），在这种情况下，被压缩的提交还将包括作为不相关补丁一部分的更改。一旦合并到dev中，将有两个应用补丁的提交：（F应用补丁并添加功能）和B（仅应用补丁）。此外，F现在将进行两个不相关的更改。

有没有办法让我的历史保持干净整洁？我需要改变我的工作流程吗？

我遵循传统的提交标准，我想制作一个 shell 函数来执行压缩，并使用解析的消息合并和提交更改，从而提高我的编码速度和我的提交一致性。

我的问题是解析参数，然后在提交消息中使用结果。

• 我的实际代码：

  /li>

• 使用示例：

  /li>

• 预期结果：

  /li>

您可以猜到，在我的实际代码中，我的注释echo准确地打印了我想要的消息。但是git commit -m命令$msg作为一个字符串。我尝试了多种其他选项，例如使用标志模拟文件输入-F，但我无法解决。

我怎样才能实现我的目标？先感谢您。

我一直在努力让我的团队的 git 工作流程变得简洁明了。我们的团队为我们的构建服务器使用master、staging和分支。development

当一个新的任务/功能正在处理时，我们将首先从 master 创建我们的功能分支，根据需要将其提交多次，然后使用临时分支将其全部压缩为 1 个提交并将其移动到任何一个 staging或发展。

考虑这个基本图：

在这里，我们看到所有分支的起始位置排成一行。每个功能的提交都是隔离的并保持在一起。当特性移动到上游时，特性的提交被压缩，然后合并到上游分支。例如，将功能移至开发将意味着：

这在短时间内运行良好，直到我在挤压时遇到第一次冲突。我不确定更改是在哪里进行的，以及为什么 git 不能自动使用历史记录来解决它。这是一个非常基本的输入/输出交换。

我的问题是：有没有更好的方法来做到这一点？我们希望将我们的代码合并到 dev/staging 中，每个特性分支 1 次提交，而不会在开发测试时破坏/弄脏特性分支（将未经批准的代码从 dev 重新定位到特性分支将包括合并到 staging 分支时的那些更改）。

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

我分叉了一个回购，做了一些改变。加班，我也用过git fetch upstream几次git merge upstream/<branch>。有时，我解决并重新测试了一些冲突。

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

我不明白的是，我不得不再次处理冲突解决方案。我不明白为什么当我的叉子与它的起源是最新的时我需要解决冲突。我本可以对所有修改过的文件进行备份，对我的 fork 进行核对，再次 fork，恢复备份，我将没有冲突需要解决并准备好提交。这个过程似乎很机械，我不明白为什么我必须走艰难的路（再次解决冲突）。

有人可以帮我理解吗？

假设我在本地分支 A 上有以下提交，然后我将其推送到远程分支。

现在，我从远程主机拉出，提交历史看起来像这样 -

如果我现在想使用 git rebase -i 和 git push -f 压缩提交 2 和 3，那是否也会重写提交 5 和 6？如果是，有没有一种方法可以在不重写我从主分支中提取的提交的情况下压缩我之前的提交？我是 Git 新手，所以如果我遗漏了一些非常基本的东西，请见谅。

我在这个分支和屏幕上有一个分支功能/安装新功能，并且有 11 次提交。但是所有提交都合并了提交。计划做一个壁球这些提交。

我在日志历史记录中有合并提交的列表，需要压缩成一个提交。

但我做了一个git rebase -i branchname它显示这样的输出。我无法将其压缩为提交。输出是这样的

我如何使用上述提交来处理壁球。

我通常从不这样做，但这次我完成了一个功能分支，出于更新目的，将 master 合并到其中（我通常倾向于在我的功能分支上重新设置 master 以避免无用的合并提交）。

现在我想将我的功能分支的所有提交压缩为一个，然后将其合并为最终确定的 master，但它不像通常那样无缝。

我怎样才能做到这一点？

我正在处理本地化，这是一个迭代 40 多个分支的过程，每个分支实现大约 40 次提交。其中一些（假设是一半）对于几乎所有分支都完全相同。因此，我开始将提交 ID（如 085cfefc9291b）复制到记事本中，然后在我希望在当前分支上实施这些更改时从该列表中挑选。

我的提交列表 cherry-pick（例如git cherry-pick 290d953c2837）：

• 290d953c2837 --> 产品矩阵更新 (2017-02),
• 9ee8c001165e6 --> 结果和收益的 Jsonify (2017-02)
• 13156cee10d --> 实现产品系列的双后端/前端
• 80c98c492 --> 切换后端过滤
• 15106bdc --> 在包中包含椭圆形 (fusion2)
• 085cfefc9291b --> 从前端排除产品范围

这些提交来自同一存储库的不同分支。

真正适合我的工作流程的东西是一种将这些提交捆绑/压缩到一个提交中的方法。这将使我能够在此过程中动态创建补丁，如果我保留一长串单独的提交，我可以轻松创建不同版本的补丁，其中一些提交更多，一些提交更少。

您对此了解哪些最佳实践？

我的团队喜欢有一个“干净”的 git 历史记录，并且喜欢在我请求代码审查之前将提交压缩。这个工作流程的一个方面我遇到了麻烦：

在审查期间，我想继续工作feature-branch-2（这取决于 中的内容feature-branch-1） 。feature-branch-1所以：

git checkout -b feature-branch-2 feature-branch

feature-branch-2在我工作时添加一些提交。

代码审查评论回来了，所以我添加了一些提交来feature-branch-1回应他们。然后我压缩这些提交，并再次发布以供审查。

但是现在我遇到了一个问题：我如何轻松地feature-branch-2更新对 的修复feature-branch-1？如果我没有 squashedfeature-branch-1的提交，这将是一个简单的合并，但我不确定使用 squashes 的简单工作流程是什么。

在制作拉取请求之前，我正在阅读有关在 Git 中压缩提交的优缺点。我没有找到有关信息的是，如果其他拉取请求被合并到主请求中，而相关拉取请求被推迟，则带有压缩提交的拉取请求是否或多或少可能会变成合并冲突。我可以想象不同的场景：

• 通过大量的小提交，合并工具可以更容易地判断事物如何属于一起并且合并冲突的可能性较小。“合并冲突”可以“解决”成更小的单元，如果逐个考虑，这些单元不会发生冲突。
• 对于很多小的提交，合并工具可以认为中间提交已经不可合并，即使以后的提交会修复它。（感觉有点奇怪。）
• 从技术上讲，它没有任何区别，因为无论如何合并工具只会查看最后一次提交。

哪一个是真的，还是事情更复杂？（比如，取决于变化的种类？）