Зізнаюся чесно: Git бив мене по обличчю стільки разів, що я вже збився з ліку. Щоразу, коли мені здається, ніби я нарешті налагодив процес випуску нової версії, Git кричить: «Не так швидко!» — і після двох джебів, лівого хука та аперкоту я вже лежу на рингу й намагаюся зрозуміти, що сталося. Гілки розійшлися, конфлікти вискакують, наче кроти в аркадній грі, а номери версій більше нагадують лотерейні квитки… Суцільний хаос.

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

Розповім, як я до цього дійшов.

Перші труднощі

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

Я системний архітектор і справді добре розумію цінність Git та його можливостей. Просто ніяк не міг збагнути, як використовувати його ефективно. Коли я вирушив у дивовижний світ гілок, гілок від інших гілок, злиттів… скажімо так, виступив не надто вдало. Усе йшло шкереберть, і поки я розгрібав наслідки, моя версія 0.15.0 перетворювалася на 0.15.8.

Переломний момент

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

Я задокументував його не лише в репозиторії, а й у своїй базі знань поза проєктом. Моя порада: якщо для документування керування випусками потрібно зробити ще один випуск, краще цього не робіть… серйозно.

Уроки з практики

Найбільшим відкриттям став сумнозвісний конфлікт під час оновлення версії в pyproject.toml. У main і гілці випуску були різні номери версій, і Git вимагав обрати один. Я навчився швидко помічати й розв’язувати такі конфлікти. Тепер змінюю версію лише в гілці випуску.

А ще stash — мій найкращий друг. Коли в main панував хаос, я тимчасово зберігав зміни в stash, робив злиття, а потім викидав stash, бо насправді ті локальні зміни мені були не потрібні. Не надто витончено, зате не раз рятувало шкуру.

Перемога

Нарешті, після повного тренувального проходження процесу — гілка функції, злиття з dev, гілка випуску, новий номер версії, злиття з main, тег і push — мені вдалося викласти все на GitHub та PyPI без жодного сюрпризу.

Найкраща мить? Створити нове віртуальне середовище, встановити свій пакет із PyPI й переконатися, що це саме той код, який я й хотів випустити. Ось воно, задоволення.

Поради колегам-розробникам

  • Почніть із простого, а потім поступово вдосконалюйте процес.
  • Зберігайте контрольний список випуску поза репозиторієм, щоб він залишався стабільним і доступним.
  • Не бійтеся злиттів або stash: Git — інструмент, а не тиран.
  • Автоматизуйте лише тоді, коли ручний процес уже працює бездоганно.

І не соромтеся попросити досвідченого користувача Git пройти цей шлях разом із вами.

Наостанок

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

Маєте власні бойові історії про Git? Із задоволенням послухаю.

Продовження

Згодом я написав ще одну, новішу статтю про Git, у якій розповів, як автоматизував цей процес.