Як підготувати та передати наявний проект до 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 є найкращим способом керування змінами, гілками тощо.