标签: git-rebase

我当时在一个名为 的功能分支中工作auth+menus，下面是我需要帮助尝试恢复的事件和操作的顺序。我担心我会失去所有的工作，我希望我是错的。

git commit -m "code changes"

git commit -m "more changes"

git rebase -i HEAD~2

git checkout master

git pull upstream master

git checkout auth+menus

git rebase master

git rebase --continue存在单一冲突

git rebase --skip

git add --all

git commit -m "some of these files should have already been committed"

git push origin auth+menu

git push origin auth+menu -f因为我是个白痴...

我希望我没有完全失去前两次提交中的所有内容，我真的需要有人的帮助！有没有办法从中恢复并获得我原来的两次提交？

按照本指南，我通过删除历史上的一些重文件来缩小我们的项目存储库。这意味着 git 历史已经改变。但现在的问题是，我的其他团队成员如何在不丢失他们对当前不在远程的分支上所做的更改的情况下获得我们的 repo 的新缩小版本，并且也不会推回已删除的历史记录。

作者建议 clone 或 rebase：

拥有存储库本地克隆的任何其他人都需要使用 git rebase，或者创建一个新的克隆...

新的克隆意味着放弃任何团队成员在本地所做的所有更改。因此，rebase 似乎是更好的选择。但是我们该怎么做呢？

我在想这样的事情：（假设 master 是新功能分支的基础分支，开发人员机器上的本地分支有新工作，并且 master 受到历史重写的影响）：

$ git checkout master
$ git fetch origin
$ git pull --rebase
$ git checkout new-feature
$ git rebase master

确认一切正常然后

$ git push origin

我们遇到的问题是我们有我们的主development分支。我们有一张票，它依赖于多张票才能进入development分支。所以可以说 ticketA依赖于 ticketB并且C为了被合并到development.

我们一直在处理这个问题的方法是使一个A分叉的development再分支B和C关闭的A。问题是我们想要将 development 的更新带入A, B，C并且我们还想将更新从Binto 带入C，反之亦然。git rebase当有人在从 中进行更改后进行git push --force了Arebase时，我们如何在不让每个人都删除其本地 A 分支的情况下使用它来执行此操作development？

我看到有之间的连接rebase和cherry-pick一系列的提交。

我没有找到任何文章/教程来解释当一个人尝试cherry-pick多次提交时究竟发生了什么。

一些问题（我能想到的）是：

1. 什么是CHERRY_PICK_HEAD参考？
2. 通过运行git cherry-pick 2^..4，git 执行的操作序列是什么以及git 使用的提交之间diff究竟是什么？

3. 通过运行git cherry-pick 1..8，git 会做什么？

说我有这个：

A - B - C - E - F    [integration]
 \
  G - H - I          [feature]

在 commit 之后I，我们通过集成进行变基：

git fetch origin
git rebase integration

所以现在我们有：

A - B - C - E - F    [integration]
 \
  B - C - E - F - G - H - I          [feature]

然后说我们将功能分支合并到集成中，然后我们有：

A - B - C - E - F - G - H - I   [integration]
 \
  B - C - E - F …

我最近开始使用 git 树和临时索引文件来构建提交，而无需修改我的工作目录，目的是自动化一些任务。最终目标是有效地重新设置某个分支（例如feature/x_y_z在 之上main），但不修改工作目录来执行此操作。显然，我仍然想检测冲突，并且绝对不是破坏性的更改main（就像使用git commit-tree）。我通读了这本书的“Git Internals”一章，它对树、blob、索引等很有教育意义——但没有明确解释 rebase 是如何工作的。

（旁白：这样做的动机是1）它的方式更快，2）我想使开发人员能够揭开序幕测试设置一些提交/支，迅速，消费最新规范的更改，而不是他们的重挫工作目录）。

为此，git rebase引擎盖下是如何工作的？它使用哪些管道命令？它如何分析树以检测冲突？指向有用资源的链接和/或对这些内容的直接解释将非常有帮助。

我的 Git 存储库如下所示：

我创建了 2 个分支 - Branch_1 和 Branch_2。现在我终于准备好将此 Branch_2 合并到 Master 分支中。但是当我合并时，它显示了 Branch_1 和 Branch_2 的所有提交，因为中间有多个合并。任何人都可以建议如何在这种情况下继续进行一次提交，然后将我的代码合并到主分支吗？

git log --oneline --graph --color --all --decorate

* 36dbb26 (origin/Branch_2) changed abc
* 1a7bf25 changed T
* 110095a changed Z
*   1087d5d Merge remote-tracking branch 'origin/Branch_1' into Branch_2
|\
| * 8c9d02a (origin/Branch_1) sleep added between each processing to discover partitions
| * ca401cb changed S
| * 20a4edd changed R
* 3f472ef install package
*   1087d5d Merge remote-tracking branch 'origin/Branch_1' into …

我理解，一般来说，git rebase -i并且git reset用于非常不同的事情。

但是在删除最近的 N 次提交的情况下，在我看来它们是（或可以是）相同的。我什至做了一个实验（我的存储库有两个不同的本地副本），据我所知，它们是相同的。我只是发布这个问题，以防有人可以指出我可能遗漏了什么。所以这就是我所做的。

我需要删除最近的 11 次提交（不管为什么）。

我尝试了两种方法，它们看起来完全相同；只是想知道我是否遗漏了什么，因为它们并不完全相同：

1. git rebase -i HEAD~12

• 从我不想要的 11 个提交中删除提交行，只保留它们之前的提交（交互式 rebase 文件顶部的那个）。
• 变基成功