我不是，也永远不会是一个git专家，所以要温柔。
我有一个PR分支，它有-Github告诉我 - 让我们说12个提交。
虽然我一直在研究这个PR，但我已经将master（它与原来分开的分支）合并了几次。我计划在接受并合并PR之前将所有提交压缩到一个。
我知道我将使用git rebase -i来做到这一点。这个问题的一般方面是如何提出供给这个命令的论据。
鉴于从master到我的PR分支等的合并，git merge-base并没有给我，我认为，正确的SHA作为git rebase -i的参数提供。事实上，它会给我最近的来自master的“承诺”，而不是我的分支“开始”的最早点。
我当然读过this excellent answer。它的“贝壳魔法”答案有效，但我并不完全理解它，我不喜欢依靠魔法我不明白。
因此，我的问题是：从我的PR分支，我可以使用这个相对简单的命令：git rebase -i HEAD~12，其中12是Github告诉我的是我分支上的提交数量？
（我假设所有这些，当然，我有qazxswwied我的本地分支到我的push，即我的本地笔记本电脑分支与我的Github托管的origin分支相同。这个假设隐含的是，如果Github 12个提交，然后我的笔记本电脑分支也应该有12个提交。）
在波浪号（origin）之后，这个提交数量是否可以提供？这是一个可靠的，相对容易死脑的事情吗？或者我会在另一个不可思议的~选项或惯例上绊倒自己吗？
我找到了git，它完全回答了我的问题。具体来说，它解决了对提交进行计数以及指定应提供给this wonderful example的提交哈希的需求。它部分说：
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].
。现在我知道它不是“我的一个”，而是一个早于我的。