Як перенести наявний проект до GitHub?
Тут ми обговорюємо важливі зауваження щодо перенесення проекту до GitHub із застарілої системи керування версіями.
Навіщо переносити до GitHub?
Є томи літератури, що звеличують чесноти GitHub. Цей модуль виходить за рамки цього модуля, щоб переконати вас у переміщенні. Але ми можемо змінити деякі основні переваги в контексті тем, які потрібно враховувати під час планування перенесення.
Керування версіями
GitHub використовує виключно Git, мабуть, найкращу систему керування версіями. Однак Git неймовірно складний і може представити деякі складні сценарії роботи з кодом, з яким ваша команда може не мати досвіду. Гілки та запити на витягування є основною частиною повсякденного життя для розробників, які використовують Git, тому розуміння того, коли і як їх ефективно використовувати, необхідно для успішного використання GitHub. Команді варто спочатку ознайомитися з потоку GitHub, щоб ви могли потрапити на землю.
Зберігайте код у хмарі
Великий обсяг коду проекту все ще зберігається в застарілих системах керування версіями за корпоративними брандмауерами. Під час перенесення до GitHub ви переміщуєте код на хмарну платформу GitHub, де учасники команди можуть легко отримати доступ до нього звідусіль. Це перенесення дає змогу переглянути політику команди щодо типів файлів і даних, які ви зберігаєте в елементі керування версіями. Як найкраща практика, слід вважати, що все, що ви берете на себе зобов'язання щодо GitHub, порушено. Не включайте конфіденційні дані, наприклад ключі API, паролі або інші файли, які містять порівнянну інформацію.
Примітка
GitHub пропонує як загальнодоступні, так і приватні репозиторії, а також деталізовані елементи керування доступом для різних частин сховища. Це дає змогу визначати, кому відображаються ваші проекти, а також які дії може виконувати певний користувач.
Співробітництво
GitHub надає чудову підтримку для співпраці в команді завдяки таким функціям, як проблеми, запити на витягання та відгуки про коди. Однак потік GitHub може відрізнятися від методів, до яких зараз звикла ваша команда. Радимо розглянути, чи планує команда адаптуватися до GitHub, зберегти свій процес або зустрітися десь посередині, перш ніж завершити перенесення.
Якщо проект – це проект із відкритим кодом, який дає змогу зовнішнім співавторам, краще використовувати GitHub для максимального розширення переваг.
Перенесення до GitHub
Зауваження щодо планування
Найважливішим моментом перед перенесенням до GitHub є те, чи потрібно зберігати будь-що за межами поточного стану джерела. Якщо ви задоволені запуском нового проекту лише з поточним вихідним as-is, найкращий варіант – ставитися до нього як до нового проекту та передавати джерело до сховища.
Однак, якщо ви хочете зберегти журнал керування версіями, потрібно імпортувати дані за допомогою засобу перенесення 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 Migrator піклується про решту.
