Question

另一个功能分支的提交历史记录是否会继续显示在新功能分支中？为什么是这样？

我唯一能想到的是，我需要在签出新功能分支之前结账git log: Rebuilt for deployment，但我非常怀疑这是否真的有必要。

发生以下情况：

git status On branch john-cleanup Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: some-file.jsx

git commit -m "Remove some-file"

git log Remove some-file last-feature-branch-commit another-different-feature-branch-commit ...

// assignments
var a = 2
// if/else statement and condition expression
if a == 2 {
  // print function and strings
  print "a == 2"
} else {
  // halt program with status code
  halt 1
}

Answer 1

Git的分支和提交概念与大多数其他版本控制系统非常不同，甚至是像Mercurial这样的分布式版本控制系统。如果你期待这种行为，你会被Git吓到。

在大多数VCS中，当您进行提交时，将其设置为在分支上，从那时起，该提交就是该分支上的。这似乎很明显。这不是Git所做的。

在Git中，当你进行提交时，你可以在一个分支上，或者根本不在任何分支上（Git称之为“分离的HEAD”）。提交像往常一样进入存储库。如果在分支上，那么 - 通过Git对“在分支上”的定义 - 分支名称，例如master，标识当前提交（ HEAD或@），这必然是该分支的提示：

...--E--F--G   <-- master

（其中每个字母代表一些提交哈希ID）。您创建的新提交将成为master的新提示，并且名称master将更改为指向新提交：

...--E--F--G--H   <-- master

您仍然是on branch master，正如Git所说，但现在master名称提交H。

但名称本身意义不大。您可以将Git重新指向master，例如，提交F。提交G和H已不再是master！它们仍然是在存储库中，但不再是分支的一部分：

...--E--F   <-- master
         \
          G--H

他们确实需要某些名称（分支或标记名称）才能找到它们，否则它们最终会被垃圾收集。

同样适用于合并：一旦有合并提交使某些其他提交可以访问，那些提交的所有都在分支上。例如，如果我们改为：

...--E--F--G   <-- master
      \
       H--I--J   <-- develop

然后将develop合并到master，我们得到一个新的合并提交，它链接回提交G和J：< / p>

...--E--F--G---K   <-- master
      \       /
       H--I--J   <-- develop

现在，以前所有三个 - develop - 仅提交都在两个分支上。因此，在git log上运行master会向您显示所有这些提交。

（请注意，提交E以及之前的任何提交，也在两个分支上，甚至在合并之前。提交F，G ，K现在develop上的develop 不，但如果名称K更改为指向develop，则将是此时在git log --oneline --graph上。）

您可能希望查看提交日志 with 提交图表的表示，例如git log --all --decorate --oneline --graph或{{1}}。（或者，大多数图形查看器和GUI尝试绘制一些提交图，如果图形很复杂，则会有不同程度的成功。）

Answer 2

您可以创建orphan分支，以避免创建分支的历史记录，就像git init没有历史 甚至来自主分支 ：

git checkout feature
git checkout --orphan new-feature
git commit -m "new feature with no history"

什么可能导致feature1分支提交显示在feature2分支日志中？

2 个答案: