Новий розробник не може бути в курсі злиття філій

Я новий розробник - це моя перша позиція програмування.

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

Як я це долаю? Чи є така тактика, яку я можу використати, окрім "бути кращим у кодуванні"? Я маю намір викласти це з моїм керівником на наступному тижні.

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

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

Щоб змінити менше рядків самостійно, переконайтеся, що вносите лише зміни, пов’язані зі своїм завданням.

Якщо вам потрібно експериментувати з різними способами досягнення своєї мети, можливо, деякі ваші експерименти змінили лінії, які насправді не потрібно змінювати? Скасуйте ці зміни перед об'єднанням.

Також є кілька команд Git, які допоможуть вам змінити якомога менше рядків:

• git diffі git diff --stagedпобачити, які рядки ви змінили.
• git add -p щоб додати лише деякі зміни у файл.
• git commit --amendі git rebase -iналаштувати комісії, які ви вже зробили у вашій локальній гілці функцій, перш ніж пересилати їх до інших сховищ Git.

(Зміна в кілька рядків , як можна також зробити його простіше розглянути роботу або використовувати інструменти , які працюють на відмінностях між роблять такі як git cherry-pick, git rebase, git bisectі git blame.)

Але навіть якщо ви зменшите ймовірність конфліктів злиття, ви все одно іноді будете стикатися з конфліктами злиття. Тому не бійтеся їх, але навчіться вирішувати конфлікти.

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

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

Я досить досвідчений розробник, і мені ще потрібно зовсім небагато часу, щоб набрати швидкість для нового проекту. У вашому випадку це здається, що у вас є кілька людей, які працюють над одним проектом одночасно, тож це або дуже великий проект, або новий проект, який швидко розвивається. В будь-якому випадку не хвилюйтеся, якщо вам знадобиться кілька місяців, щоб потрапити в потік. Якщо я переключаю проекти на 2 або 3 тижні, а потім перемикаюсь назад, це може зайняти кілька годин (а то й день-два), щоб повністю «повернутися» в проект, який я написав на 100% самостійно!

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

Редагувати:

Або використовувати merge. Це теж варіант. Отже, вищезгаданим було б: "використовувати git rebase -i( -iзасоби інтерактивні) або git merge". Щодо того, який саме використовувати, поговоріть про це з рештою своєї команди. Вони можуть (або не можуть) мати сильні переваги в будь-якому випадку. Зрозуміло , що деякі люди дійсно мають сильні переваги.

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

Прийняті відповіді. Я думаю, що це більше технічний характер "як краще використовувати Git", я думаю, що це скоріше проблема команди, ніж проблема інженерії чи інструментів.

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

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

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

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

Найважливіше при злитті - це тим, що чим довше ви чекаєте, тим більше болісно. І проблема зростає більше, ніж лінійна. Втричі більше конфліктів - це дев’ять разів більше роботи. Є кілька стратегій:

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

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

Порадьтеся з колегами щодо стратегій уникнення конфліктів. У вас виникають конфлікти, якщо двоє людей редагують один і той же код. Не просто той самий файл, а той самий код. Тому мені потрібна нова функція functionA, і вам потрібна нова функціяB, і ми обидва додаємо її в кінці того самого файлу, у нас конфлікт. Якщо ми додамо його в різних місцях, конфлікту немає. Якщо ми обидва додаємо його у файлі, де він логічно належить, швидше за все, у нас немає конфлікту.

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

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

На той момент я готовий об'єднати свою гілку назад у розвиток (акцент мій)

Поводження з конфліктами в git mergeРосії часто простіше, ніж в Росії git rebase. У Git merge ви можете побачити весь список файлів, які були змінені одразу. Незалежно від того, скільки комісій було зроблено іншими колегами, вам доведеться один раз злитися . З робочим процесом ребазування у вас можуть виникати однакові конфлікти знову і знову, і вам доведеться їх переглядати вручну. Ви можете закінчити фіксацію 13-ї комірки і відчуєте, що не можете побачити світло з тунелю .

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

Я запропоную вам кілька методів, але вони можуть лише допомогти злиття отримати легше, ніж автоматизувати завдання.

• Ресурсні / мовні файли . Якщо у вас є додаткові зміни до файлу ресурсу, переконайтеся, що ви завжди переміщуєте їх до кінця файлу, щоб ви могли легко згадати свої зміни проти інших змін. Можливо, ви зможете скопіювати та вставити зміни знизу або просто видалити маркери конфлікту
• До. Ні. АБСОЛЮТНО RE-формат . Ні ви, ні ваші колеги-розробники не повинні виконувати "масове переформатування коду" під час щоденної роботи. Переформатування коду додає надмірну кількість помилкових позитивних результатів в управлінні конфліктами. Переформатування коду можна зробити
  • Поступово, наприклад, кожен розробник на кожній комісії, як тільки він використовує автоматизований інструмент (наприклад, у Eclipse є можливість переформатувати на збереження, у vanilla Visual Studio немає). Абсолютно кожен розробник повинен використовувати однакові стандарти форматування коду, закодовані у форматний файл, який їсть ваш IDE. Щоб дати вам уявлення, якщо це 4 пробіли або 2 вкладки, це не має значення, але це дійсно важливо, якщо всі використовують одне і те ж.
  • Незадовго до звільнення керівник команди. Якщо "переформатування коду" відбувається, коли люди не працюють на галузях, тобто перед тим, як вони розгалужуються, все полегшиться
• Перегляньте поділ роботи між колегами. Ця частина є частиною, куди надходить більшість інженерій. Як вказують інші відповіді, це дизайн запаху, якщо кілька розробників, які виконують різні завдання, повинні торкатися одних і тих же ресурсів. Можливо, вам доведеться обговорити з вашим керівником команди про те, яку частину повинен змінювати кожен одночасно розробник.

Я також бачив деякі шкідливі звички в робочих процесах Git у своїх командах. Часто люди переборюють у своїх відділеннях. Я особисто був свідком розробника, який додав 10-20 комісій з позначкою "виправити", кожен з яких здійснював один або два рядки. Наша політика полягає в тому, що комісії мають маркування квитків JIRA, щоб дати вам уявлення.

@JacobRobbins пропонує зробити git rebaseщоденне завдання. Я хотів би просунути його підхід вперед.

По-перше, використовуйте rebase один раз просто, щоб зменшити кількість комісій до пригорщі. І базуйтесь лише на початковій гілці розробки, яка є зобов'язанням, від якого ви розгалужилися. Коли я скажу кілька, я можу мати на увазі 3 або 4 (наприклад, весь передній, весь задній, всі виправлення бази даних) або будь-яку розумну цифру. Після того як ви їх об'єднали, використовуйте fetchта працюйте зі своєю базою даних над гілкою вище. Це не позбавить вас від конфліктів, якщо ваша команда не перегляне власний підхід, але зробить ваше життя менш болючим.

Якщо у вас є додаткові запитання щодо конкретних завдань, сміливо шукайте і запитайте на Stackoverflow.

[Редагувати] про правило без переформатування та хлопця-розвідника. Я трохи переформулював RE-формат, щоб підкреслити, що я маю на увазі завдання форматування з нуля всього вихідного файлу, включаючи код, який ви не торкалися. На противагу завжди форматуванню власного коду, який ідеально підходить для хлопців, ряд розробників, в тому числі і я, використовуються для переформатування всього файлу за допомогою можливостей IDE. Коли файл торкнеться інших, навіть якщо зачіпані рядки не змінені у своєму змісті та семантиці, Git сприйме це як конфлікт. Лише дуже потужний мовний редактор може припустити, що конфлікт пов'язаний лише з форматуванням та автоматичним злиттям найкращого форматованого фрагмента. Але я не маю доказів такого інструменту.

Зрештою, правило хлопчиків-розвідників не наказує вам чистити чужий безлад. Просто твій.

По-перше, не думайте про відмову від змін. Ви втратите можливості вивчити процес злиття.

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

Якщо конфліктів занадто багато, ваше завдання може бути другорядним, але повторюваним. Спробуйте знайти візерунок. Це допоможе у вирішенні конфліктів клієнтськими інструментами Git UI. Я використовую TortoiseGit. Це допомагає в злитті.

А щоб уникнути в майбутньому,

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

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

Вам слід регулярно (щодня) виконувати команду "git fetch" (не git pull) зі своєї галузі розвитку. Це призведе до змін інших людей і введе їх у вашу галузь функцій, не намагаючись інтегрувати зміни у вашу гілку.

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

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

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

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

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

Це звучить як ідеальний сценарій для парного програмування !

Детальніше про переваги та базові підходи:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

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

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

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

Сидіти з більш швидким, досвідченим розробником може допомогти:

• Це, швидше за все, зменшить конфлікти злиття, оскільки робота з кимось досвідченим збільшуватиме час завершення, а не окрему роботу
• Оскільки вони навчатимуть вас, швидше за все, вони будуть повільнішими, ніж вони працюватимуть поодинці, тому все ще можуть виникнути конфлікти злиття, і таким чином можна працювати з ними з кимось приправленим, і, можливо, підберіть поради щодо економії часу тощо
• Допоможіть побачити потенційні хитрощі та способи бути швидшими (хоча повільність іноді просто просто відсутність досвіду, а не відсутність належних практик)
• Можна відразу задавати питання, коли щось не має сенсу чи не на 100% зрозуміло
• Робота 1: 1 цінна для навчання, тому що людина, до якої ви попросили допомоги, вже розуміє точний код та сценарій, коли вони над цим працюють, без парного програмування ви повинні пояснювати код та сценарій, що часто закінчується проблемою і тож ви втрачаєте їх час / увагу на те, щоб отримати фактично потрібні поради
• Познайомтеся з мислительним процесом того, хто досвідченіший і досвідчений, і при хорошому спілкуванні ви, безсумнівно, дізнаєтесь нові речі

Чи є така тактика, яку я можу використати, окрім "бути кращим у кодуванні"? Я маю намір викласти це з моїм керівником на наступному тижні.

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

Тут є кілька основних проблем. Ваші проблеми з об'єднанням, швидше за все, не є вашою виною і частіше є симптомом поганих практик.

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

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

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

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

5) Можливо, у вас немає стійких стандартів форматування коду. Якщо ви не всі послідовно використовуєте одне і те ж форматування коду, ви отримаєте багато різних конфліктів для одного і того ж коду. Залежно від того, як налаштовано ваш git, вони навіть можуть зводитися до конфліктів пробілів (закінчення рядків, відступи, вкладки та пробіли).

6) Люди можуть підштовхувати свої зміни безпосередньо до галузі розвитку.

Ось що ви можете зробити: 1) Якщо ви не можете об'єднатись у розвиток щодня, злиття / відновлення розвиваються у вашу галузь щодня (або частіше).
2) Намагайтеся, щоб ваш код був відокремлений від коду інших.
3) Порадьтеся з іншою командою про менші функції, узгоджені стандарти кодування та кращу організацію коду (менші файли, менші функції).

Насправді здається, що простіше зняти свою роботу і почати все із завдання, що, звичайно, не є стійким рішенням)

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

Я також вважаю, що коли я переробляю трохи роботи, я пишу кращий код .....

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

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

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

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

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

1. Завдання розділити самостійно:

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

2. Об'єднайте часті детальні деталі:

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

3. Часто обмінюйте свою філію:

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

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   Це поки що найкорисніша команда git для мене в житті розвитку.

4. Тісно співпрацюйте з товаришами по команді:

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

5. Звикайте з параметрами git:

   Використовуйте потужність інструментів злиття git. Існує багато зручних способів вирішення конфліктів під час злиття. Стратегії об'єднання іноді можуть дуже допомогти. Будьте звикли і безстрашно виконайте команди git.