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