创建一个空分支？

Question

我有一个包含项目的 git 存储库。我现在要对这个项目进行大修。

如何为这个空白的大修创建一个新分支？然后完成时。如何将此分支切换到master？

Answer 1

使用 checkout --orphan 命令

git checkout --orphan MyNewBranch
git reset -- *
git ls-files

另请参阅此链接 https://git-scm.com/book/en/v2/Git-Tools-Replace

Answer 2

Gregg's answer 和the linked possible-duplicate 都建议使用git checkout --orphan（链接的问题可以追溯到--orphan 相对较新的时候）。

In a comment、exxecc 建议从某个现有提交创建一个分支，删除所有内容（例如，git rm -r .），然后从那里继续。

这两种方法都有效且可行。那么您应该使用哪一个？这个问题的答案不取决于你现在想做什么，而是你想做什么，稍后。和往常一样，关键是 Git 的提交图。 （为了稍微破坏效果，但作为答案更有用，我会说“选择孤儿”，因为您可能需要推迟此决定，而“孤儿”稍后会为您提供更多选择。继续阅读以了解我是什么谈论。）

一个孤立分支是一个新的根提交

当您查看 Git 的提交图时，git log 默认以 current 提交开始，或任何命名分支的最尖端提交。 （然后它继续通过按日期对提交进行排序来破坏这种明智的行为，但这是一个不同的问题，如果日期本身是明智的，那么这种“破坏”基本上没有任何影响，实际上它仍然是明智的。）因此我们从某些分支的当前或最近一次提交、提交，并及时向后工作到 root 提交。

根提交只是没有父母的提交。这是时间的起点。它有后代——在它之后的提交，是从它派生的——但它没有祖先。它是从头开始创建的；它没有以前的历史。

重写可能是正确的（大修，在原始问题描述中）。

或者，它可能不会。当然，这是一次重写——但之前有 一些东西。有 个以前的提交。也许你应该包括它们。

任何其他提交都有历史记录

如果你作为一个非-root提交，一个清空先前版本的提交（并且什么都没有，或者一个简单的骨架，或者甚至可能是一个新的、重写的实现） ，将来，您将能够及时回溯到这个新开始之前的某个时间点。事实上，这会更准确。此外，它将允许您将其合并到其他分支中，Git 会向您显示自“新开始”点以来修改或创建的文件的冲突。

假设，例如，有问题的项目有一个主要分支，这是您打算重写的分支，但它也有一个用于一些实验的分支。如果该实验被证明是成功的，那么在一段时间后将部分或全部工作带回重写可能会很好。如果您的重写从清空然后替换开始，那么实验分支的一个简单的git merge 将为您提供“由他们修改，由我们删除”形式的冲突，每个文件都有更改。

无论如何，git log 将能够向您展示真实的历史：在某个时候，您进行了大规模的重写。那段真实的历史可能有一些价值。 （不过，正如所有代码历史记录一样，有时该值可能比正数更负。:-)）

两全其美

尽管我在上面建议不使用孤立分支可能有优势，但我推荐使用孤立分支方法。原因是这可以让你推迟决定。这是基本思想。

在具有完全独立历史记录的新孤立分支中——顺便说一下，您也可以在完全独立的存储库中创建它，从而无需git checkout --orphan——您可以开发大修后的，从头重写版本。然后，在某个时候，您认为它已准备好替换旧版本。此时，您可以合并两个分支（或两个存储库），即使它们没有共同的基础。您只需要使用两个父级进行新提交：第一个父级是重写分支的当前尖端，第二个父级是原始（未重写）版本。

第二个父提交可以是现在的原始版本，此时两者正在“合并”，也可以是重写项目开始时的提交。

我在这里将“合并”放在引号中只是因为合并提交的 tree 将只是重写版本。我们将完全忽略旧版本的 source。新合并提交的要点只是将两条开发线的历史结合起来，并暗示（通过使分支名称，例如master 指向新的合并提交）新版本现在是可以说是负责。

(这种合并是由-s ours策略进行的，虽然也有一种相对简单的手动方法。如果你想直接在master上进行这种合并，你将需要@ 987654335@ 而不是，这需要手动方法。要使用 -s ours 进行此操作，请在孤立分支上进行合并，然后将分支名称打乱。如果您已将新的孤立分支版本放在孤立中-单独-repository，只需将新存储库添加为额外的远程，获取新版本，然后像往常一样进行合并提交。）