我将这个项目添加到了一个由主要分支组成的git存储库中。
A--->B--->C--->D--->E
当我对b tht b进行一些实验修改时，我想在其他分支中保留 main 分支的副本 main-copy ，以防万一错误的原因是在Main Branch上玩提交，我不想进行还原，我仍然有一个完整的主分支副本。
如果我创建 main_copy 在提交e之上的分支，当前我实际上不会制作 main 分支的副本。
因此，我需要在提交A之上创建一个分支，并在此分支中进行相同的提交。最后的存储库将是这样的。
A--->B--->C--->D--->E
|
`--->B'--->C'--->D'--->E'
我不知道如何做到这一点，而不必重新犯下另一个分支，然后再次通过e逐一进行b。
在git上有没有忠实的命令？
I have this project added to a git repository with the main branch consisting of a number of commits.
A--->B--->C--->D--->E
as i'm doing some experimental modifications on commits A through B i want to keep a copy of the commits of main branch inside a different branch main-copy in case anything went wrong due to play with commits in main branch and i wouldn't want to go through restoring, i still have an intact copy of main branch.
if i create main_copy branch on top of commit E where Head is currently at i will not actually make a copy of main branch because commits A to B are common between the two branches.
so i need to create a branch on top of commit A and do the same commits in this branch. the final repository would be something like this.
A--->B--->C--->D--->E
|
`--->B'--->C'--->D'--->E'
I have no idea how to do this without going back to commit A making another branch and doing commits B through E again one by one.
is there any devoted command to do this on git?
发布评论
评论（1）
TL; DR
所需要做的就是在开始实验之前创建一个分支名称。
长期
。
我不是说您不是尝试尝试这样做。我的意思是从字面上看，这是不可能的，所以无论您尝试什么，这实际上都没有发生。
这里的诀窍是：提交是不可变的，但是我们没有通过它们不可变的真实名称找到它们。任何给定提交的真实名称是其哈希ID，使用该哈希ID会找到commit 的。无论您尝试多么努力，该提交都永远不会改变。稍后再次使用该名称会找到comport 的（有一个警告：请参见下文）。
A 分支名称在git中是一个数据库条目，但是您可以将其视为一个小文件，因为有时将其实现为一个小文件。此“文件”（或实际文件）包含一个字符串，条目提供的一个字符串是我们要声明的 last commit的 hash id 分支”。
也就是说，给定的一连串的提交：
如果我们创建一个分支名称输入并塞入提交
h到 该名称，我们得到：运行
git log tomeBranch显示我们提交h，然后提交commitg，然后提交f，等等。如果我们尝试更改其中一些提交（例如
g），而发生的事情是，我们立即获得了 new commit，ag'，其父<代码> f 。新提交g'没有孩子，并且要查找g'我们将使用一个名称，例如分支名称，因为人类是如此不擅长使用哈希ID：如果进行“修改”提交
g'的目的是仅编辑g中的提交消息的文本 ，新提交g'将保持由于它的快照是g保留的相同快照（两个快照将是100％被删除的，因此g'没有额外的空间）。然后，我们必须制作一个新的h'h的副本，其中我们在h'中更改的一件事是它保存的父母哈希ID：commith'必须向后指向我们的新g'：一旦我们处于这种情况下，如果我们 stuff
h 's Hash ID中的名称someBranch，我们得到：如果现在删除临时名称
newBranch，似乎我们已经编辑了Commit commit> g'以某种方式：我们从字面上看，除非我们在某处记住了它的哈希ID，否则找不到 commit commit 。
当然，记住其哈希ID的地方很明显：我们只是创建一个新的分支名称在做任何事情之前，我们要做“修改”
g以制作g'。然后，一旦名称someBranch找到h'而不是h，我们创建的我们的分支是h：和
git日志原始单行向我们展示了仍然存在的原始提交。如果我们忘记创建名称怎么办？
如果我们忘记了创建一个名称，例如
ointer-somebranch，我们必须 找到旧提交的哈希IDh。我们有一些时间来做到这一点：git存储库也不会丢弃旧提交，即使是通过普通方式无法理解的，因为“一段时间”。那“一段时间”多长时间？好吧，这取决于许多事情。一些托管系统（例如，github）从不丢弃旧提交。默认情况下，git设置了三个到期时间：14天，30天和90天。在这三次中之一之后， 名称都无法找到的旧提交可以消失。当然，如果您先制作新名称，那么您最安全，
git rebase -i或您正在做的任何事情。但是大多数操作将提交哈希ID的副本放入另一个名称或a reflog条目，在这里30或90天默认启动。要安全起见，我们应该考虑较短的到期：30 几天后能够找到h，如果我们不费心为其创建名称，则git May 可以删除它。 Git的过程是有点懒惰的，因此它可能会持续多个月或几年，但是在回流条目到期30天之后，它已经“变得脆弱”。您可以使用
git reflog查看回流条目，这实际上是运行git log -g的前端。请参阅git reflog的文档。请注意，在一个随机的哈希ID和提交信息的海洋中，很难从另一个旧提交中告诉一个旧提交。这是在您开始工作之前制作名称的另一个原因。如果通过“垃圾收集器”
git gc删除提交，并且您将git命名其真实姓名（哈希ID），则git会说它不识别该哈希ID。如果您只是构成哈希ID，尽管您“缩短”了一个缩短的情况，但也会发生同样的事情ID。如果您使用 branch名称（或标签名称或其他名称）来保存哈希ID，这也停止git gc删除它，因为现在可以找到提示能够以一些可读的名称。这也保护所有提交的所有提交（比此提交更早），因为这些提交也可以发现。TL;DR
All you need to do is create a branch name before you start experimenting.
Long-ish
No, you're not.
I don't mean you aren't trying to do that. I mean it's literally impossible to do that, so no matter what you try, that doesn't actually happen.
The trick here is this: commits are immutable, but we don't find them by their immutable true names. The true name of any given commit is its hash ID, and using that hash ID will find that commit. That commit can never be changed, no matter how hard you try; using that name again later will find that commit (with one caveat: see below).
A branch name, in Git, is a database entry, but you can think of it as a small file, because it's sometimes implemented as a small file. This "file" (or actual file) contains one string, and that one string the entry provides is the hash ID of the last commit we want to claim is "in the branch".
That is, given a string of commits:
which ends at commit
H, if we create a branch name entry and stuff the raw hash ID of commitHinto that name, we get:Running
git log somebranchshows us commitH, then commitG, then commitF, and so on.If we attempt to change some of these commits—such as
G—what happens instead is that we immediately get a new commit, aG', whose parent isF. New commitG'has no child, and to findG'we will use a name, such as a branch name, because humans are so bad at using hash IDs:If the purpose of making "modified" commit
G'was to edit just the text of the commit message inG, new commitG'will hold as its snapshot the same snapshot thatGholds (and the two snapshots will be 100% de-duplicated and thus the one forG'takes no extra space). We then have to make a newH'copy ofHwhere the one thing we change inH'is its saved parent hash ID: commitH'must point backwards to our newG':Once we're in this situation, if we stuff
H's hash ID into the namesomebranch, we get:If we now delete the temporary name
newbranch, it seems as though we've edited commitG'somehow:We literally can't find commit
Hunless we've memorized its hash ID somewhere.Of course, the place to memorize its hash ID is obvious: we just create a new branch name before we do whatever it is that we do that "modifies"
Gto makeG'. Then, once the namesomebranchlocatesH'instead ofH, our branch we created earlier locatesH:and
git log original-somebranchshows us the original commits, which still exist.What if we forget to create the name?
If we forget to create a name like
original-somebranch, we must find the hash ID of old commitH. We have some time to do this: a Git repository will not discard an old commit, even if it's unfindable by ordinary means, for "some time". How long is that "some time"? Well, that depends on many things. Some hosting systems (e.g., GitHub) never discard old commits. Git by default sets three expiration times though: 14 days, 30 days, and 90 days. After one of these three times, old commits that can't be found by any name can go away.You're safest, of course, if you make the new name first, before doing
git rebase -ior whatever it is that you are doing. But most actions place a copy of a commit hash ID into another name, or a reflog entry, and here the 30 or 90 day default kicks in. To be safe we should just consider the shorter expiration: 30 days after we were able to findH, if we haven't bothered to create a name for it, Git may get around to removing it. Git's process for doing this is kind of lazy so it could stick around for many more months or years, but it has "become vulnerable" after the 30 day expiry of the reflog entry.You can view reflog entries with
git reflog, which is actually a front end that runsgit log -g. See the documentation forgit reflogfor details. Note that in a sea of random-looking hash IDs and commit messages, it can be hard to tell one old commit from another. That's the other reason to make the name before you start working.If a commit is removed via the "garbage collector"
git gc, and you give Git its true name (hash ID), Git will say that it doesn't recognize that hash ID. The same thing happens if you just make up a hash ID—although if you "make up" a shortened one, there's a good chance that this is the valid prefix of some existing commit, so you want to make sure you remember the full hash ID. If you use a branch name (or tag name or other name) to hold the hash ID, that also stopsgit gcfrom removing it, since the commit is now find-able by some human-readable name. This also protects all commits "behind" (earlier than) this commit, since those too are find-able.