29. Слияние в ветку main
Поскольку последний коммит в main предшествует последнему коммиту ветки style , Git может выполнить ускоренное слияние, просто переместив указатель ветки вперед, на тот же коммит, что и ветка style .
При ускоренном слиянии конфликты не возникают. Кроме того, при ускоренном слиянии не создается фиксация слияния.
02 Просмотрите логи
Выполните
git log --all --graph Результат
$ git log --all --graph * 39a1e0f 2023-11-28 | Renamed hello.html; moved style.css (HEAD -> main, style) [Alexander Shvets] * 23149b5 2023-11-28 | Included stylesheet into hello.html [Alexander Shvets] * b9e6de1 2023-11-28 | Added css stylesheet [Alexander Shvets] * 85c14e9 2023-11-28 | Added meta title [Alexander Shvets] * ee16740 2023-11-28 | Added README [Alexander Shvets] * 9288a33 2023-11-28 | Added copyright statement with email [Alexander Shvets] * b7614c1 2023-11-28 | Added HTML header (tag: v1) [Alexander Shvets] * 46afaff 2023-11-28 | Added standard HTML page tags (tag: v1-beta) [Alexander Shvets] * 78433de 2023-11-28 | Added h1 tag [Alexander Shvets] * 5836970 2023-11-28 | Initial commit [Alexander Shvets] Теперь ветки style и main идентичны.
Git для начинающих. Урок 9.
Слияния или мерджи веток
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Ветка master — еще раз
Мастер — это основная ветка проекта, в которую заливается только рабочий проверенный код. Новый функционал в конце концов оказывается в мастере. В этой ветке находится тот же самый код, что и на боевом сайте
В различных компаниях и командах могут быть приняты другие соглашения насчет веток. Например, что весь функционал сначала сливается в промежуточную ветку. Но в наших уроках мы будем исходить из того, что ветка мастер — главная и в нее в итоге заливаются все остальные ветки
Подробнее о разных соглашениях мы поговорим во второй части курса.
Что такое мердж или слияние веток
Это перенос кода из одной ветки в другую. Например, когда мы заканчиваем работу над веткой, например, сделали новый функционал или поправили багу, мы сливаем ее в мастер. В мастере код проверяется еще раз и выкладывается на боевой сервер.
Сливать друг в друга можно любые ветки. Технически, с точки зрения git нет никакой разницы, сливается ветка с новым функционалом в мастер или наоборот. Для нас мастер — это основная ветка разработки, а для git это просто ветка.
Мы будем говорить, что новая ветка сливается в мастер, когда мы закончили работать над функционалом и хотим выложить его на боевой сайт. Тогда мы сливаем ветку в мастер и выкладываем мастер в продакшен.
Мастер сливается в ветку или мастер подтягивается в ветку, когда мы продолжаем работать над веткой, но хотим периодически подтягивать новые коммиты с сервера — новый код, который написали наши коллеги. Если работа над веткой идет довольно долго, есть смысл подтягивать изменения из мастера хоть каждый день.
Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.
Мердж ветки в мастер
Выполняется после завершения работы над своей веткой при помощи команды git merge. Чтобы вмерджить ветку в мастер, нужно сначала перейти в мастер, а затем выполнить git merge branch_name.
$ git checkout master $ git merge news При этом возможны разные ситуации
Поговорим о них подробнее
Пока мы работали над веткой, в мастере не появилось новых коммитов
То есть мы создали ветку, поработали над ней, собрались заливать ее в мастер, а за это время новых коммитов там не появилось. Тогда слияние проходит так
$ git merge news Updating f32b91e..33ea897 Fast-forward index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) $ git push origin master $ git branch -d news Git понимает, что это новый код, который можно просто положить поверх старого. Это простая ситуация и git не задает никаких вопросов.
Не забудьте сразу запушить изменения, чтобы их увидели коллеги, и удалить локальную ветку header, если она больше не нужна.
Теперь другая ситуация.
Пока мы работали над веткой, в мастере появились коммиты от коллег
Сначала переключаемся на мастер
$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем
$ git pull --rebase origin master Мерджим свою ветку в мастер
$ git merge news-styles И не забываем запушить изменения
$ git push origin master Что если сначала не подтягивать мастер, а смерджить свою ветку
Принципиально ничего не изменится, но лучше сначала сделать актуальной ветку мастер, а уже потом заливать свои изменения. А еще лучше держать актуальной свою ветку относительно мастера. Это значит, что стоит почаще подтягивать мастер в свою ветку. Таким образом мы в своей ветке будем работать с актуальным кодом и у нас меньше риска что-нибудь поломать. А если поломаем, то лучше чинить это в своей ветке, а не в мастере.
Как вмерджить мастер в свою ветку
Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master
$ git checkout master $ git pull --rebase origin master $ git checkout news-redesign $ git merge master Затем проверяем, что ничего не поломалось и продолжаем работать.
Мердж коммиты
Чем чаще мерджить между собой ветки, тем больше появляется так называемых мердж-коммитов. Такой коммит появляется каждый раз, когда мы подтягиваем мастер в свою ветку или сливаем свою ветку в мастер. Эти коммиты не хранят изменений, они хранят только факт мерджа одной ветки в другую.
Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754
$ git log --oneline 051f754 Merge branch 'news' . Посмотрим его содержимое
$ git show 051f754 commit 051f75475cb1dca3cd08c1c7367a3308671ccf7b Merge: 0a3a6a3 2346be5 Author: Alexandr Shestakov Date: Sat Feb 8 14:10:39 2020 +0300 Merge branch 'news' То есть информация только о том, что в мастер была залита ветка news. Сами изменения в файлах, которые мы делали в ветке news, лежат в других коммитах.
Споры о том, есть польза от таких коммитов, ведутся годами и не закончатся, видимо, никогда.
Плюс в том, что у нас есть возможность выбора — git позволяет обходиться без таких коммитов вообще. Тогда история коммитов будет содержать только изменения в коде, а не операции с ветками. Это достигается механизмом ребейза, но это тема, которая выходит за рамки первой курса. Ребейз, его плюсы и минусы, мы подробно рассмотрим во второй части курса.
Также можете почитать мою старую статью — Отличия мерджа от ребейза.
В ней нет видеоурока, но наглядно объясняется на скриншотах.
Мерджи всегда проходят так гладко?
К сожалению, нет
В этом уроке мы намеренно упрощали ситуацию и рассматривали случаи, когда наши коллеги делают изменения в других участках кода. То есть мы с ними даже не пересекались. В реальной жизни так происходит не всегда. Иногда мы правим одни и те же участки кода и тогда при их слиянии git не может понять, чей вариант правильный. Это называется возникновения конфликта.
Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.
Что могу посоветовать
- Не забывайте, что мастер — это продакшен, это рабочая версия кода, которую не стоит ломать
- В мастер не сливается незаконченная работа, только полностью рабочий и проверенный функционал
- Перед мерджем своей ветки в мастер, подтягивайте изменения в мастер с сервера
- После мерджа в мастер, не забывайте пушить эти изменения
- Подтягивайте мастер в свою ветку почаще
- Мердж-коммиты несут информацию только о факте слияния веток. Договоритесь в команде, насколько они вам нужны
- Познакомьтесь с механизмом ребейза, он позволяет вести чистую историю без мердж-коммитов
Спасибо за внимание и до встречи!
Все уроки курса
- Вводный урок
- 1. Установка и базовая настройка git
- 2. Создание и клонирование репозитория git
- 3. Делаем первые изменения, git status и git diff
- 4. Коммиты и история коммитов, git commit, git log и git show
- 5. Подробнее об истории коммитов. Путешествие по истории
- 6. Работа с сервером, git push и git pull
- 7. Ветки — главная фишка git, git branch и git checkout
- 8. Работа с ветками на сервере, git fetch
- 9. Слияния или мерджи веток, git merge
- 10. Конфликты и их разрешение
- Платная часть курса. Презентация
- * 11. Работа с gitignore и git exclude
- * 12. Буфер обмена git, git stash
- * 13. Копирование коммитов, git cherry-pick
- * 14. Отмена и редактирование последнего коммита
- * 15. Отмена произвольного коммита, git revert
- 16. Склеивание коммитов, git rebase —interactive и git reflog
- * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
- * 18. Работа с git rebase. Отличия от merge
- * 19. Что такое git push —force и как с ним работать
- * 20. Ищем баги с помощью git, git bisect
- * 21. Как и зачем работать с тегами git
- * 22. Процессы: github flow и git flow
- * 23. Псевдонимы в git
- 24. Мердж-реквесты
- * 25. Форки
Как переключаться между ветками в git, когда в текущей ветке есть несохраненные изменения?
Что имею? Две ветки. Одна — master . Другая — feature. Они отличаются. Я изменил некоторые файлы в папке project (пока работал в ветке feature ). Но тут мне очень понадобилось взглянуть на файлы, которые в master . Как сделать так, чтобы в папке project находились не те файлы, над которыми я сейчас работаю feature , а те, что были в ветке master ?
Отслеживать
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
задан 14 окт 2012 в 2:04
153 1 1 золотой знак 1 1 серебряный знак 9 9 бронзовых знаков
15 окт 2012 в 1:05
как вариант — спрятать изменения «git stash», перейти на другую ветку, взглянуть на то, что было нужно, перейти обратно и вытащить изменения обратно «git stash pop»
8 сен 2015 в 11:34
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Если у вас уже есть ветка feature , то после коммита в нее сделайте git checkout master – это переключит текущую ветку на master .
Пока вы не вкоммитили изменения, вы не можете переключиться на другую ветку. Выхода два: вкоммитить изменения или отложить их. Второе можно сделать с помощью git stash – это добавит текущие незакоммиченные изменения в стек изменений и сбросит текущую рабочую копию до HEAD ‘а репозитория. Далее вы сможете:
- git stash list : показать все изменения в стеке
- git stash show : показать последнее изменение в стеке (патч)
- git stash apply : применить последнее изменение из стека к текущей рабочей копии
- git stash drop : удалить последнее изменение в стеке
- git stash pop : применить последнее изменение из стека к текущей рабочей копии и удалить его из стека
- git stash clear : очистить стек изменений
Отслеживать
ответ дан 14 окт 2012 в 2:14
3,797 16 16 серебряных знаков 29 29 бронзовых знаков
Также вместо stash можно использовать обычный commit (а потом откатить его) — это позволит «привязать» сохраненные изменения к ветке. Еще есть такой механизм как worktree для самых тяжелых случаев.
23. Переключение веток
Просто используйте команду git checkout для переключения между ветками.
Выполните
git switch main cat hello.html Результат
$ git switch main Switched to branch 'main' $ cat hello.html Hello, World!
Теперь мы находимся в ветке main . Как видите, в hello.html нет никаких следов style.css . Не волнуйтесь, эти изменения все еще есть в репозитории, но мы не можем увидеть их из ветки main .
02 Вернемся к ветке style
Выполните
git switch style cat hello.html Результат
$ git switch style Switched to branch 'style' $ cat hello.html "text/css" rel="stylesheet" media="all" href="style.css" /> Hello, World!
Мы вернулись к ветке style . Как видите, наши изменения, связанные с CSS, присутствуют.