Новости программы Industrial Software Engineering
Укажите свой email для того чтобы получать полезные материалы по индустриальной разработке программного обеспечения
Новости программы Industrial Software Engineering
Укажите свой email для того чтобы получать полезные материалы по индустриальной разработке программного обеспечения

Мержи и конфликты в IntellijiIdea

Мержи и конфликты в IntellijiIdea. Возникновение конфликтов и способы их разрешения.
Часто бывает такая ситуация, когда вы мержите ветки, когда вы их сливаете, у вас происходит что-то страшное - непонятный конфликт, какие-то странные "закорючки" у вас в файле, вы не понимаете, как что-то делать, добавляете какие-то изменения, вызываете sudo для гарантии, чтобы все точно заработало. Часто конфликты вызывают много паники у людей. Но конфликт - это не что-то страшное и чудовищное. Конфликт - это нормальная ситуация. Она говорит только о том, что в двух наборах исходников, которые вы хотите смержить, git не знает как это сделать в каких-то конкретных местах. Алгоритм в git достаточно умный, то есть он может ранжировать изменения относительно друг друга, совмещать, сливать, но он не всесилен. Часто бывает так: в одной ветке вы создаете файл с названием HelloKitty, и в другой ветке создаете такой же файл, но пишете в нем что-то другое. Получился готовой конфликт, git не знает как это смержить. Ему под одним и тем же именем абсолютно разные изменения предлагают, которые с его точки зрения равноправны, и он не понимает изменения, у которых нет пересечений. Поэтому он создаст конфликт и скажет :"А что вы хотели этим сказать? Как нам это смержить?" Конфликтов не нужно бояться, их можно всегда разрешить и получить решение, которое работает. И с честью выйти из этой ситуации!

Есть такой принцип, который я рекомендую вам использовать. Он состоит в том, что конфликты разрешает автор ветки, которую вливают. Например, если вы хотите влить мастер ветку Петя, то Петя должен позаботиться о том, чтобы не было конфликта. Петя должен подтянуть в свою ветку актуальный мастер, его себе смержить и убедиться, что у него конфликтов нет. Как вы думаете, почему именно Петя должен это сделать? Почему именно автор изменений? Потому что он понимает как работают его изменения и как проверить, что они не сломались. Представим, что я Петины изменения заливаю, то я не знаю что он добавил, я это не писал, я не знаю, как это правильно работает. У меня произошел конфликт в git. Я это как-то смержил, но свою часть я могу проверить, а Петиты изменения - это для меня "темный лес". Поэтому важно, чтобы конфликт исправлял тот, по чьей вине он возник.

Давайте на простом примере попробуем разобраться с очень простым конфликтом. Есть две ветки - test1 и test2. Сейчас я подключусь на одну из них и попробую смержить в неё ветку test2. Ветку test1 я сделаю локально, и, с помощью специальной команды, которая осуществляет слияние веток, сделать мерж. Я хочу смержить test2. Выбираю ветку, нажимаю мерж и вижу: возникает окно с конфликтом. Здесь нам предлагают методы разрешения конфликта: принять вашу версию изменений, которые конфликтуют, либо принять версию, которая в ветке test2. Чтобы не делать необратимых вещей, я рекомендую всегда перед тем, как конфликт разрешить, заглянуть и посмотреть, что произошло. Двойным нажатием на проблемный файл мы открываем окно и видим, что конфликтное место у нас подчеркнуто. Локально добавилась новая строка в конце файла. В ветке test2 у нас добавился комментарий. Понятно, что эти звенья "нехорошие", но git этого не понимает. Для него это равноправные правки. Поэтому он не знает что выбрать. Какие у него есть альтернативы? Он может, вообще, ничего не прикладывать, может оставить нашу версию, может оставить версию из test2, может их расположить по порядку, то есть для него это полная неопределенность. Попробуем этот конфликт разрешить. Мы попробовали смержить. В файле, в котором мы видели конфликт появились "заклинания" на неизвестном языке. Сверху над знаками равно наша версия, снизу версия той ветки, которую мы хотим смержить. Наша с вами задача, когда мы разрешаем конфликт, надо удалить форматирование и оставить какую-то работоспособную и логичную версию. Таких модулей может быть несколько. Важно понять все места, где есть конфликт, в каждом месте внимательно посмотреть, выработать какое-то общее решение и, удалив форматирование, оставить работоспособный вариант. После того, как мы разрешили конфликт, важно проверить, что ничего не сломалось. Важно убедиться, что приложение запускается, что нет приобретенных багов. Для нашего случая, мы оставляем наши оба изменения по порядку - изменения для test1 у нас сверху, для test2 снизу. Чтобы завершить исправление конфликтов, нам необходимо сделать коммит. Нам пишут, что мы забыли что-то сделать. Это не относится собственно к конфликту, это относится к IDEA. Сама среда разработки настроена таким образом, чтобы, если у вас есть какие-то критичные вещи в ваших исходниках, то она вам будет бросать warning даже при попытке закоммитить код, который на её взгляд коммитить не стоит. Попробуем сделать коммит, и видим, что какой-то коммит остался нерешенным. Теперь конфликт у нас решен. Если те же самые вещи делать в командной строке, то таких проблем не будет. Сразу после решения конфликта, как вы делаете коммит, проблемы больше нет.

Давайте посмотрим в историю коммитов. Мы видим, что мерж у нас удался, и у нас получился результат, в котором все хорошо. Наш конфликт разрешен успешно.