Як Git допомагає впоратися зі сценарієм нижче:

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

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

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

Ваша перша галузь featureAготується до розгляду.

Ваша друга галузь featureBзнаходиться у стадії розробки та залежить від коду у featureAгалузі.

Об’єднайте featureAгілку у featureBгілку.

Якщо ви вносите зміни в featureAгалузі , то ви повинні об'єднати featureAфілія в featureBгалузі знову включити зміни.

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

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

Тримайтеся, пропускайте злиття

При такому підході ви не хочете об'єднувати своє feature_aв feature_bкілька разів.

Згадування згадувалося в інших відповідях, але тільки для того, щоб передати речі master. Що ви хочете зробити у вашому випадку:

• Почніть свій feature_bз feature_a, тобто:

  git checkout feature_a
  git checkout -b feature_b
  

• Кожного разу, коли feature_aзміни, поки він чекає, щоб masterви вступили feature_b в нього , ви перейдете на нього:

  ... commit something onto feature_a ...
  git checkout feature_b
  git rebase feature_a
  

• Нарешті, як тільки feature_aви об'єдналися master, ви просто отримуєте нове masterі перезавантажуєте feature_aйого в останній раз:

  git checkout master
  git pull origin master
  git checkout feature_b
  git rebase --onto master feature_a feature_b
  

  Ця остаточна база даних буде перенесена на всі комітети, які звисають від feature_aкомітету (який зараз не має значення, оскільки він був об'єднаний master) прямо на master. Ваша feature_bзараз проста, стандартна галузь, що йде прямо звідти master.

EDIT: натхненний коментарями, трохи піднімаючи голову: якщо вам потрібно внести якісь зміни, які впливають на обидві функції, то не забудьте внести це feature_a(а потім перезавантажити, як показано). Ви НЕ зробити це в двох різних фіксацій в обох гілках, навіть якщо може бути привабливим; як feature_aце є частиною історії feature_b, що матиме зміна двох різних комітетів, буде семантично помилковим і, можливо, пізніше призведе до конфліктів або "воскресіння" небажаного коду.

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

Типовий спосіб для відгалуження нової функції , щоб залишитися в синхронізації з master, щоб залишитися на вершині цього. Коли masterви змінюєтесь, ви зазвичай git fetch origin master:master && git rebase masterзнаходитесь у робочому каталозі своєї філії.

Те ж саме можна зробити і з іншою гілкою функцій: продовжуйте діставати її та перезавантажувати поверх неї.

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

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

Функціональна гілка, яка живе досить довго, потребує об'єднання змін із головним часом (щоб переконатись, що ви узгодили будь-які злиття чи семантичні конфлікти як частину розробки роботи над функціональною гілкою, а не як частина "огляду, qa, злиття- to-master "процес). Таким чином, ви робите це на передній гілці, і коли робота заднього сервісу буде прийнято до основного, ви отримаєте будь-які незначні зміни, які були внесені до бекенда в рамках його огляду / прийняття автоматично, тим самим маршрутом, який ви хотіли б отримати будь-які інші зміни коду на master.

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

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

Я не бачу тут проблеми.

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

Отже, у вашому конкретному прикладі ви спочатку створюєте feature_xxx_backendгілку та розробляєте зміни в заднім часі. Коли це буде зроблено, відділення буде переглянуто і буде об'єднано, masterколи огляд завершиться.

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

Коли feature_xxx_backendгілка змінюється, наприклад, тому, що під час огляду з’являються речі, на які потрібно звернути увагу, просто зробіть ці зміни та об'єднайте їх у feature_yyy_frontendгілку. Потім продовжуйте по передній гілці.

Як тільки огляд гілки резервного сервісу завершено, він об'єднується в master. На даний момент, було б доцільно , щоб перебазуватися в feature_yyy_frontendгалузі на master, так що рецензенти потрібно тільки розглянути нові зміни , які ця галузь вносить свій внесок в master, і не потрібно повторно переглянути зміни , зроблені для внутрішнього інтерфейсу (які вже були затверджені ).

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

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

Як згадував Polygnome, ви можете насправді об'єднати свою гілку фронта з вашою заднім відділенням замість майстрів. Навіть з поточним налаштуванням філії, яке ви зараз маєте, ви можете просто зробити:

git checkout frontend
git merge backend

або просто

git merge backend frontend

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

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

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

Щоразу, коли у вас є два набори великих змін, які ви хочете переглянути окремо (як-от featureAі featureB), створіть PR, який НЕ призначений для об'єднання, а для отримання раннього зворотного зв'язку про PoC featureA.

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

Потім ви можете продовжувати працювати над функцією A, створювати запит на витягнення для неї та відділення та працювати над функцією B.

Велика різниця полягає в тому, що зараз ви можете розраховувати featureAна те, що кардинально не змінитись: дизайн та підхід вже були затверджені. Огляд коду та необхідні зміни можуть бути тонкими та локальними, а не "wops, вам потрібен інший підхід". Це дозволить звести до мінімуму обсяг роботи , що вам потрібно зробити , щоб в подальшому об'єднати featureBна featureA«и коду, незалежно від методу ви вибрали.