merge into current idea что делает
Git для начинающих. Урок 9.
Слияния или мерджи веток
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Подробнее о разных соглашениях мы поговорим во второй части курса.
Что такое мердж или слияние веток
Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.
Мердж ветки в мастер
Выполняется после завершения работы над своей веткой при помощи команды git merge. Чтобы вмерджить ветку в мастер, нужно сначала перейти в мастер, а затем выполнить git merge branch_name.
При этом возможны разные ситуации
Поговорим о них подробнее
Пока мы работали над веткой, в мастере не появилось новых коммитов
То есть мы создали ветку, поработали над ней, собрались заливать ее в мастер, а за это время новых коммитов там не появилось. Тогда слияние проходит так
Git понимает, что это новый код, который можно просто положить поверх старого. Это простая ситуация и git не задает никаких вопросов.
Не забудьте сразу запушить изменения, чтобы их увидели коллеги, и удалить локальную ветку header, если она больше не нужна.
Теперь другая ситуация.
Пока мы работали над веткой, в мастере появились коммиты от коллег
Сначала переключаемся на мастер
Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем
Мерджим свою ветку в мастер
И не забываем запушить изменения
Что если сначала не подтягивать мастер, а смерджить свою ветку
Принципиально ничего не изменится, но лучше сначала сделать актуальной ветку мастер, а уже потом заливать свои изменения. А еще лучше держать актуальной свою ветку относительно мастера. Это значит, что стоит почаще подтягивать мастер в свою ветку. Таким образом мы в своей ветке будем работать с актуальным кодом и у нас меньше риска что-нибудь поломать. А если поломаем, то лучше чинить это в своей ветке, а не в мастере.
Как вмерджить мастер в свою ветку
Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master
Затем проверяем, что ничего не поломалось и продолжаем работать.
Мердж коммиты
Чем чаще мерджить между собой ветки, тем больше появляется так называемых мердж-коммитов. Такой коммит появляется каждый раз, когда мы подтягиваем мастер в свою ветку или сливаем свою ветку в мастер. Эти коммиты не хранят изменений, они хранят только факт мерджа одной ветки в другую.
Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754
Посмотрим его содержимое
То есть информация только о том, что в мастер была залита ветка news. Сами изменения в файлах, которые мы делали в ветке news, лежат в других коммитах.
Споры о том, есть польза от таких коммитов, ведутся годами и не закончатся, видимо, никогда.
Мерджи всегда проходят так гладко?
В этом уроке мы намеренно упрощали ситуацию и рассматривали случаи, когда наши коллеги делают изменения в других участках кода. То есть мы с ними даже не пересекались. В реальной жизни так происходит не всегда. Иногда мы правим одни и те же участки кода и тогда при их слиянии git не может понять, чей вариант правильный. Это называется возникновения конфликта.
Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.
Слияние веток с Git в IntelliJ IDE
Я знаю, что есть десятки вопросов по этому вопросу, но у меня проблемы. Во-первых, я использую Webstorm (IntelliJ), а не командную строку. Во-вторых, это, кажется, зависит от перспективы.
У меня есть мастер ветка, очевидно. Я создал новую ветку под названием «InlineEditing». Я работаю в этой ветке пару дней. В основной ветке изменений не было. Теперь я хочу перенести все изменения в текущей ветке обратно в мастер и возобновить работу оттуда.
В Webstorm, с InlineEditing в качестве текущей ветви, я попытался объединиться, используя следующий метод, но, похоже, он ничего не сделал. Т.е. когда я потом проверяю основную ветку, это старый код.
Итак, мой вопрос: как правильно «объединить» мою текущую ветку с мастером?
2 ответа
Стандартный рабочий процесс, который вы используете, выглядит примерно так:
Что касается вашего первоначального вопроса о IntelliJ, я думаю, что нет ничего плохого в использовании инструмента графического интерфейса для Git, при условии, что вы знаете, что делаете. Я склонен выполнять большинство операций Git из командной строки, потому что у меня есть опыт в этом, и командная строка мощная. Но во многих случаях я использую такие инструменты, как IntelliJ. Например, разрешение конфликтов слияния в IntelliJ намного проще, чем в командной строке. Кроме того, визуализация истории ветки может быть проще с помощью инструмента с графическим интерфейсом.
В Intellij нет возможности одним щелчком мыши объединить текущую ветку с мастером, поэтому создать скрипт для этого будет проще:
Введение в Git Merge и Git Rebase: зачем и когда их использовать
Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git Merge
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной. 
Плюсы:
Слейте ветку master в ветку feature, используя команды checkout и merge.
Это создаст новый «Merge commit» в ветке feature, который содержит историю обеих веток.
Git Rebase
Rebase — еще один способ перенести изменения из одной ветки в другую. Rebase сжимает все изменения в один «патч». Затем он интегрирует патч в целевую ветку.
В отличие от слияния, перемещение перезаписывает историю, потому что она передает завершенную работу из одной ветки в другую. В процессе устраняется нежелательная история.
Переместите ветку feature на главной ветке, используя следующие команды.
Это перемещает всю ветку функции в главную ветку. История проекта изменяется, создаются новые коммиты для каждого коммита в основной ветке.
Интерактивное перемещение
Это позволяет изменять коммиты при их перемещении в новую ветку. Это лучше, чем автоматическое перемещение, поскольку обеспечивает полный контроль над историей коммитов. Как правило, используется для очистки истории до слияния ветки feature в master.
Это откроет редактор, перечислив все коммиты, которые будут перемещены.
Это точно определяет, как будет выглядеть ветка после выполнения перемещения. Упорядочивая объекты, вы можете сделать историю такой, как захотите. Вы можете использовать команды fixup, squash, edit, и так далее.
Какой из них использовать?
Так что же лучше? Что рекомендуют эксперты?
Трудно принять единственно правильное решение о том, что лучше использовать, поскольку все команды разные. Всё зависит от потребностей и традиций внутри команды.
Принимайте решения на основании компетенции команды в Git. Для вас важна простота или перезаписывание истории, а может быть что-то другое?
По мере роста команды становится сложно управлять или отслеживать изменения в разработке, применяя слияние. Чтобы иметь чистую и понятную историю коммитов, разумно использовать Rebase.
Merging branches with Git in IntelliJ IDE
I know there are dozens of questions on this, but I’m having trouble. First off, I’m using Webstorm (IntelliJ) not the command line. Second, this seems to vary by perspective.
I have my master branch, obviously. I created a new branch called «InlineEditing». I’ve been working in this branch for a couple days. There have been no changes to the master branch. I now want to move all the changes in the current branch back to the master and resume working from there.
In Webstorm, with InlineEditing as the current branch, I tried merging using the following method but it doesn’t seem to do anything. Ie, when I then checkout the master branch, it’s the old code.
So my question is, what is the proper way to «merge» my current branch back to the master?
3 Answers 3
You normally have two merge use cases.
The standard workflow you are following goes something like this:
It might be slightly counterintuitive that you have to switch to master in order to merge another branch into it. Instead, you might have expected to be able to merge InlineEditing into master from the former branch. This is just how Git works.
With regard to your original question about IntelliJ, I think there is nothing wrong with using a GUI tool for Git, provided that you know what you are doing. I tend to do most Git operations from the command line, because I am experienced doing this and the command line is powerful. But there are many cases where I use tools like IntelliJ. For example, resolving merge conflicts is much easier in IntelliJ than the command line. Also, visualizing the history of a branch can be easier using a GUI tool.
Сравнение слияния и перебазирования
Обзор основных моментов
А теперь предположим, что новые коммиты в главной ветке main затрагивают функцию, над которой вы работаете. Для включения новых коммитов в свою функциональную ветку feature можно использовать два варианта: слияние или перебазирование.
Способ слияния (merge)
Проще всего слияние ветки main в функциональную ветку выполняется с помощью следующей команды:
При желании этот код можно записать в одну строку:
Эта операция создает в ветке feature новый «коммит слияния», связывающий истории обеих веток. Структура веток будет выглядеть так:
Слияние (merge) — это отличная неразрушающая операция. Существующие ветки никак не изменяются. Эта операция позволяет избегать потенциальных проблем, связанных с выполнением команды rebase (и описанных ниже).
Способ перебазирования (rebase)
Вместо слияния можно выполнить перебазирование функциональной ветки feature на главную ветку main с помощью следующих команд:
Однако такая безупречная история коммитов требует определенных жертв: жертвовать приходится безопасностью и отслеживаемостью. Если не следовать Золотому правилу Rebase, перезапись истории проекта может обернуться катастрофическими последствиями для совместных рабочих процессов. Кроме того, при выполнении rebase теряется контекст, доступный в коммите со слиянием: вы не сможете увидеть, когда вышестоящие изменения были включены в функционал.
Интерактивное перебазирование
Чтобы запустить интерактивное перебазирование, передайте параметр i команде git rebase :
Откроется текстовый редактор. В нем будут перечислены все коммиты, подготовленные к перемещению:
Этот список точно отражает, как будет выглядеть ветка после перебазирования. Изменяя команду pick и (или) порядок коммитов, вы можете придать истории ветки нужный вид. Так, если второй коммит содержит исправление небольшой проблемы в первом, их можно объединить с помощью команды fixup :
Когда вы сохраните и закроете файл, Git выполнит перебазирование в соответствии с вашими указаниями. История проекта затем примет следующий вид:
Удаление незначительных коммитов помогает быстрее разобраться в истории функциональной ветки. Команда git merge просто не в состоянии этого сделать.
Золотое правило перебазирования
Разобравшись с возможностями rebase, необходимо в первую очередь понять, когда эту команду не нужно использовать. Золотое правило для команды git rebase — никогда не использовать ее в публичных ветках.
Единственный способ синхронизировать две главные ветки main — выполнить их обратное слияние. Это приведет к дополнительному коммиту слияния и двум наборам коммитов, которые содержат одни и те же изменения (исходные изменения и изменения из вашей ветки после rebase). Нужно ли говорить, что ситуация получится крайне запутанная?
Поэтому перед выполнением команды git rebase следует убедиться, что текущую ветку не просматривает кто-то другой. Если в ней действительно ведется работа, прекратите любые действия и подумайте, как можно внести изменения неразрушающим способом (например, с помощью команды git revert ). В остальных случаях вы можете свободно перезаписывать историю при необходимости.
Принудительная отправка изменений
При этом удаленная ветка main станет соответствовать ветке в вашем репозитории после rebase. В итоге путаться начнут и ваши коллеги. Поэтому будьте внимательны и используйте эту команду только в том случае, если полностью понимаете, чего хотите добиться.
Одна из немногих ситуаций, требующих форсированного помещения кода, — это локальная очистка после помещения частной функциональной ветки в удаленный репозиторий (например, для создания резервной копии). Это равноценно заявлению: «Ой, я ведь не хотел отправлять исходную версию этой функциональной ветки. Лучше возьмите текущую версию». Здесь также важно, чтобы никто после коммитов не начал работу из исходной версии функциональной ветки.
Пошаговый разбор процесса
Перебазирование можно использовать при работе с Git ровно в том объеме, который подходит команде. В этом разделе вы узнаете о преимуществах перебазирования на разных этапах разработки функций продукта.
В любом рабочем процессе с применением команды git rebase сначала нужно создать отдельную ветку для каждой функции. Полученная структура веток необходима для безопасного перебазирования:
Локальная очистка
Один из самых эффективных сценариев перебазирования в рабочем процессе — это очистка локальных функциональных веток, в которых еще ведется работа. Если периодически проводить интерактивное перебазирование, ни один коммит в вашей ветке не потеряет смысла. Вы сможете быть уверены, что ваш код не распадется на изолированные коммиты. Если это случится, ситуацию всегда можно будет исправить.
При использовании команды git rebase есть два варианта для нового положения ветки: вышестоящая ветка для функциональной ветки (например, ветка main ) или более ранний коммит в функциональной ветке. Первый вариант описывался в примере в разделе Интерактивное перебазирование. Второй вариант удобен, когда нужно исправить лишь несколько недавних коммитов. Например, следующая команда запускает интерактивную операцию rebase только для трех последних коммитов.
3 в качестве нового положения, вы не перемещаете ветку как таковую, а лишь интерактивно переписываете 3 последующих коммита. Следует отметить, что при этой операции вышестоящие изменения не включаются в функциональную ветку.
Такое использование интерактивной операции rebase отлично поможет включить git rebase в рабочий процесс, поскольку затронет только локальные ветки. Другие разработчики увидят только законченную версию с простой и отслеживаемой историей функциональной ветки.
Повторим, что это работает только для частных функциональных веток. Если вы работаете в одной функциональной ветке с другими разработчиками, она является публичной и переписывать ее историю запрещено.
Варианта очистки локальных коммитов с интерактивным использованием rebase с помощью команды git merge не существует.
Включение восходящих изменений в функциональную ветку
Проверка функции с помощью запроса pull
Если в процессе проверки кода используются пул-реквесты, не используйте команду git rebase после создания пул-реквеста. Сразу после создания пул-реквеста другие разработчики смогут видеть ваши коммиты, то есть ваша ветка станет публичной. В случае перезаписи ее истории Git и ваши коллеги не смогут отслеживать последующие коммиты в функциональную ветку.
Поэтому хорошей идеей является очистка кода с помощью интерактивной операции rebase перед созданием пул-реквеста.
Внедрение утвержденной функции
Резюме
Теперь у вас достаточно информации, чтобы начать использовать rebase для своих веток. Если вы предпочитаете иметь чистую линейную историю без ненужных коммитов слияния, используйте команду git rebase вместо git merge при включении изменений из другой ветки.