Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
近年来，Git 作为分布式源代码存储库越来越受欢迎，该存储库允许用户在处于断开连接状态时使用完整存储库。 git 的优点已有广泛记录，但如果需要回溯到之前的主目录库状态，会发生什么情况？ 执行这些操作并不直观，需要提升权限，因为这可能会影响到存储库的每一个用户，这是可以预期的。
那么，如何安全地回退中心存储库呢？
问题场景
假设将大型文件（如视频）提交到 git 服务器。 在传统的源代码系统中，将一切存储在一个位置，然后拉取所需的内容是方便的。 但是，使用 git，整个存储库将克隆到每个用户的本地计算机。 使用大型文件时，项目中的每个用户也需要下载大型文件。 将每个后续大型文件提交到服务器后，问题只会越来越严重，直到存储库变得过大，难以有效为用户服务。 更糟的是，即使从本地存储库中删除罪犯并重新提交，文件仍将存在于存储库的历史记录中，这意味着该文件仍将作为历史记录的一部分下载到每个人的本地计算机。
将大型文件添加到本地存储库
从本地存储库提交后，服务器也将包含大型文件
冻结存储库
重要
以下步骤将从分支历史记录中删除视频，但从 Azure Repos 克隆存储库时，该文件将保留在存储库历史记录中。 从分支历史记录中删除文件会阻止更新文件，这将在存储库中创建另一个版本的大型文件。 详细了解如何在 Git 中管理大型文件 ，并参阅此 博客文章 ，了解有关使用 Azure Repos Git 存储库时此行为的详细说明和解决方法。
若要解决此问题，必须从源开始，在本例中，这是服务器存储库。 要求团队停止推送到存储库，但如果在此过程中发生其他推送，你也必须考虑到这些推送，以免丢失任何数据。
变基和强制推送
如果团队中没有其他人对存储库进行任何更改（通常是通过推送），则可以采用简单的路由，其中基本上使本地存储库的外观与你想要的方式（即，没有大型文件）一样，然后强制更改服务器。
注意：在开始这项工作之前，可能需要克隆或修复本地存储库。 这可能会导致工作丢失或更改，因此请谨慎操作。
默认情况下，你可能只有能够更改其本地项目文件和存储库并将更改推送到服务器，因此你无法在服务器级别进行其他更改，例如删除或重新设置。 因此，您需要从管理员那里获取项目强制推送权限（首选）或管理员权限，或者找到拥有这些权限并且愿意提供帮助的人。 有关 git 权限的详细信息， 请转到此处。
接下来，需要重新设置存储库的基。
- 但首先，用于
git log查找最近提交的 SHA 哈希值 - 稍后将需要此信息。 这是因为我们需要知道最近的良好提交。 通过打开 git 命令提示符并键入以下内容来获取该信息：
git log
或者，可以从在 Visual Studio 团队资源管理器中查看分支历史记录来获取 SHA 哈希。
- 现在，打开 Git 命令提示符。
- 查找感兴趣的 SHA 哈希号。
- 你将需要以“25b4”开头的 SHA
请记住，git 使用指针来确定头分支或 Current Branch 所在的存储库中的位置。 因此，你感兴趣的存储库状态将处于过去的某个时间点。 若要“及时返回”，使之前所需状态为新的当前状态，需要使用 git rebase 命令：
git rebase -i <SHA hash of desired new current branch>
该 -i 开关提供了一点额外的安全性，因为它将在编辑器中显示历史记录（Windows 中的命令行上的 git 实现会显示经典 vi 编辑器，你可能记得你是否使用过基于 Unix 的系统）。
- 对于我们的示例，你将输入：
git rebase -i 25b4
- 编辑器出现后，移除所有“pick”行，但要保留作为新头部分支的分支除外。 如果一切顺利，在 vi 中，键入“:wenter<”以进行保存，或键入“!q>enter<”以退出而不保存。
你将更改不再需要的行
- 如图所示，将“
pick”更改为“drop”，然后在 vi 中键入“:w”进行保存，并键入“:q!”以开始变基
现在再次键入 git log - 日志中应缺少有问题的分支。 如果是，则可以完成最后一步，这需要项目管理员权限。
git log
请注意，大型视频的提交现在已从本地存储库中消失
- 类型：
git push --force
此命令将强制本地代码库覆盖服务器上的代码库。
请谨慎使用，因为可以轻松丢失服务器上的数据！！
请注意，必须向服务器进行身份验证才能正常工作
如果使用 Azure Repos，可能需要设置不使用特殊字符（例如电子邮件地址中的“@”）的备用凭据。 为此，请按照 此处的说明操作。
现在，分支将永久离开服务器，项目团队成员的后续克隆和同步将不会下载你尝试删除的大型文件。 用户将需要从服务器中拉取，以确保他们与新的服务器存储库状态同步。
如果用户有更新的提交
如果其他用户已经提交给服务器存储库，则你还需要考虑其他注意事项。 你想要删除包含大型文件的分支，但不想丢失团队所做的更改。 若要解决此问题，当你在变基过程中打开编辑器时，请仔细查看提交。 确保在“pick”行中列出了要保留的提交；删除想要移除的提交，例如添加大型文件的位置。
请注意，在重新分组后，团队中的其他用户还需要重新建立数据库，以便每个人都拥有服务器存储库的一致副本。 这是每个人的痛苦，通常应该避免。 因此，如果确实需要移除此处所述的推送，请务必与团队协调。 有关重新分组的完整详细信息，请查看 此处的官方重新分组文档。
关键是要确保你知道所需的提交和不需要的提交。 研究 git 日志或你使用的 IDE（如 Visual Studio）中的历史记录，并仔细记下要保留和要丢弃的 SHA 哈希。
在大型文件已存在一段时间且有后续分支和合并的情况下，可以使用git filter-branch选项删除该文件。 若要尝试一下，请按照此处的说明进行。
最佳做法注意事项
确保大型文件不进入主存储库可以减少大量工作。 考虑到这一点，以下是团队要记住的一些常识最佳做法：
可执行的操作
- 请经常提交更改。 你以后始终可以用 squash 或 rebase 来修复它们。
- 请使用分支来隔离你的更改。 分行便宜，私人化，合并很简单。 可以通过将分支上的更改推送到服务器来备份。
- 发布主题分支时，请使用命名约定。 将分支命名为“
users/<alias>/<branchname>”。 这有助于对分支进行分组，并使其他人能够轻松识别“所有者”。 - 请记住务必推送更改。
Commit != Checkin。(Commit + Push) == Checkin。 - 请考虑使用
.gitignore来处理大型二进制文件，以避免它们被添加到存储库中 - 了解更多信息。 - 请考虑使用 NuGet 或 TFS 版本控制来存储大型二进制文件。
禁忌事项
- 不要在推送后进行变基。 在 git 中对推送的提交进行变基可能不是件好事，因为它会强制存储库中的其他所有人对其本地更改进行变基。如果他们需要这样做，他们不会很高兴。 即使是推送的，在你自己的个人分支上对推送的提交进行变基也并不是什么大不了的事情，除非其他人正在拉取这些提交。
- 不要将二进制文件提交到存储库。 Git 不会按照 TFVC 所做的方式压缩二进制文件，因为所有存储库都具有所有历史记录，因此提交二进制文件意味着永久膨胀。
概要
有时，不需要的元素（如大型文件）会添加到存储库中，需要将其删除，以便使存储库保持干净且轻量级。 可以通过使用命令 git rebase 来整理本地存储库，然后使用命令 git push --force 将本地存储库覆盖服务器存储库。
作者：爱德华·弗莱和杰西·侯文 |与作者、ALM 和 DevOps Rangers 联系此处
(c) 2015 Microsoft Corporation。 保留所有权利。ÿ本文档“按原样”提供。本文档中表达的信息和观点（包括 URL 和其他 Internet 网站引用）如有更改，恕不另行通知。 您自行承担其使用风险。
此文件不会向您提供关于任何Microsoft产品的任何知识产权的法律权利。 可以复制本文档并将其用于内部参考目的。