Гілки

Перегляд Гілки надає огляд різних гілок у вашому репозиторії.

Етапи

Odoo.sh пропонує три різні стадії гілок:

• Промислова експлуатація

• Тестування

• Розробка

Ви можете змінити стадію гілки, перетягнувши її під потрібну стадію.

Примітка

• Гілки розробки можна переміщувати під Тестування. Якщо ви спробуєте перемістити гілку розробки під Промислова експлуатація, з’явиться попереджувальне повідомлення з поясненням, що ви можете мати лише одну промислову гілку на проект.

• Гілки тестування можна переміщувати під Розробка, але їх неможливо перемістити під Промислова експлуатація.

• Промислову гілку можна перемістити лише під Розробка. Якщо ви спробуєте перемістити її під Тестування, ви зможете виконати лише злиття. Зверніться до розділу злиття для детального пояснення цього процесу.

Виробництво

Промислова гілка містить код, який використовується для роботи промислової бази даних. Може існувати лише одна промислова гілка.

Коли ви надсилаєте новий коміт до цієї гілки, промисловий сервер оновлюється переглянутим кодом і перезапускається.

Якщо зміни вимагають оновлення модуля, наприклад зміни форми перегляду, і ви хочете, щоб оновлення виконувалося автоматично, ви можете збільшити номер версії модуля в його файлі маніфесту (__manifest__.py). Після цього платформа виконує оновлення, під час якого екземпляр буде тимчасово недоступний з причин технічного обслуговування.

Цей метод еквівалентний оновленню модуля через меню Додатки або перемикач -u у командному рядку.

Примітка

• Якщо зміни перешкоджають перезапуску сервера або якщо оновлення модуля не вдається, сервер автоматично повертається до попередньої успішної версії коду, а база даних відкочується до попереднього стану. Отримайте доступ до журналу невдалого оновлення для усунення несправностей.

• Демонстраційні дані не завантажуються, оскільки вони не призначені для використання в промисловій базі даних. Модульні тести не виконуються, оскільки це збільшило б час недоступності промислової бази даних під час оновлення.

Odoo.sh автоматично створює резервні копії промислової бази даних. Зберігається сім щоденних, чотири щотижневих і три щомісячних резервних копії. Кожна резервна копія включає дамп бази даних, сховище файлів (вкладення та бінарні поля), журнали та сесії.

Попередження

При використанні пробних проектів промислова гілка та всі гілки тестування автоматично повертаються до стадії розробки через 30 днів.

Проміжне середовище

Гілки тестування призначені для перевірки нових функцій з використанням промислових даних без компрометації фактичної промислової бази даних тестовими записами. Вони створюють нейтралізовані дублікати промислової бази даних.

Нейтралізація вимикає:

• Заплановані дії

  Примітка

  Щоб їх перевірити, запустіть їх вручну або увімкніть знову. Майте на увазі, що платформа запускатиме їх рідше, якщо ніхто не використовує базу даних, щоб заощадити ресурси.

• Вихідні електронні листи

  Примітка

  Натомість вони перехоплюються за допомогою mail catcher. У вашому проекті Odoo.sh надається інтерфейс для перегляду електронних листів, надісланих з бази даних. Таким чином жодні електронні листи не надсилаються вашим контактам.

• Служби IAP

• Платіжні провайдери та з’єднувачі доставки

  Примітка

  Вони переводяться в тестовий режим.

Якщо ви налаштовуєте або переглядаєте зміни в проміжній базі даних, обов’язково запишіть їх (записуючи крок за кроком, відтворюючи в продакшені тощо) або запишіть їх безпосередньо в модулі гілки, використовуючи XML-файли даних для перевизначення стандартної конфігурації чи подань. Перегляньте документацію до першого модуля, щоб побачити приклади.

Примітка

Модульні тести не виконуються. Вони покладаються на демонстраційні дані, які не завантажуються в продакшн та проміжні бази даних. Якщо Odoo почне підтримувати запуск модульних тестів без демонстраційних даних, Odoo.sh розгляне можливість запуску тестів на проміжних базах даних.

Проміжні бази даних не створюють резервні копії автоматично. Проте ви можете відновити резервну копію виробничої бази даних у проміжній гілці для тестування або для ручного відновлення даних, які були випадково видалені з виробничої бази даних. Можна створювати резервні копії проміжних баз даних вручну.

Попередження

Бази даних, створені для staging-гілок, автоматично видаляються через один місяць. Щоб знову використовувати гілку, необхідно її перебудувати.

Розробка

Гілки розробки створюють нові бази даних, використовуючи демонстраційні дані для запуску модульних тестів. Встановленими модулями є ті, що включені в гілку. Ви можете змінити цей список модулів для встановлення в налаштуваннях проекту.

Під час надсилання коміту до гілки розробки запускається новий сервер з базою даних, створеною з нуля, і гілка оновлюється. Завантажуються демонстраційні дані, а модульні тести виконуються за замовчуванням для перевірки того, що зміни не порушують жодну з функцій, що тестуються. Ви можете вимкнути тести або дозволити запуск конкретних тестів за допомогою спеціальних тегів, перейшовши до налаштувань гілки.

Подібно до проміжних гілок, електронні листи не надсилаються, а перехоплюються mail catcher, а заплановані дії не запускаються, доки база даних не використовується.

Бази даних розробки не створюються автоматично, а ручне створення резервних копій неможливе.

Попередження

Бази даних, створені для гілок розробки, розраховані на існування приблизно три дні. Після цього вони можуть бути автоматично видалені збирачем сміття, щоб звільнити місце для нових баз даних без попереднього повідомлення.

Злиття гілок

Ви можете об’єднувати гілки, перетягуючи їх одну в одну.

Щоб перевірити зміни гілок розробки з продакшн-даними, ви можете:

• Об’єднати гілку розробки з проміжною гілкою, перетягнувши її на потрібну гілку; або

  

• Перетягніть гілку розробки в розділ Staging, щоб зробити її staging-гілкою.

  

Коли зміни готові для продакшену, перетягніть staging-гілку в production-гілку, щоб об’єднати та розгорнути їх.

Примітка

• Ви можете об’єднувати гілки розробки безпосередньо в production-гілку. Однак зміни не будуть перевірені на production-даних через staging-гілку, тому існує вищий ризик виникнення проблем у production-базі даних.

• Ви можете об’єднувати гілки розробки між собою, а також staging-гілки між собою.

• Ви також можете використовувати git merge безпосередньо на своїй робочій станції для об’єднання гілок. Odoo.sh отримує сповіщення, коли нові ревізії надсилаються до ваших гілок.

Об’єднання staging-гілки в production-гілку об’єднує лише вихідний код. Будь-які зміни, внесені до staging-бази даних, не передаються до production-бази даних. Однак якщо ви змінюєте код у репозиторії, він буде переданий до production-гілки при об’єднанні.

Якщо ви тестуєте зміни конфігурації в staging-гілках і хочете, щоб вони були застосовані до production-гілки, вам потрібно:

• Записати зміни конфігурації в XML-файли даних, щоб перевизначити стандартну конфігурацію або представлення в гілці, а потім збільшити версію модуля в його маніфесті (__manifest__.py), щоб ініціювати оновлення модуля при об’єднанні staging-гілки в production-гілку.

  Примітка

  Цей метод рекомендується для кращої масштабованості ваших розробок, оскільки ви використовуватимете функції версіонування Git для всіх змін конфігурації, тим самим забезпечуючи відстежуваність ваших змін.

• Передати їх вручну зі staging-бази даних до production-бази даних, скопіювавши та вставивши їх.

Вкладки

Історія

Вкладка History надає огляд історії гілки:

• Повідомлення комітів та їх автори

• Різні події, пов’язані з платформою, такі як зміни етапів, імпорт баз даних та відновлення резервних копій

Статус у верхньому правому куті кожної події вказує на поточну операцію над базою даних (наприклад, встановлення, оновлення, імпорт резервної копії) або її результат (наприклад, зворотний зв’язок тесту, успішний імпорт резервної копії). Якщо операція успішна, з’являється кнопка Connect, яка дозволяє отримати доступ до бази даних.

Листи

Вкладка Mails містить перехоплювач пошти, який надає огляд електронних листів, надісланих базою даних.

Примітка

Перехоплювач пошти доступний для гілок розробки та staging. Електронні листи з production-бази даних фактично надсилаються і не перехоплюються перехоплювачем пошти.

Командна оболонка

Вкладка Shell надає доступ до оболонки контейнера.

Клацання на Shell відкриває нову вкладку браузера, де ви можете виконувати базові команди Linux (ls, top). Ви можете відкрити оболонку в базі даних, виконавши psql.

Порада

Ви можете відкрити кілька вкладок оболонки одночасно та впорядкувати їх розташування, перетягуючи їх.

Примітка

• Оболонки робочих екземплярів виділені червоним кольором, щоб підкреслити небезпеку прямого маніпулювання робочими екземплярами, тоді як оболонки тестових/розробницьких екземплярів виділені жовтим кольором.

• Довготривалі екземпляри оболонки/неактивні сеанси оболонки можуть бути завершені в будь-який час для звільнення ресурсів.

Команди

Ось огляд корисних команд, які ви можете виконати в терміналі бази даних Odoo.sh:

• odoo-bin shell: щоб відкрити оболонку Odoo

• odoo-update: щоб оновити модулі в базі даних

• odoosh-restart: щоб перезапустити служби Odoo.sh (http або cron)

• odoosh-storage: щоб перевірити використання сховища файлової системи контейнера вашого екземпляра

• psql: щоб відкрити оболонку бази даних

• mutt: щоб перевірити, як електронні листи відображаються в текстових клієнтах (тестові та розробницькі екземпляри)

• lnav ~/logs/odoo.log: щоб переглядати файл odoo.log вашого екземпляра

• ncdu: щоб запустити аналізатор використання диска з інтерактивним інтерфейсом

• grep: щоб фільтрувати та знаходити інформацію в файлах журналів або конфігурації

Редактор

Клацання на Editor відкриває нову вкладку браузера для доступу до онлайн-інтегрованого середовища розробки (IDE) для редагування вихідного коду. Ви також можете відкривати термінали, консолі Python та консолі оболонки Odoo.

Ви можете відкрити кілька вкладок і перетягувати їх, щоб впорядкувати розташування на свій смак.

Див. також

Документація онлайн-редактора.

Моніторинг

Вкладка Монітор відображає різні метрики моніторингу продуктивності поточної збірки.

Збільште масштаб за допомогою курсора, щоб налаштувати часовий діапазон, або виберіть його вручну з селектора часового діапазону. Також можна змінити часовий пояс.

Примітка

• Технічні журнали завжди використовують UTC. Щоб аналізувати ці журнали разом із метриками моніторингу, переконайтеся, що в інструменті моніторингу вибрано UTC.

• Аналогічно, надсилаючи заявку в службу підтримки, переконайтеся, що інформація, якою ви ділитеся, базується на UTC, оскільки Odoo використовує цей часовий пояс для дослідження проблем продуктивності.

Інформація агрегується періодично. Коли це відбувається, відображається синя пунктирна лінія разом із тегом Дата агрегації. Це означає, що дані до цієї дати виглядатимуть більш згладженими порівняно з даними після цієї дати. Тому під час використання інструменту моніторингу рекомендується зосередитися на останніх подіях, щоб отримати якомога детальнішу інформацію.

Примітка

Пунктирні лінії інших кольорів допомагають співвіднести інші зміни у збірці (імпорт бази даних, git push тощо).

Порада

На кожному графіку у верхньому лівому куті відображається піктограма 𝕚 (інформація). Наведіть на неї курсор миші, щоб отримати докладнішу інформацію про те, що представляє графік.

Метрики

Система

Графік Пам’ять відображає інформацію про споживання пам’яті:

• Memory container представляє робочі процеси Odoo та процеси контейнера.

• Memory postgresql представляє базу даних.

Графік ЦП відображає інформацію про споживання процесора:

• CPU http представляє робочі процеси Odoo.

• CPU cron/mail представляє заплановані дії та вхідні електронні листи.

• CPU postgresql (процеси бази даних)

• CPU other представляє веб-оболонки, редактор тощо.

Графік Сховище відображає інформацію про використане сховище:

• Контейнер представляє файлове сховище, лог-файли та файли користувачів.

• Postgresql представляє базу даних та індекси.

HTTP

Графік Запити відображає інформацію про кількість HTTP-запитів за секунду:

• Успішні HTTP представляє успішні запити.

• Помилки HTTP представляє невдалі запити (перевірте odoo.log).

• HTTP з обмеженням швидкості представляє відхилені запити, можливо, через брак воркерів.

Графік Одночасні запити (макс.) відображає максимальну кількість одночасних HTTP-запитів за секунду.

Примітка

Воркери бази даних визначають кількість одночасних запитів, які можуть оброблятися одночасно. Важливо мати достатню кількість воркерів для обробки всіх вхідних запитів по мірі їх надходження. Однак наявність додаткових воркерів понад це не покращує швидкість обробки запитів.

Середній час відповіді відображає середній час відповіді на HTTP-запити (у мілісекундах).

Листи

Графік Вхідні відображає дані про щоденну кількість вхідних електронних листів:

• Отримані листи представляє електронні листи, успішно отримані.

• Повернуті отримані листи представляє електронні листи, отримані неуспішно.

Графік Вихідні відображає дані про щоденну кількість вихідних електронних листів:

• Надіслані листи представляє успішно надіслані електронні листи.

• Повернуті надіслані листи представляє неуспішно надіслані електронні листи.

Журнали

Вкладка Журнали надає перегляд журналів вашого сервера в реальному часі.

Доступні різні журнали:

• pip.log: встановлення залежностей Python

• install.log: встановлення бази даних (для гілок розробки включені тести)

• odoosh-import-database.log: процес останнього імпортованого дампа

• odoo.log: запущений сервер

• update.log: оновлення бази даних

• pg_slow_queries.log: psql-запити, які займають незвичайно багато часу

• sh_webshell.log: дії, виконані в webshell

• sh_editor.log: дії, виконані в редакторі

• neutralize.log: нейтралізація бази даних (тільки staging)

Коли до журналів додаються нові рядки, вони відображаються автоматично. Якщо прокрутити вниз, браузер автоматично прокручуватиметься кожного разу, коли додається новий рядок.

Ви можете призупинити процес отримання журналів, натиснувши кнопку (пауза) у верхньому правому куті. В іншому випадку процес зупиниться через п’ять хвилин. Ви можете перезапустити його, натиснувши кнопку (відтворити).

Резервні копії

Вкладка Резервні копії містить список доступних резервних копій для завантаження та відновлення, дозволяє виконати резервне копіювання вручну та імпортувати базу даних.

Продуктивна база даних автоматично резервується щодня. Зберігаються сім щоденних, чотири тижневі та три місячні резервні копії. Кожна резервна копія включає дамп бази даних, файлове сховище (вкладення та бінарні поля), журнали та сеанси.

Примітка

Ви можете звернутися до оціночного розкладу автоматичних резервних копій, щоб краще зрозуміти, як працює система. Цей файл оновлюється щодня, беручи поточний день за відправну точку.

Бази даних для тестування та розробки не резервуються автоматично. Однак ви можете відновити резервну копію продуктивної бази даних у ваших гілках для тестування або вручну відновити дані, які було випадково видалено з продуктивної бази даних.

Список містить резервні копії, які зберігаються на сервері вашої продуктивної бази даних. Цей сервер зберігає лише резервні копії за один місяць: сім щоденних і чотири тижневі резервні копії.

Виділені сервери резервного копіювання зберігають ті самі резервні копії, а також три додаткові місячні резервні копії. Щоб відновити або завантажити одну з цих місячних резервних копій, зверніться до служби підтримки Odoo.

При злитті коміту, що оновлює версію одного або кількох модулів (у __manifest__.py) або їхніх пов’язаних залежностей Python (у requirements.txt), Odoo.sh виконує автоматичне резервне копіювання (позначене типом Update у списку), оскільки або контейнер буде змінено встановленням нових pip-пакетів, або сама база даних буде змінена наступним оновленням модуля. У цих двох випадках запускається резервне копіювання, оскільки це може щось зламати.

Якщо злитий коміт не оновлює версію модуля або пов’язаних залежностей, то Odoo.sh не запускає резервне копіювання, оскільки ні контейнер, ні база даних не змінюються; тому платформа вважає це достатньо безпечним. Як додаткову запобіжну міру ви можете створити резервну копію вручну перед зміною продуктивних джерел.

Метою ручних резервних копій є створення конкретного знімка продуктивних баз даних або баз даних для тестування (недоступно для розробки). Вони залишаються доступними протягом семи днів. Однак існує обмеження в п’ять щоденних ручних резервних копій.

Етап	Автоматичне резервне копіювання	Ручне резервне копіювання
Виробництво	Так (до 3 місяців)	Так (3 дні)
Проміжне середовище	Ні	Так (3 дні)
Розробка	Ні	Ні

Функція Імпорт бази даних приймає архіви баз даних з:

• стандартного менеджера баз даних Odoo (доступний для локальних серверів Odoo за адресою /web/database/manager)

• менеджера баз даних Odoo Online

• вкладки Backups Odoo.sh (використовуючи кнопку (Download Options))

• перегляду Builds Odoo.sh (натиснувши Download DB dump)

Оновлення

Вкладка Upgrade може використовуватися для оновлення продуктивних гілок і гілок для тестування дійсних проектів. Для отримання додаткової інформації про процес оновлення зверніться до документації щодо оновлення.

Інструменти

Вкладка Інструменти містить профайлер коду. Він використовується для запуску сеансу профілювання, записуючи діяльність воркерів Odoo, що працюють в екземплярі, максимум протягом п’яти хвилин. Ви можете завершити сеанс раніше, оскільки коротша тривалість роботи інструменту зменшує кількість шуму у звіті.

Після кожного сеансу створюється інтерактивний flame graph, який допомагає візуалізувати, як воркери Odoo розподіляють свій час.

Попередження

Запуск профайлера споживає багато серверних ресурсів, тому уникайте його тривалої роботи. Мета — записати конкретну дію у вашій базі даних.

Налаштування

Вкладка Налаштування містить параметри конфігурації, доступні для поточної вибраної гілки. Параметри відрізняються для кожного етапу.

Поведінка при нових комітах

Ви можете змінити поведінку гілки при отриманні нового коміту для гілок розробки та стейджингу.

За замовчуванням гілка розробки створює новий білд, а гілка стейджингу оновлює попередній білд. Це корисно, якщо функція, над якою ви працюєте, потребує певної конфігурації, оскільки вам не потрібно буде налаштовувати її вручну після кожного коміту.

Якщо ви оберете Новий білд для гілки стейджингу, то щоразу при відправці коміту створюється нова копія продакшн-білда.

Гілка, яка переміщується зі стейджингу до розробки, автоматично встановлюється в Нічого не робити.

Встановлення модулів

Ви можете вибрати, які модулі мають встановлюватися автоматично для гілок розробки.

Щоб змінити стандартну поведінку, зніміть позначку з параметра Використовувати стандартне у розділі Поведінка білда розробки та виберіть один із наступних параметрів у розділі Встановлення модулів:

• Встановити лише мої модулі (не включає субмодулі): встановлює лише модулі гілки, виключаючи субмодулі. Це параметр за замовчуванням.

• Повне встановлення (без тестового набору): встановлює модулі гілки, субмодулі та всі стандартні модулі Odoo. При виконанні повного встановлення тестовий набір вимкнено.

• Встановити список модулів: встановлює вказані модулі. Для цього введіть їхню технічну назву та розділіть їх комами (наприклад, sale_management,website,accountant).

Примітка

Якщо тестовий набір увімкнено, встановлення всіх стандартних модулів Odoo може зайняти до однієї години.

Тестовий набір

Типово тестовий набір для гілок розробки увімкнено. Ви можете обмежити, які тести виконуватимуться, ввівши теги тестів та розділивши їх комами (наприклад, custom_tags,at_install,post_install).

Щоб повністю вимкнути тестовий набір, зніміть позначку Перевіряти тестовий набір під час нових збірок.

Версія Odoo

Ви можете змінити версію Odoo для гілок розробки, наприклад, щоб протестувати оновлений код або розробляти функції, поки ваша робоча база даних перебуває в процесі оновлення до новішої версії, вибравши іншу Версію.

Типово вибрано Остання як Ревізія, і вихідні коди вашого сервера Odoo оновлюються автоматично щотижня, щоб скористатися останніми виправленнями помилок, безпеки та продуктивності.

Щоб натомість вибрати конкретну ревізію, виберіть її за допомогою поля Ревізія.

Попередження

Ревізії втрачають чинність через три місяці. Ви отримаєте сповіщення електронною поштою, коли наблизиться дата закінчення терміну дії ревізії. Якщо ви не вжили жодних дій після закінчення терміну дії, поле Ревізія автоматично повертається до Остання.

Власні домени

Ви можете налаштувати додаткові домени <name>.odoo.com або власні користувацькі домени для всіх типів гілок.

Щоб використовувати власний користувацький домен, необхідно:

• Володіти або придбати доменне ім’я.

• Введіть доменне ім’я в розділі Користувацькі домени (наприклад, www.mycompany.com), потім натисніть Додати домен.

• Налаштуйте доменне ім’я (наприклад, www.mycompany.com) за допомогою менеджера доменних імен вашого реєстратора із записом CNAME, значення якого встановлено на доменне ім’я вашої робочої бази даних (наприклад, mycompany.odoo.com).

Важливо

Голі домени (наприклад, mycompany.com) не приймаються. Їх можна налаштувати лише за допомогою записів A, які приймають лише IP-адреси як своє значення. Тому голий домен може раптово перестати функціонувати, оскільки IP-адреса бази даних може змінитися (наприклад, після оновлення, апаратного збою, зміни місця розміщення бази даних).

Щоб працювали як ваш голий домен (наприклад, mycompany.com), так і домен www (наприклад, www.mycompany.com), необхідно перенаправити голий домен на домен www. Більшість менеджерів доменів надають спосіб налаштувати це перенаправлення, яке зазвичай називають веб-перенаправленням.

HTTPS/SSL

Якщо перенаправлення налаштовано правильно, SSL-сертифікат автоматично генерується за допомогою Let’s Encrypt протягом години, що означає, що ваш домен буде доступний через HTTPS.

Відповідність SPF та DKIM

Якщо домен ваших електронних адрес використовує протокол автентифікації SPF або DKIM, необхідно авторизувати Odoo як хост-відправник у налаштуваннях доменного імені, щоб підвищити доставність вихідних електронних листів. Для отримання додаткової інформації зверніться до документації Налаштування DNS-записів для надсилання електронних листів в Odoo.

Важливо

Якщо Odoo не авторизовано як хост-відправник, ваші вихідні електронні листи можуть бути позначені як спам.

Команди оболонки

У верхньому правому куті перегляду відображаються кілька команд оболонки. Команди можна скопіювати за допомогою кнопки буфера обміну, а потім використовувати в терміналі. Крім того, деякі з них можна використовувати безпосередньо з інтерфейсу Odoo.sh.

Клонувати

Команда clone використовується для створення локальної копії вашого Git-репозиторію.

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• --recurse-submodules для завантаження підмодулів вашого репозиторію

• --branch main для переходу до конкретної гілки репозиторію (наприклад, development)

Примітка

Кнопка запуску недоступна, оскільки команда використовується для створення локальної копії на вашій машині.

Форк

Команда fork використовується для створення нової гілки на основі поточної.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main команда для створення нової гілки (наприклад, development-1) на основі поточної гілки (наприклад, development)

• git push -u origin development-1 команда для завантаження нової гілки (наприклад, development-1) до віддаленого репозиторію

З’єднати

Команда merge використовується для об’єднання змін з однієї гілки в іншу гілку.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 команда для злиття змін поточної гілки в іншу гілку (наприклад, staging-1)

• git push -u origin staging команда для завантаження об’єднаних змін до гілки віддаленого репозиторію (наприклад, staging)

SSH

Команда SSH використовується для підключення до збірки за допомогою SSH.

Щоб використовувати команду SSH, спочатку необхідно налаштувати SSH-ключ. Для цього:

• Згенеруйте новий SSH-ключ.

• Скопіюйте SSH-ключ у буфер обміну.

• На Odoo.sh клацніть свого користувача GitHub у верхньому правому куті та виберіть Profile.

  

• Вставте SSH-ключ у поле Add a key manually та клацніть Add.

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 ідентифікатор збірки

• my-user-my-repository-staging-25004381.dev.odoo.com домен, що використовується для підключення до збірки

За умови, що ви маєте необхідні права доступу до проєкту, вам буде надано SSH-доступ до збірки.

Примітка

Довготривалі SSH-з’єднання не гарантовані. Неактивні з’єднання можуть бути розірвані для звільнення ресурсів.

Підмодуль

Команда submodule використовується для додавання гілки з іншого репозиторію до вашої поточної гілки як підмодуля.

Див. також

Документація підмодулів

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> команда для додавання конкретної гілки (наприклад, master) репозиторію (<URL>) як підмодуля за вказаним шляхом (<PATH>) у вашій поточній гілці.

• git commit -a команда для фіксації всіх поточних змін

• git push -u origin staging команда для завантаження змін поточної гілки (наприклад, staging) до віддаленого репозиторію.

Видалити

Команда delete використовується для видалення гілки з вашого репозиторію.

Примітка

Після видалення гілки немає можливості відновити її, якщо не існує резервної копії. Проміжні гілки не створюються автоматично в резервних копіях, але можуть бути створені вручну. Гілки розробки не можуть бути збережені в резервних копіях.

Example

git push origin :staging && git branch -D staging

• git push origin :staging команда для видалення конкретної гілки (наприклад, staging) у віддаленому репозиторії

• git branch -D staging команда для видалення конкретної гілки у вашій локальній копії репозиторію

Попередження

Перед видаленням гілки зверніться до розділу Резервні копії, щоб краще зрозуміти, як вони працюють і коли слід створювати резервну копію вручну.