Git робочий процес для невеликих команд


11

Я працюю над робочим процесом git, який потрібно впровадити в невеликій команді. Основні ідеї в робочому процесі:

  • Є спільний майстер проекту, на який можуть писати всі члени команди
  • Вся розробка здійснюється виключно на особливих галузях
  • Гілки функцій коду переглядає член команди, який не є автором філії
  • Гілка функцій з часом об'єднується в спільний головний і цикл починається заново

У статті детально пояснюються етапи цього циклу:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Це має сенс чи я щось пропускаю?

Відповіді:


16

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

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


Як я розумію, це git flow та безперервна інтеграція - це альтернативні способи роботи, і їх реально не можна поєднувати. У потоці git код об'єднується в розробку лише тоді, коли функція завершена. При постійній інтеграції весь код об'єднується в спільну гілку принаймні один раз на день, навіть якщо він не надає будь-якої нової функції негайно.
— bdsl

7

Думаю, вам не вистачає теми Неперервна інтеграція. Він повинен бути частиною кожної програми розробки.

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

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

Ще одна альтернатива - встановити збірки CI для кожної гілки функцій. Це точно допомагає, але це не інтеграція. Це стає очевидним, коли ви знайдете свою першу помилку, яка не з’являється в Feature A і Feature B, але в момент, коли ви інтегруєте Feature A&B

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


Головну гілку можна з'єднати з CI, щоб відхилити об'єднання гілок функцій, якщо вони не виконають автоматизовані тести нерегресії. Дякую за підказку, я додам розділ "Поради" наприкінці і згадаю про це там.
— janos

1
Звичайно, але, як було сказано, це не суцільна інтеграція, а інтеграція в кінці функції, яка може бути хорошою, але це не те саме
— Jens Schauder

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

Автоматизований процес збирання, який працює за графіком (система CI), незамінний. Її потрібно запускати часто, щоб проблеми з компіляцією можна було швидко знайти та виправити. Команди розробників повинні надавати збої в побудові найвищим пріоритетом. Виправити подібні проблеми набагато простіше, коли вони з'являються на першому місці.
— Натан Піллінг

1
Для наших проектів, які використовують CI (у нас є декілька застарілих проектів, які наразі не можуть використовувати його), ми зобов'язуємось ВСЕМЕ майструвати справжній CI, для наших застарілих проектів ми використовуємо модель розгалуження git flow. Гілки функцій - це блокатор ІС, якщо ви запитаєте мене, вони ускладнюють НЕПРОТИГАЛЬНУ (не тільки після завершення) інтеграцію. Ми продовжуємо працювати над функціями, і остаточне завдання - це ввімкнути його в основному, але код завжди в проекті.
— Елліот Блекберн

1

Ви можете надихнутися gitflow або Twgit .

gitflow підсумовує свій підхід як:

Розширення Git для забезпечення операцій із сховищами високого рівня для моделі розгалуження Вінцента Дріссена.

Twgit описує себе так:

Twgit - це безкоштовний та відкритий джерело допоміжних інструментів для управління функціями, виправленнями та випусками у сховищах Git. Він пропонує прості команди високого рівня для прийняття моделі розгалуження, описаної в нашій документації. Підтримувана ОС: Debian / Ubuntu Linux, Mac OS X.

Обидва інструменти доступні від github .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.