标签: git-squash

我已经阅读了一些有关--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？

I use an optimistic work-flow in Gitlab, which assumes the majority of my merge requests will be accepted without change. The flow looks like this:

1. Submit a merge request for branch cool-feature-A
2. Create a new branch, based on cool-feature-A, called cool-feature-B. Begin developing on this branch.
3. 一位同事批准了我的cool-feature-A.
4. 我cool-feature-B反对master（这是无痛的）并继续开发。

如果同事在第 3 步进行壁球合并，就会出现问题。这会重写cool-feature-B. 当我到达第 4 步时，我面前是一个合并痛苦的世界。

我怎样才能避免这种情况发生？

我有以下场景：

• 主分支：生产中的内容，可以包含修补程序
• Develop-branch：我的开发人员用来创建拉取请求的分支
• 功能分支：我们为开发人员正在实现的功能创建的分支。

开发人员完成工作后，他会在开发分支上创建拉取请求。批准后，我们​​将功能分支压缩合并到开发分支，以便不包括开发人员在功能分支上所做的所有提交。这使我们能够在开发分支上拥有清晰干净的 git 历史记录。

有时功能分支需要从 develop 分支变基，这就是麻烦的开始。

如何避免这种情况，以便 PR 仅包含来自功能分支的实际提交？

我们可以压缩 中的最后 N 次提交Git。据我了解，我们可以使用git rebase -i HEAD~Nor压缩最后 N 次提交git reset --soft HEAD~N。

在这个问题的答案中（使用 Git 将我的最后 X 次提交压在一起）最受好评的答案建议是使用git reset --soft HEAD~N，但这不是被接受的建议。接受答案建议git rebase -i HEAD~N。因此我很困惑，更喜欢使用哪一个。

这些方法有何不同？推荐使用哪一种或安全使用哪一种？

我的团队正在开发一个长期运行的功能分支，它现在有数百个提交，现在我需要将它合并到 master 中以进行生产发布。

我不想在那个分支中有那么多提交，因为许多提交是为了修复错误而完成的，并且每次提交只更改几行。

在 Github 上的 PR 创建页面上，它限制了显示为 250 的提交。

来自 Github - “这个比较很大！我们只显示最近的 250 次提交”

因此，我决定以一种将作者的一组顺序提交压缩为单个提交的方式压缩历史记录。

例如，假设我们有这样的提交：A - A - A - B - B - A - C - D - D - B- B -A来自作者 A、B、C 和 D，那么生成的提交日志将有 A (3) - B(2) - A - C - D (2) - B(2) - A，其中 X`(N) 是 N 个提交的压缩提交来自作者 X。

编辑：我知道这将需要一个脚本，我正在寻找相同的。我不想通过交互式 rebase 来做同样的事情。

1. 我有另一个repo @github的分支.
2. 做了一些代码并向上游发出了拉取请求
3. 上游主人与壁球选项合并
4. 现在下一个pull请求包括新代码和旧提交.所以他们越来越多了.

我该怎么办？

• repos在代码方面完全同步
• 顶部的github徽章显示我的fork是xx提交在上游之前
• 我试图将上游合并到我的仓库(没有效果,因为它们是同步的)
• 我不确定rebase是否有帮助,但有我的提交和其他人的提交.所以那里很乱,我不知道该怎么做.

假设我已经开发了一个功能,branch1并使用Gi​​tHub Pull Request将其发送出去进行代码审查.在进行审核时,我会做一些后续工作branch2.

 branch2                   -> D --> E --> F
                          /    
 branch1  -> A --> B --> C
         /
 master M

我的评论家喜欢我的作品!无需更改.我合并了branch1使用GitHub的Squash和合并功能的pull请求.

运行后git pull的master和删除branch1,我留下了这样的情况:

 branch2  -> A --> B --> C -> D --> E --> F
         /
 master M --> S

为了发送一个看起来干净的PR branch2,我想让我的提交树看起来像这样:

 branch2        -> D' --> E' --> F'
               /
 master M --> S

S(由"Squash and merge"生成的提交的代码branch1)是相同的C,因为它只是被压缩的版本A …

我正在从上游分叉的git存储库上工作。有一个我想实现的功能，我创建了一个新的分支uiTests并在那里进行了更改并提出了拉取请求。

公关在那里呆了一段时间，与此同时，还有其他一些公关被合并并发生了冲突。我用叉子解决了它们，最后有两个合并提交。

当我检查git日志时，列表的顶部看起来像这样；

commit 70db4de884d5e4b64ef3a2c903f310c901dd68e2
Merge: ef5dfc2 5b7a827
Author: Padmal
Date:   Sat May 26 18:53:33 2018 +0530

    Merge branch 'CloudyPadmal-uiTest' into uiTests

commit 5b7a827763c35a3605daed6c717004700582eede
Merge: e815867 ef5dfc2
Author: Padmal
Date:   Sat May 26 18:52:52 2018 +0530

    Merge branch 'uiTests' of git://github.com/CloudyPadmal/pslab-android into CloudyPadmal-uiTest

commit ef5dfc2f4af7431b2bc5efa356540bd616669706
Author: Padmal
Date:   Thu May 24 20:06:27 2018 +0530

    test: removed Travis build time consuming UI tests

    removed dummy test files

所以我想压扁70db4de884d5e4b64ef3a2c903f310c901dd68e2并5b7a827763c35a3605daed6c717004700582eede在ef5dfc2f4af7431b2bc5efa356540bd616669706和一个提交更新PR。

有关更多信息，git log --oneline结果如下： …

我从远程存储库克隆了一个分支：

git clone -b feature/feature1 http://.....
git status
    On branch feature/feature1
    Your branch is up to date with 'origin/feature/feature1'
    nothing to commit, working tree is clean

现在我试图用来git rebase -i压缩最后两个提交：

git rebase -i HEAD~3

pick ...
pick ....
squash ...

但是，我收到此错误：

error: unable to unlink old 'file1': No such file or directory
error: unable to unlink old 'file2': No such file or directory 
error: unable to unlink old 'file3': No such file or directory
hint: Could not execute the …

假设我有以下git的历史：一个主分支开始犯A，一个feature-1分支分支的关闭A与提交B和C，第二特性分支feature-2所建立起来的承诺关闭C与提交D和E。

master     A
            \
feature-1    B--C
                 \
feature-2         D--E

现在假设提交C已经过测试并准备好合并，所以我们使用git switch master; git merge feature-1 --squash.

master     A------C'
            \    /
feature-1    B--C
                 \
feature-2         D--E

master 的历史记录很好而且干净，只有提交A和C'，但是如果我们现在想要比较master和feature-2（例如，git log master..feature-2），我们最终会看到所有提交feature-1都已经合并了。

问题 1：是否有一种简单的方法可以feature-2压缩历史以匹配压缩的合并？如果什么历史是一个有点复杂，它的分支点后有更多的提交C上feature-1那名壁球合并成高手？

问题 2：假设重写历史很困难（或者只能用 很乏味地完成git rebase -i；我在每个分支上有两个以上的提交），有没有办法只查看 …