Стратегія перегляду коду перед об'єднанням в майстер з галузевих функцій

Я та моя команда використовуємо функції філій (з git). Мені цікаво, яка найкраща стратегія для перегляду коду перед об'єднанням у майстер.

1. Я перевіряю нову гілку від майстра, давайте називати її fb_ # 1
2. Я кілька разів беру на себе зобов’язання, і тоді хочу повернути його до головного
3. Перш ніж об'єднати, хтось повинен зробити перевірку коду

Зараз є 2 можливості:

1-й

1. Я зливаю майстер до fb_ # 1 ( не fb_ # 1 для майстра), щоб зробити його якомога актуальнішим
2. Командник перевіряє зміни між головним керівником та fb_ # 1 головою
3. Якщо fb_ # 1 гаразд, ми об'єднуємо fb_ # 1 в master
4. Плюси: немає застарілого коду в огляді
5. Мінуси: якщо хтось інший об'єднує щось середнє між "1." і "2." його зміни з’являються в огляді, хоча вони належать до іншого огляду.

2-й

1. Командний команда оглядає зміни між пунктом оформлення замовлення (майстер злиття бази git fb_ # 1) та головкою fb_ # 1
2. Плюси: ми точно бачимо, що було змінено під час роботи над функцією
3. Мінуси: в огляді може з’явитися деякий застарілий код.

Який спосіб ви вважаєте кращим і чому ? Може бути, є ще один підхід?

Варіант першого варіанту:

1. приєднайте майстер до fb_ # 1 (не fb_ # 1 до головного), щоб зробити його максимально актуальним
2. Партнер по команді переглядає зміни між майстром у точці, яку ви злили, та головою fb_ # 1
3. Якщо fb_ # 1 гаразд, ми об'єднуємо fb_ # 1 в master
4. швидко перевірте, чи є злиття нормальним

напр.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

де:

• ma - родоначальник господаря і fb_ №1.
• fn - остання зміна у вашій галузі
• mm - комісія, яка була майстром / HEAD у той час, коли ви злилися на вашу гілку (даючи fm ).

Отже, ви порівнюєте mm та fm у своєму первинному огляді, а потім швидко перевіряєте після об'єднання назад mf, щоб переконатися, що нічого важливого не змінилося на master під час кроків 1-3. Здається, це має всі плюси і жоден з мінусів для первинного огляду.

Це передбачає, що огляд швидкий порівняно із звичайною частотою змін, що підштовхуються до головного, тому fm -> mf часто буде швидким вперед.

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

3-й

• Ви перезавантажуєте гілку на майстер, щоб вони були оновлені та зберігали зміни окремо.

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

• Ви використовуєте інтерактивну базу даних ( git rebase -iі git commit --amend) для впорядкування, редагування та очищення змін, щоб кожна з них була логічно закритою зміною.

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

• Плюси:

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

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

Так роблять Linux і Git. І незвично бачити, що серії з 20 до 25 патчів надходять на огляд і кілька разів переписуються в цих проектах.

Насправді Linux робив це з самого початку проекту, коли їх контролем вибору версій були тарілки та патчі. Коли через багато років Лінус задумався створити git, це було головною причиною реалізації rebaseкоманди та її інтерактивним варіантом. Також через це git має окреме поняття автора та виконавця . Автор - це той, хто вперше створив редакцію, і хто останній торкнувся її. Оскільки в Linux та Git патчі все ще надсилаються електронною поштою, вони майже ніколи не є однією людиною.

Насправді є третя можливість - і, швидше за все, багато інших, оскільки GIT - це скоріше реалізація рамки СКМ, ніж реалізація методології СКМ. Ця третя можливість заснована на rebase.

rebaseСубкоманди GIT приймає серію фіксації ( як правило , від вашої точки розгалуження на кінчик теми гілки topic) і відтворювати їх в іншому місці ( як правило , на кінчику інтеграції галузі, наприклад master). rebaseСубкоманди виробляє нові коммітов, що дає можливість перегрупування фіксацій в формі , яка легше огляд. Це дає нову серію зобов’язань, подібну до тієї, що topicраніше, але з'являється укоріненою у верхній частині галузі інтеграції. Ця нова гілка все ще називається topicGIT, так що стара посилання відкидається. Я неофіційно маркую topic-0початковий стан вашої філії topic-1та ін.

Ось моя пропозиція щодо вашої topicфілії:

1. (Необов’язковий крок) Ви інтерактивно базуєте свою гілку теми topicна її точці розгалуження (див. --fixupПараметр для commitта опції -iта --autosquashпараметри rebase), що дає можливість переписати свої комісії легшим способом перегляду. Це призводить до галузі topic-1.

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

3. Надішліть topic-2товариша по команді, який розглядає його проти кінчика master.

4. Якщо topic-2це нормально, то з’єднайте його з головним.

ПРИМІТКА Гілки, де гілка посилається на дерево фіксації, всі будуть називатися GIT однаково, таким чином, в кінці процесу, лише гілка topic-2має назву в GIT.

Плюси:

• Немає застарілого коду в огляді.
• Немає помилкових відгуків про «злиття іноземних зразків» (явище, яке ви описали у першій частині).
• Можливість переписати твори чистим способом.

Мінуси:

• Замість однієї галузі topic-0, є три гілки артефакти topic-0, topic-1і topic-2які створені в фіксації дерева. (Хоча в будь-який час лише одна з них має ім’я в GIT.)

У вашому 1-му сценарії «якби хтось об'єднав щось середнє між« 1. » і "2." »позначається на часовий проміжок між створенням точки розгалуження та часом, коли ви вирішили об'єднатись. У цьому сценарії «якби хтось об'єднав щось середнє між« 1. » і "2." »стосується часу, що перебуває між базою даних і об'єднанням, яке зазвичай дуже коротке. Таким чином, у наданому нами сценарії ви можете «заблокувати» masterгілку на час злиття, не порушуючи істотно робочий процес, хоча в 1-му сценарії це недоцільно.

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

Управління проміжними артефактами гілок представляє лише труднощі, якщо ви поділите їх між сховищами.