我有一个包含项目的git repo。我现在要对该项目进行大规模的改造。
如何为此次大修创建一个新分支？然后完成。如何将此分支切换为主分区？
答案 0 :(得分：23)
使用checkout --orphan命令
git checkout --orphan MyNewBranch
git reset -- *
git ls-files
答案 1 :(得分：16)
Gregg's answer和the linked possible-duplicate都建议使用git checkout --orphan（链接的问题会追溯到--orphan相对较新的时候）。
In a comment，exxecc建议从现有提交中创建一个分支，删除所有内容（例如git rm -r .），并从那里继续。
这两种方法都是有效且可行的。那么你应该使用哪一个 ？答案取决于您现在想要做什么，而不是您想要做什么，并且稍后会看到 。关键是，像往常一样，Git的提交图。 （为了稍微破坏效果，但作为答案更有用，我会说＆＃34;与孤儿一起去＃34;因为你可能需要推迟这个决定，并且＆＃34; orphan＆＃34;给出你以后会有更多的选择。请继续阅读，看看我在说什么。）
当您查看Git的提交图时，git log默认情况下以当前提交开头，或者任何已命名分支的提示最多提交。 （然后它继续通过按日期对提交进行排序来破坏这种明智的行为，但这是一个不同的问题，如果日期本身是明智的，那么这种＆＃34;毁灭＆＃34;基本上没有任何影响，并且＃39; ; s实际上仍然是明智的。）因此，我们从当前或最近的某些分支（es），提交开始，并及时向 root commit 工作。
根提交只是一个没有父母的提交。这是一个起点。它有后代 - 来自它后面的提交，它来自它的 - 它没有祖先。它是从头开始创建的;它没有历史。
在原始问题描述中，重写（大规模检修）可能也是如此。
或者，它可能不会。当然，它是一个重写 - 但之前是的东西。那里有 以前的提交。也许你应该包括它们。
如果您作为非 -root提交，提交清空以前版本的提交（根本没有任何内容，或者简单的框架，或者甚至是新的重写实现） ，您将来能够及时扫描回到新的开始之前的某个点。事实上，这将更加准确。此外，它允许您将其合并到其他分支中，Git向您显示自从＆＃34; new start＆＃34;以来修改或创建的文件的冲突。点。
例如，假设有问题的项目有一个主要分支，这是您打算重写的分支，但它也有一个侧面分支用于某些实验。如果这个实验证明是成功的，那么在一段时间后，将部分或全部工作重新带回重写可能会很好。如果你的重写是通过清空然后替换来开始的，那么实验分支的简单git merge会给你冲突的形式＆＃34;由他们修改，由我们删除＆＃34;对于每个文件都有变化。
无论如何，git log将能够向您展示真实的历史：在某些时候，您进行了大量的重写。真实的历史可能有一些价值。 （尽管如此，正如所有代码历史一样，有时价值可能比正面更负面。:-)）
尽管我建议使用孤儿分支 not ，但我推荐使用孤儿分支方法。原因是这可以让你推迟决定。这是基本的想法。
在新的孤立分支中，它具有完全独立的历史记录 - 您可以在完全独立的存储库中创建它，从而无需git checkout --orphan - 您可以开发从头开始大修，重写的版本。然后，在某些时候，您认为它已准备好替换旧版本。此时，您可以合并两个分支（或两个存储库），即使它们没有公共基础。您只需要使用两个父项进行新的提交：第一个父级是重写分支的当前提示，第二个父级是原始（未重写）版本。
第二个父提交可以是现在的原始版本，也可以是两个正在进行的合并＆＃34;，或者是重写项目开始时的提交。
我把＆＃34;合并＆＃34;在引号中仅因为合并提交的树将只是重写版本。我们将完全忽略旧版本的源。新合并提交的要点仅仅是连接两行开发的历史，并暗示（通过使分支名称，例如master指向新的合并提交）新版本现在是负责人。
（这种合并是由-s ours策略制定的，虽然有一种相对简单的方法可以手动制作。如果你想直接在master进行合并，你需要相当于-s theirs，需要手动方法。要使用-s ours执行此操作，请在孤立分支上进行合并，然后将分支名称随机移动。如果已放置新的孤立分支版本在orphan-separate- 存储库中，只需将新存储库添加为额外的远程数据库，获取新版本，然后照常进行合并提交。）