Как перенести существующий проект на GitHub?
Здесь мы обсудим важные рекомендации по переносу проекта в GitHub из устаревшей системы управления версиями.
Зачем выполнять миграцию на GitHub?
Существует масса литературы, восхваляющей преимущества GitHub. Это выходит за рамки этого модуля, чтобы убедить вас двигаться. Но мы можем вернуть некоторые ключевые преимущества в контексте тем, которые необходимо учитывать при планировании миграции.
Управление версиями
GitHub использует исключительно Git, возможно, лучшую систему управления версиями. Однако Git невероятно сложный и может представлять некоторые сложные сценарии для работы с кодом, с которым может не столкнуться ваша команда. Ветви и запросы на вытягивание являются основной частью повседневной жизни для разработчиков, использующих Git, поэтому понимание того, когда и как эффективно использовать их, необходимо для успешного выполнения на GitHub. Для вашей команды стоит сначала ознакомиться с потоком GitHub, чтобы вы могли попасть на землю.
Сохраните свой код в облаке
Большой объем кода проекта по-прежнему хранится в устаревших системах управления версиями за корпоративными брандмауэрами. При миграции на GitHub вы перемещаете свой код на облачную платформу GitHub, где участники команды могут легко получать к нему доступ из любого места. Эта миграция дает возможность заново сверить политику команды относительно типов файлов и данных, которые хранятся в системе управления версиями. Рекомендуется предположить, что все, что вы фиксируете в GitHub, скомпрометировано. Не следует включать конфиденциальные данные, такие как ключи API, пароли или другие файлы, содержащие сопоставимые сведения.
Примечание.
GitHub предлагает как общедоступные, так и частные репозитории, а также детализированные элементы управления доступом для различных частей репозитория. Это позволяет настроить отображение проектов для определенных пользователей, а также действия, которые может выполнять данный пользователь.
Совместная работа
GitHub обеспечивает отличную поддержку совместной работы групп с помощью таких функций, как фиксирование проблем, создание запросов на включение изменений и проверка кода. Однако поток GitHub может отличаться от методов, к которым в настоящее время привыкла ваша команда. Рекомендуется рассмотреть вопрос о том, планирует ли команда адаптироваться к GitHub, сохранить свой заданный процесс или встретиться где-то в середине перед завершением миграции.
Если проект является проектом с открытым исходным кодом, который допускает вклад внешних участников, то нет лучшего варианта для максимизации преимуществ, чем GitHub.
Миграция на GitHub
Общие вопросы планирования
Самое важное, что нужно рассмотреть перед миграцией на GitHub, — это необходимость сохранить что-либо за пределами текущего состояния источника. Если вы удовлетворены запуском нового проекта только с текущим исходным кодом как есть, лучше всего рассматривать его как новый проект и отправлять источник в репозиторий.
Однако если вы хотите сохранить журнал управления версиями, необходимо импортировать с помощью средства миграции GitHub. Дополнительные сведения о поддержке импорта для разных платформ управления версиями см. в описании импорта данных из сторонних систем управления версиями.
Кроме данных Git, может потребоваться сохранить проблемы, запросы на вытягивание или другие данные. Поддержка этих элементов зависит от платформы и обычно доступна от проектов сообщества. Этот модуль не охватывает перенос данных, отличных от Git.
Обработка двоичных файлов в вашем проекте
Рекомендуется, чтобы репозитории GitHub были ограничены файлами, необходимыми для создания проектов. Избегайте фиксации больших двоичных файлов, таких как артефакты сборки. Двоичные файлы, например электронные таблицы и презентации, лучше всего подходят для отслеживания на порталах, которые понимают, как правильно обслуживать их и управлять их версиями. Если требуется версия больших двоичных файлов, рассмотрите возможность использования расширения Git LFS (хранилище больших файлов) Git.
Создание важных файлов Git, таких как .gitignore
Git поддерживает файлы .gitignore для распространения файлов политик управления версиями. Эти файлы определяют шаблоны поиска, используемые для исключения файлов и папок из отслеживания системы управления версиями. Следующий простой пример рекурсивно исключает все папки, называемые Bin или bin, и их содержимое из отслеживания системы управления версиями:
[Bb]in/
Дополнительные сведения об игнорировании файлов можно узнать. Вы также можете ознакомиться с коллекцией начальных .gitignore файлов, предлагаемых для различных платформ в репозитории Gitignore.
Существуют и другие файлы, часто используемые в проектах GitHub, для объяснения различных политик для потребителей и участников репозитория. Даже если ваш проект является частным и предназначен для аудитории с ограниченными правами, все равно может быть полезно сформулировать эти политики. Хотя ни один из этих файлов не требуется, мы перечислили несколько распространенных из них здесь.
| Файлы | Характер использования |
|---|---|
README.md |
Целевая страница для папки. Эта страница отображается при просмотре папки в GitHub. |
LICENSE.md |
Лицензия, указанная в коде. |
CONTRIBUTING.md |
Объясняет, как пользователи должны участвовать в проекте, например ожидания в отношении запросов на включение изменений. |
SECURITY.md |
Объясняет политику безопасности для проекта. Предоставляет рекомендации для пользователей, желающих отправить конфиденциальный код, связанный с безопасностью, или отзывы, которые не должны быть публично раскрыты перед решением. |
Дополнительные сведения см. в статье Настройка проекта для работоспособного вклада.
Импорт проекта в GitHub.
После подготовки репозитория к миграции перейдите на вкладку "Код " репозитория GitHub. Используйте Импортировать код, чтобы указать исходный репозиторий.
Средство миграции GitHub заботится об остальных.
