我需要在Github的特定点进行备份，因为我们现在正在删除至少50％的代码。处理这个问题的最佳方法是什么。
PS：我们没有计划使用我们即将拆除的代码，但只是想将其作为备份。我应该创建不同的分支还是标记？
感谢。
答案 0 :(得分：0)
首先，版本控制系统的目的可以概括 - 可能过于概括，但仍然如下：记住每个版本。所以你使用版本控制系统的事实意味着您已经永久地永久保存所有代码。很快出现的问题是任何收集器：在集合中找到的东西。你需要某种索引，目录或其他什么。
所以想一想：标签会记住提交。
在Git中提交的是那些你看到的那些丑陋哈希ID的东西。以下是Git本身的Git存储库克隆中的一个：
$ git log
commit e3a80781f5932f5fea12a49eb06f3ade4ed8945c
Author: Junio C Hamano ...
以e3a80781f开头的东西是提交的“真实姓名”。同一个提交将在此存储库的每个副本中具有相同的编号，并且该编号是为此提交保留的。如果你记住它，你总是能够判断一个存储库是否有这个提交，如果Git的Git存储库中有这个数字，它就是这个提交。 （如果Git 的Git存储库没有进行此提交，它可能刚刚过时，需要git fetch才能使其更新。 1 ）
但是：谁能记住这件事？你可能还记得e3a或类似的东西，但很快它就会分解成一堆十六进制的数字。所以这就是标签的用途。任何特别有趣的提交都可以有一个标记，或者你甚至可以制作一种特殊的标记，一个带注释的标记，其中包含额外的信息：
$ git show v2.16.2
tag v2.16.2
Tagger: Junio C Hamano ... [snippage]
commit ffa952497288d29d94b16675c6789ef83850def3
Author: Junio C Hamano ...
名称v2.16.2对人类意味着什么。它会以你能够记住的方式记住提交ID（在本例中为ffa952497288d29d94b16675c6789ef83850def3）。
请注意，master之类的分支名称也会记住（单个）Git提交。关键区别 - 至少在这里;在master这样的分支名称和v2.16.2之类的标记名称之间还有一些更多的是分支名称随时间更改，以便记住最新< / em>在分支上提交。标签名称不是。
请注意，在Git中，每个提交都会记录父提交。这个最新提交链有一个父母;父母有自己的父母（这个提交的祖父母）等等，形成了软件的历史。因此存储在存储库中的提交是历史记录。每个提交都包含源代码的快照，这就是Git保留每个版本的方式。如果您使用Git提供的工具来重写历史记录，那么唯一的一次就不会出现这种情况，正如有些人所说的那样：进行过时的新提交，但不同意原始提交，然后更改您保存的名称 - 您的分支和标记名称 - 以便他们记住新的重写历史记录而不是原始历史记录。
如果您不重写历史记录并移动标记，则保留每个版本。当然，您的存储库只是 - 您的 - 所以可以移动标签;只是这不是他们打算工作的方式。 2 并记住：当你的Git存储库是你的时，每个Git的克隆存储库至少在默认情况下，在正常设置中 - 所有历史记录的完整副本：所有提交。所以每个人 - 例如爱丽丝，鲍勃和卡罗尔 - 拥有一切，或者至少，爱丽丝拥有其他Git在爱丽丝制作克隆时所拥有的一切，鲍勃拥有鲍勃制作克隆时其他Git所拥有的一切，等等。
1 还有一些其他可能性：例如，存储库可能是浅克隆，故意省略某些历史记录。在这种情况下，简单的git fetch无法修复，但您可以git fetch --unshallow填写所有历史记录。另一个当然是一个包含代码假装的存储库是Git，实际上并不是Git。如果它是恶意假装，Git的设计使它变得困难：它可能不会有这个提交，而且它几乎肯定不会有一个PGP签名的带注释的标签支持它，但这是一个话题对于另一个问题。
2 如果您重写历史记录，那么新历史记录的 new 提交将具有来自原始文件的不同提交哈希ID，因此人们将能够分辨。事实上，他们通常会发现即使他们不关心这样做，因为他们的 Git可以并且通常会在添加新内容时保留原始历史记录历史记录，并显示两者。但这也是另一个问题的另一个主题。
答案 1 :(得分：0)
通常用于指示您正在发布的点的标记。假设我们已经发布了v1.00，为了跟踪我们的发布代码，我们制作了一个标签，以便我们可以轻松找到v1.00发行版的代码。我们可以说Git标记跟踪分支中的特定提交。
我们使用分支从我们的开发（dev分支）或测试（测试分支）代码中分离出主代码（主分支）。最后我们用主代码（主分支）对它们进行Marge。
因此，在您的情况下，将您的最新更改提交给分支并标记它。 希望对你有帮助 ：-） 。