0

我不是，也永远不会是git专家，所以请温柔一点。

我有一个 PR 分支——Github 告诉我——假设它有 12 个提交。

虽然我一直在处理这个 PR，但我已经将master（它最初分歧的分支）合并到其中几次。我计划在此 PR 被接受和合并之前将所有提交压缩为一个。

我知道我会用git rebase -i它来做这件事。这个问题的一般领域是如何提出提供给这个命令的参数。

鉴于从master我的 PR 分支等的合并等git merge-base，我不认为，我不认为，正确的 SHA 可以作为参数提供给git rebase -i. 事实上，它会给我从 中“过来”的最新提交master，而不是我的分支“开始”的最早点。

当然，我已经阅读了这个出色的答案。它的“shell magic”答案有效，但我并不完全理解它，而且我不喜欢依赖我不理解的魔法。

因此，我的问题是：从我的 PR 分支中，我是否可以改为使用这个相对简单的命令： Github 告诉我的分支上的提交次数在哪里git rebase -i HEAD~12？12

（当然，在所有这些中，我假设我已将push本地分支编辑为 my origin，即我的本地笔记本电脑上的分支与我的 Github 托管的origin分支相同。这个假设隐含的是，如果 Github 说 12提交，那么我的笔记本电脑上的分支也应该正好有 12 个提交。）

~在波浪号 ( )之后可以提供这个提交数量吗？这是一个可靠的、相对容易脑残的事情吗？还是我会在另一个难以理解的git选择或约定上绊倒自己？

4

1 回答 1

1

我找到了这个很好的例子，它准确地回答了我的问题。具体来说，它解决了对提交计数以及指定应提供给git rebase -i. 它部分说：

该命令的一个缺点git rebase --interactive HEAD~[N]是您必须通过逐个计数来猜测提交的确切数量。幸运的是，还有另一种方法：

git rebase --interactive [commit-hash]

在您要重写的第一个提交之前，提交[commit-hash]的哈希值在哪里。所以在我的例子中，命令是：

git rebase --interactive 6394dc

6394dc在哪里Feature Y。您可以将整个内容阅读为：

Merge all my commits on top of commit [commit-hash].

更容易，不是吗？

我的主要问题是试图找到[commit-hash]. 现在我知道它不是“我的一个”，而是早于我的那个。

于 2019-04-19T01:33:33.180 回答