Як обговорювати злиття конфліктів англійською мовою

Конфлікти злиття є рутинною частиною спільної розробки, але їх розв’язання часто вимагає короткої розмови з колегою по команді - і ця розмова проходить швидше з точним словником того, що насправді конфліктує і чому. Цей посібник охоплює англійську мову для обговорення конфліктів злиття чітко, замість того, щоб просто сказати « there’ s a conflict, can you look? »

Ключовий словник

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

• « Конфліктуючий шматок — це лише підпис функції — решта файла була об’ єднана автоматично без будь- яких проблем. » *

** Семантичний конфлікт ** — ситуація, коли дві зміни об’ єднуються чисто на текстовому рівні, але все одно розриваються під час об’ єднання, оскільки вони роблять несумісні припущення щодо поведінки коду. “Git не позначив це як конфлікт, але це семантична конфлікт — ваша зміна припускає, що функція все ще повертає рядок, але моя зміна змусила її повернути об’єкт.”

Our vs. theirs — Терміни Git для двох версій, які об’єднуються: “ours” - це гілка, в яку ви об’єднуєтесь, “theirs” - це гілка, в яку об’єднуєтесь, розрізнення, яке легко отримати назад. “У цьому перебазуванні, « їхні » насправді відноситься до моїх початкових звітів, а не до звітів іншої людини — мітки « наші/ їхні » перевертаються під час перебазування порівняно з об’ єднанням.”

** Конфлікт перебазування проти злиття ** — відмінність у тому, як виник конфлікт, оскільки розв’ язання конфлікту під час перебазування може вимагати повторення розв’ язання у декількох звітах, на відміну від одного конфлікту злиття.

• “Це конфлікт перебазування, а не конфлікт злиття, отже, якщо ті ж самі рядки конфліктують у декількох зведеннях, нам може знадобитися розв’ язати його більше одного разу, оскільки перебазування продовжується.” *

** Розв’ язання конфлікту ** — дію вручну редагування конфліктного шматка для створення остаточної, правильної об’ єднаної версії, після чого файл буде перенесено на наступний етап, щоб позначити його як розв’ язаний. “Якщо ви завершили розв’ язання конфлікту, не забувайте запустити команду git add на файлі перед продовженням перебазування.”

Звичайні фрази

• «Існує конфліктний шматок у конфігурації файлу — виглядає, що ми обидва торкнулися трьох однакових рядків»
• Це не конфлікт Git, але я думаю, що це семантичне конфлікт — чи ваша зміна прийняла старий тип повернення?
• Яка версія повинна бути тут — ваша, моя, чи комбінація обох?»
• “Ми вирішуємо це як частину злиття або перебазування? Це змінює те, як ми з цим поводимося, якщо це повторюється»
• “Можете перевірити мою резолюцію? Я хочу переконатися, що я не випадково не впустив твої гроші»

Приклади висловлювань

Позначити конфлікт для співробітника команди: “У нас є конфліктний шматок в auth.ts — здається, що ми обидва змінили логіку оновлення токенів приблизно в той же час. Чи є у вас кілька хвилин, щоб пройти через це разом, щоб ми не втратили жодної зміни?»

Опис семантичного конфлікту, який не було враховано Git: “Git об’єднав це чисто, але я думаю, що є семантична конфліктність — ваш PR змінив API, щоб повертати null замість throw, але мій код все ще має try/catch, очікуючи стару поведінку. Ми повинні оновити мою, щоб вона відповідала.»

Підтвердження роздільної здатності перед надсиланням:

• « Я розв’ язав конфлікт, зберігши вашу логіку перевірки і змінивши повідомлення про помилку — чи не могли б ви швидко переглянути це перед тим, як я надіслаю, щоб переконатися, що я правильно об’ єднав їх? » *

Професійні поради

• Ви можете сказати ** « conflicting hunk » **, щоб вказувати на конкретні рядки, які зазнали змін, замість того, щоб сказати « there is a conflict in the file », що може означати будь- що, від одного рядка до всього файла.
• Визначте і вкажіть назву ** семантичних конфліктів ** — вони є більш небезпечними, ніж конфлікти, позначені прапорцем Git, оскільки вас не попереджають автоматично, а для їх виявлення потрібна реальна розмова.
• Перевіряйте двічі значення ** ours/ theirs ** перед описом розв’ язання, особливо під час перебазування, оскільки позначки не означають те, що більшість людей вважає.
• Завжди пропонувати ** подвійну перевірку ** при нетривіальному розв’ язанні конфлікту — розв’ язаний конфлікт, який беззвучно відкидає зміну співробітника команди, є поширеною і важко помітною помилкою.

Практичні вправи

1. Напишіть повідомлення з двох речень, в якому вкажете на конфліктний момент і запропонуєте співробітнику швидко зв’ язатися з вами.
2. Напишіть одне речення, яке описує семантичне протиріччя, яке Git не виявив автоматично.
3. Напишіть речення, у якому ви просите члена команди двічі перевірити розв’ язання конфлікту перед тим, як ви його надсилаєте.

Навигація Нуанс: Специфічний словник для вирішення конфліктів

Ефективне обговорення конфліктів злиття не просто про те, що є проблема; це про те, щоб передати як ви бачите рішення і продемонструвати спільний підхід. Для людей, для яких англійська мова не є рідною, оволодіння певною термінологією може суттєво поліпшити вашу здатність впевнено брати участь у цих обговореннях. Давайте розглянемо деякі фрази, які виходять за рамки простого сказання «Є конфлікт»

Одна з ключових областей описує природу розбіжностей. Замість нечіткого «Це не працює», спробуйте сформулювати це більш точно. Наприклад, якщо ви ввели нову змінну, яка вступає в конфлікт з існуючою, ви можете сказати: “Я додав поле user_id до моделі Customer. Це вводить потенційний конфлікт, тому що попередня версія використовувала поле customerId. Здається, що нам потрібно вирішити, яка конвенція іменування є кращою для цих даних. “Зауважте, як це використовує технічні терміни - user_id, customerId, Customer модель - але обрамляє її як питання переваги, сприяючи діалогу, а не конфронтації. Інша корисна фраза - це “перетинаючи функціональність”, що стосується того, коли дві різні гілки реалізували одну і ту ж функцію трохи різними способами. Це уникає обвинувачувальної мови і підкреслює технічну проблему.

Крім того, навчіться чітко пропонувати рішення. Не просто скажіть « Розв’ яжу це ». Замість цього, надайте конкретну пропозицію: « Я пропоную зберегти поле customerId для зворотньої сумісності, поки я оновлюватиму свій код, щоб використовувати user_id в майбутньому. Після цього ми зможемо створити скрипт міграції для обробки переходу. » Це показує, що ви розглянули наслідки і активно пропонуєте шлях уперед. Аналогічно, відповідаючи на пропозицію товариша по команді, визнайте їхню точку зору: «Це хороша точка про підтримку зворотної сумісності. Давайте розглянемо цей варіант далі. » Використання таких фраз, як «Давайте розслідуємо», «Чи можемо ми розглянути», або «Що, якщо ми…» показує, що ви відкриті до співпраці і готові адаптувати свій підхід на основі обговорення.

Нарешті, будьте уважні до тону в письмовому спілкуванні - особливо Slack повідомлення або PR описи. Уникайте мови, яка може звучати вимогливо або відверто. Фрази на кшталт “Будь ласка, виправте це” можуть бути сприйняті як критично. Замість цього виберіть « Чи могли б ви глянути на цей конфлікт і запропонувати рішення? » Це ввічливо, професійно і запрошує до співпраці. Пам’ятайте, що мета полягає не в тому, щоб виграти суперечку, а знайти найкращий шлях вперед як частина команди.