如何将现有项目迁移到 GitHub？

  • 8 分钟

本文介绍将项目从旧的版本控制系统迁移到 GitHub 的重要注意事项。

为什么要迁移到 GitHub？

GitHub 的优点被许多文献所称颂。 说服用户迁移不在本模块范围内。 但是，我们回顾了在规划迁移时需要考虑的主题上下文中的一些主要优势。

版本控制

GitHub 只使用 Git，它可以说是最佳的版本控制系统。 然而，Git 非常先进，并且支持一些复杂方案来处理团队可能不熟悉的代码。 分支和拉取请求是使用 Git 的开发人员日常生活中的基本部分，因此了解何时以及如何有效地使用它们是在 GitHub 上取得成功的必要条件。 团队有必要先熟悉 GitHub 流，以便可以顺利上手。

将代码保留在云中

许多项目代码仍存储在企业防火墙后的旧版本控制系统中。 当迁移到 GitHub 时，你要将代码移动到 GitHub 的云平台，在此团队成员可以从任何位置轻松地访问它。 此迁移提供了一个良好的机会，可检查团队针对你在版本控制中保留的文件和数据类型所采用的策略。 作为最佳做法，你应假设你提交到 GitHub 的任何内容都可能遭泄露。 请确保不包括敏感数据，例如 API 密钥、密码或其他包含类似信息的文件。

注意

GitHub 提供了公共和专用存储库，以及对存储库不同部分的精细访问控制。 这样，你便可控制项目对谁可见，以及给定用户可执行哪些操作。

协作

GitHub 通过问题、拉取请求和代码评审等功能为团队协作提供了出色的支持。 但是，GitHub 流可能与团队当前习惯的做法不同。 最好要考虑团队是否计划适应 GitHub、保留其给定的过程，或者在完成迁移前的执行期间于某个位置融会贯通。

如果项目是一个允许外部参与者的开放源代码项目，则为了最大限度地提高权益，GitHub 就是最好的选择。

迁移到 GitHub

规划注意事项

在执行向 GitHub 的迁移之前，最重要的事情是考虑是否需要保留任何超出当前状态的源代码的内容。 如果你认为只使用当前保持原样的源启动新项目就行，则最佳选择是将其视为一个新项目并将源上传到存储库中。

但如果你想要保留版本控制历史记录，则需要使用“GitHub Migrator 工具”进行导入操作。 若要详细了解不同版本控制平台的导入支持，请参阅从第三方版本控制系统导入数据。

除了 Git 数据之外，你还可能想要保留问题、拉取请求或其他数据。 对这些项的支持因平台而异，通常可从社区项目中获得。 此模块不涉及迁移非 Git 数据。

处理当前存储在项目中的二进制文件

最佳做法是将 GitHub 存储库限制为仅存储生成项目所需的文件。 避免提交大型二进制文件，例如生成工件。 对于电子表格和演示文稿之类的二进制文件，更适合在知道如何正确地为这些文件提供服务并对它们进行版本设置的门户上进行跟踪。 如果你需要对大型二进制文件进行版本控制，请考虑使用 Git 扩展 Git LFS（大文件存储）。

创建 .gitignore 之类的重要 Git 文件

Git 支持 .gitignore 文件，有助于实施版本控制文件策略。 这些文件定义了用于从源代码管理跟踪中排除文件和文件夹的搜索模式。 下面这个简单的示例以递归方式从源代码管理跟踪中排除任何名为 Bin 或 bin 的文件夹及其内容：

[Bb]in/

你可以详细了解如何忽略文件。 还可以在 .gitignore中查看为各种平台提供的初学者 文件集合。

GitHub 项目中还经常使用其他一些文件来向存储库使用者和参与者说明不同的策略。 即使项目是专用项目并且仅供有限的受众访问，明确地阐明这些策略仍然非常有用。 虽然这些文件都不是必需的，但我们还是在这里列出了一些常见的文件。

文件 目的
README.md 目录的登陆页面。 在 GitHub 上查看其目录时，将呈现此页面。
LICENSE.md 提供代码所依据的许可证。
CONTRIBUTING.md 说明用户应如何为项目做出贡献，例如拉取请求预期。
SECURITY.md 说明项目的安全策略。 为想要提交敏感的安全相关代码或反馈的用户提供指导，这些代码或反馈在经过处理之前不应公开披露。

详细了解为运行状况参与设置项目。

将项目导入到 GitHub

存储库准备就绪可进行迁移之后，导航到 GitHub 存储库的“代码”选项卡。 使用“导入代码”选项指定源存储库。

将代码导入到 GitHub 存储库的屏幕截图。

“GitHub Migrator 工具”负责其他工作。

GitHub Migrator 工具的屏幕截图。