问题标签 [git-rebase]

我一直在阅读git merge和git rebase操作的工作原理，我认为我对这些差异有一个非常基本的了解。我已经看过这些图表 :-) 尽管如此，我仍然不清楚在我当前的工作流程中使用哪一个最好。

我的工作是使用perforce，因为它是 SCM 系统，但我在本地使用git来跟踪本地更改、进行重构以及 git 可以带来的其他一些很酷的东西。我知道已经存在一个工具来帮助使用 git 和 perforce（例如 p4-git），但我不一定想要/需要这种开销，所以我试图让事情尽可能简单。以下是我当前创建本地 git 分支并最终集成回我们的主要 perforce 仓库的工作流程的简要说明：

1. 我有一个主git 分支，它每晚对我们的代码库进行 p4 同步。在 perforce 同步之后，我将所有更改提交到 master 分支。实际上，我的主git 分支本质上是提交到我们的 perforce 主线的最新代码的快照。

2. 对于我正在进行的本地更改，我总是先创建一个git 分支，然后在进行更改时 签出这个分支。

3. 时不时地我想将我的分支更新到master的最新版本。到目前为止，我刚刚发出git merge master命令来执行此操作，并且运行良好。

4. 当我准备好提交到实际的 perforce 仓库时，我通过签出master并发出git merge BRANCH然后将我的分支合并回我的master分支，然后使用常规 perforce 命令提交

鉴于我的工作流程，我真的应该为 Step#3 使用git rebase master命令而不是git merge master吗？根据我对rebase命令的理解，这只有在我们的perforce 主线（远程仓库）被分支时才有必要，并且我想基于这个分支创建一个新的master（比如我称之为 master-newbranch）并应用我的更改到这个新的分支。我需要先从这个分支 变基吗？

总的来说，我目前的工作流程是否有意义，或者我已经养成了一些坏习惯？

我已将 2 个提交（A 和 B）压缩为一个新的提交（C）。前两个提交（A 和 B）被删除。我将这些提交从我的开发存储库推送到中央（裸）存储库。两个 repos 上的git-log确认提交 A 和 B 已被删除。问题是当我对已经拥有（A 和 B）的第三个存储库进行拉取时，它现在拥有所有三个提交（A、B 和 C）。

我原以为拉动会同步这些更改。我需要签出 A~1 然后合并新的更改吗？这似乎很麻烦，尤其是在生产环境中。

我想删除中间合并（删除，而不是 squash），然后将最后 2 个提交移动到新分支。

这是我目前的git log --graph：

我想结束这个：

我想用git rebase -itade 删除与分支的合并，然后执行 agit branch newone并将git reset --hard HEAD^2最后 2 个提交移动到新分支。但是，当我进行 rebase 时，它​​向我显示了来自 tade 分支的所有提交，这些提交合并到了 master 和 | 不愿意删除它们。

有没有更好的方法或者我应该继续它？

编辑：我更新了预期的状态图以使其更加清晰。2个新的提交（aaaaaaa和bbbbbbb）只是为了更好地说明状态（我希望）

我在 master 上犯了错误并提交了开发更改，并将它们推送到上游。从远程仓库中撤销这些更改的最佳方法是什么，但在本地保留一个分支以供以后合并到 master 中？

举个例子：

我在主题分支中有一些工作，现在我准备合并回 master：

我从 master 执行合并，解决冲突，现在我有：

现在，合并花了我一些时间，所以我再次获取并注意到远程主分支有新的变化：

如果我git rebase origin/master从 master 尝试，我将被迫再次解决所有冲突，并且我也会丢失合并提交：

有没有一种干净的方法来重新合并提交，所以我最终得到了如下所示的历史记录？

我知道如何从命令行执行 git rebase，但是您如何使用官方的git-gui执行此操作？

我正在尝试一个

从我的远程存储库添加最新的 21 个提交。

git 告诉我的是存在冲突——但这怎么可能呢？

据我了解，它只是将 21 次提交应用到我的主人之上。怎么会有冲突？

感谢帮助！

顺便说一句，我这样做是因为不知何故我搞砸了我的 git-svn 存储库（远程），并且有 21 个提交我无法提交到颠覆。所以我正在尝试一个新的 git-svn 克隆，我在其中添加了这 21 个提交。

在 rebase 一个我几周没碰过的特性分支之前，它比 master 提前了 25 次提交。变基后，现在是 18 次提交。在此过程中，我必须解决几个冲突。可能正好是7。

什么可能导致这个数字变化？沿途发现并变成 NOOP 提交的樱桃精选？上述冲突解决方案？

这是我尝试将我的错误修复分支合并到我的主分支以准备将其推送到上游的成绩单。自从 bugfix 分支创建以来，已经有一些上游更改被拉入 master，现在它拒绝 rebase。

它引发错误的文件在打开时没有差异。没有文件被添加、删除或重命名。没有任何东西被忽略，也没有任何东西是未跟踪或暂存或未暂存的。我完全不知道为什么 rebase 失败了。

我在 OS X 10.6.6 和 git 1.7.4

我想在我的主人之上应用一个小的主题分支（在贡献者的远程仓库上）。我认为这样做的规范方法是：

但我想让提交一个接一个地应用，而不是生成一个合并提交。

天真的运行git rebase contributor/topic-branch显然是行不通的，因为它将我的主应用到主题分支上，就好像主题分支是我的上游一样。所以我尝试了这个：

这就是我想要的，除了现在我有一个分离的 HEAD，我需要修复 master 分支以指向 HEAD（使用branch -f）。我当然可以编写一个 Bash 函数来自动执行此操作，但是是否有一种“正确”的方法可以在不使用的情况下拉入主题分支merge？