Question

我正在使用的别名

alias cm='git checkout master'
alias com='git add . ; git commit -m'
alias gb='git branch'
alias gc='git checkout'
alias gl='git log'
alias graph='git log --graph --all --decorate --oneline'

我的脚步

git init rebase-test
cd rebase-test/
echo "master file 1">file1.txt
com "master add file1"
gc -b feature-1
echo "feature-1 file 2">file2.txt
com "feature-1 add file 2"
echo "master file 3">file3.txt
com "feature-1 add file 3"
cm
echo "master file 4">file4.txt
com "master add file 4"
echo "master file 5">file5.txt
com "master add file 5"

```

然后我检出Feature-1并重新设定基准

gb feature-1
git rebase master

这是我登录时得到的输出

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



* 2f0e025 (HEAD -> feature-1) feature-1 add file 3
* ae4921b feature-1 add file 2
* 3e72852 (master) master add file 5
* 859afc0 master add file 4
* becc58d master add file1

然后将文件添加到master分支并再次提交后，我得到git log --graph --all --decorate --oneline的输出

* 3a55d83 (HEAD -> master) master add file 6
| * 2f0e025 (feature-1) feature-1 add file 3
| * ae4921b feature-1 add file 2
|/  
* 3e72852 master add file 5
* 859afc0 master add file 4
* becc58d master add file1

这就像还原了基准。我希望主分支保持线性.. 那么，重新设置基准点是什么呢？

Answer 1

...那么变基点是什么？

git rebase的重点是复制提交，然后放弃原始文档，转而使用新副本。它本身并不是特别有用，但是会带来一些后果，可能以后会有用。

请注意，具有原始（复制前步骤）提交的任何 other 存储库仍具有那些原始提交，并且还没有新的提交。将制作副本的存储库连接到某个预复制存储库，通常会导致两个Git combine 组合两组提交，因此您既拥有pre- 又拥有复制后提交，可以随时使用。然后将git merge放在两个集合中太容易了。这导致人们可以在此处使用一条通用规则：尽量不要为已发布提交重新设置基础。

（该规则有一个更复杂的版本，其内容为：确保在对发布的提交进行基础（即复制）之前，确保将要处理这些提交的所有各方都了解如何以及为什么要对副本进行基础提交，以及如何处理后遗症。请注意，最近的Git版本使用--fork-point和git rebase都可用的git merge-base选项自动处理其中的一些问题。仍然最好确保每个人都同意这一点，并了解其工作原理。）

在重新设置基准之前，我们没有来自{em> 的git log --graph --all --decorate --oneline输出。（如果重复我的命令，我将获得所有新的哈希ID，因为哈希ID编码提交作者的姓名，并且的时间一直到第二个。）从此以后，我们有了这个： >

* 2f0e025 (HEAD -> feature-1) feature-1 add file 3
* ae4921b feature-1 add file 2
* 3e72852 (master) master add file 5
* 859afc0 master add file 4
* becc58d master add file1

请注意哈希ID。这是我之前的猜测：

* 3e72852 (master) master add file 5
* 859afc0 master add file 4
| * XXXXXXX (HEAD -> feature-1) feature-1 add file 3
| * YYYYYYY feature-1 add file 2
|/
* becc58d master add file1

请注意个不同的哈希ID，以及YYYYYYY的父代是becc58d的事实。

这意味着，在重新定位之前，中存储库中的提交历史记录以：

结尾

提交3e72852：对master的最终提交
提交XXXXXXX：对feature-1的最终提交

从这两个最终提交中，我们（和Git）可以向后工作。完成后，我们将从任一起点分两步到达becc58d。因此becc58d是两个分支上的最后一个公共共享提交。

如果我们让每个提交都用单个字母表示，并在左侧绘制较旧的提交而在右侧绘制较新的提交，则横向绘制图形，我们将得到以下图形：

  D--E   <-- master
 /
A
 \
  B--C   <-- feature-1 (HEAD)

一旦变基完成，我们就会得到：

        B'-C'  <-- feature-1 (HEAD)
       /
A--D--E   <-- master
 \
  B--C   [abandoned, but see the reflog for feature-1: `feature-1@{1}`]

也就是说，在没有特殊双筒望远镜的情况下，提交B和C不再可见（尽管您可以使用git log --all --graph --decorate --oneline feature-1@{1}来查看它们），但是新的副本B'和分别具有哈希ID C'和ae4921b的{{1}}是可见的，并且可以通过在2f0e025指示的位置开始并向后工作来找到。

两个分支feature-1和feature-1上的最新提交现在为master，在侧面图中标记为3e72852的提交。从这里回到E的所有三个提交都在两个分支上。

在becc58d上进行新的提交3a55d83时，这只会扩展master。让我们将其作为提交master：

原始提交B'-C' <-- feature-1 / A--D--E------F <-- master (HEAD)和B可能仍在其中（默认情况下它们将至少保留30天），但是由于很难看到它们，我们可以停止绘制它们。

如果您希望C跟在提交feature-1之后，则必须再次重新设置基准，以便将提交F复制到B'和B"到C'。 C"的父级将是B"，而不是F，而E的父级将是C"。

如果我在git rebase后承诺掌握，会发生什么

我正在使用的别名

1 个答案: