огляд коду за допомогою git-flow та github


43

За допомогою регулярних git та github я можу зробити перевірку коду, просто створивши запит на виклик гілки функцій, над якою працюю до гілки master. Як я можу робити огляди коду за допомогою git-flow? З робочим процесом, як "закінчення функції git flow", я плутаюся в тому, де насправді відбувається перегляд коду і як git-flow або git можуть полегшити цей огляд.


Ви можете заглянути в геррі, хоча я не впевнений, як він добре поєднується з git-flow. У будь-якому випадку, який процес роботи вашої команди ?
OnesimusUnbound

Відповіді:


29

Ми натрапили на цю точну проблему нещодавно. Нам дуже подобається git flow, оскільки він використовує хороший семантичний рівень (використовуючи той самий рівень, який ви використовуєте в командній дискусії: "Я почну функцію A" більше, ніж "я створю гілку, оформити замовлення"), git - це дуже "рівень" впровадження (який також хороший і корисний, але різний).

Проблема у нас полягає в тому git feature finish, як ми об'єднуємо гілку в розробку, тоді як ми хочемо, щоб рецензент був надісланий і (це важливо) об'єднав рецензент , а не комітет, щоб наголосити на власності команди.

Наше поточне рішення:

  1. Хтось використовує git flow для створення гілки функцій
  2. Закінчивши, він створює запит на витяг (використовуючи github)
  3. Огляд проходить з можливими додатковими зобов’язаннями
  4. Запит на витяг об’єднується за допомогою рецензента GitHub .
  5. Немає завершення функції git flow (оскільки гілка вже об'єднана)

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


3
Як щодо створення філії випуску? Що відбувається з тегами?
E-Riddie

16

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

  1. Створіть галузь функції: git flow feature start module_1
  2. Код оновлюється у відділенні функції
  3. Після внесення змін вони пересуваються до GitHub (або один раз в кінці, якщо бажано)
  4. Коли функція завершена, у GitHub порівнянні developта гілці функцій відкривається запит на витягmodule_1
  5. Команда розглядає запит на витяг та робить коментарі
  6. Будь-які зміни від запиту на виклик вносяться у відділення функції
  7. Після включення всіх змін у гілку функції, гілка функції закінчена: git flow feature finish module_1
  8. developФілія виштовхується GitHub (GitHub буде автоматично маркувати запит тягне , як замкнутий / зливалися , коли це станеться)

Зазвичай весь цей процес виконується оригінальним автором, але це не потрібно. Будь-хто з нашої команди може вступити та взяти цей процес у будь-який момент. Все, що їм потрібно зробити, - це перевірити функціональну галузь і продовжувати процес. Хто коли-небудь працює, git flow feature finish module_1буде розкішно видаляти локальну гілку функцій, але всі, хто перевірив цю гілку, повинні зробити це вручну, якщо хочуть використовувати щось подібне git branch -D feature/module_1.

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


Дякую за цю відповідь. Я не усвідомлював, що git позначатиме закритий піар після злиття.
vicTROLLA

3

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

Під час використання Gerrit сам Gerrit стає центральним сховищем (у ньому є вбудовані SSH та HTTP-сервери, які дозволяють користувачам взаємодіяти з ним в основному таким же чином, як вони є). Під час використання Gerrit робочий процес стає:

  1. Розробник вносить зміни в будь-яку галузь, здійснює місцеві дії.
  2. Розробник підштовхує ці зміни до Герріта.
  3. Герріт створює елементи рецензії, щоб інші могли їх переглядати.
  4. Колеги переглядають код, коментуючи та приймаючи чи відхиляючи зобов’язання.
  5. Коли комісія прийнята, то Герріт робить ті зміни, доступні для інших, щоб витягнути з гілки.

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

Це добре працює з git-flow (або будь-якою іншою схемою розгалуження), оскільки Gerrit підтримує перегляд змін, внесених на будь-якій гілці.


3

Ось ще одна пропозиція.

  1. Виконайте регулярний процес руху git, щоб створити функцію , але не доробляйте її та не зливайте її.
  2. Створіть запит на витяг , але не зливайте його. Зачекайте, поки утверджуючий залишить коментар. У коментарі є знак схвалення.
  3. Зробіть завершення потоку git . (Або затверджувач, або розробник може це зробити, залежно від того, про що погодилась команда.) Запит на вилучення буде позначений як об’єднаний на github. Ще потрібно видалити гілку за походженням.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.