3.3 Ветвление в Git — Управление ветками
Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.
Команда git branch делает несколько больше, чем просто создаёт и удаляет ветки. При запуске без параметров, вы получите простой список имеющихся у вас веток:
$ git branch iss53 * master testing
Обратите внимание на символ * , стоящий перед веткой master : он указывает на ветку, на которой вы находитесь в настоящий момент (т. е. ветку, на которую указывает HEAD ). Это означает, что если вы сейчас сделаете коммит, ветка master переместится вперёд в соответствии с вашими последними изменениями. Чтобы посмотреть последний коммит на каждой из веток, выполните команду git branch -v :
$ git branch -v iss53 93b412c Fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 Add scott to the author list in the readme
Опции —merged и —no-merged могут отфильтровать этот список для вывода только тех веток, которые слиты или ещё не слиты в текущую ветку. Чтобы посмотреть те ветки, которые вы уже слили с текущей, можете выполнить команду git branch —merged :
$ git branch --merged iss53 * master
Ветка iss53 присутствует в этом списке потому что вы ранее слили её в master . Те ветки из этого списка, перед которыми нет символа * , можно смело удалять командой git branch -d ; наработки из этих веток уже включены в другую ветку, так что ничего не потеряется.
Чтобы увидеть все ветки, содержащие наработки, которые вы пока ещё не слили в текущую ветку, выполните команду git branch —no-merged :
$ git branch --no-merged testing
Вы увидите оставшуюся ветку. Так как она содержит ещё не слитые наработки, попытка удалить её командой git branch -d приведёт к ошибке:
$ git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'.
Если вы действительно хотите удалить ветку вместе со всеми наработками, используйте опцию -D , как указано в подсказке.
Если в качестве аргумента не указан коммит или ветка, то опции —merged и —no-merged покажут что уже слито или не слито с вашей текущей веткой соответственно.
Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.
$ git checkout testing $ git branch --no-merged master topicA featureB
Переименование ветки
Не переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».
Предположим, у вас есть ветка с именем bad-branch-name , и вы хотите изменить её на corrected-branch-name , сохранив при этом всю историю. Вместе с этим, вы также хотите изменить имя ветки на удалённом сервере (GitHub, GitLab или другой сервер). Как это сделать?
Переименуйте ветку локально с помощью команды git branch —move :
$ git branch --move bad-branch-name corrected-branch-name
Ветка bad-branch-name будет переименована в corrected-branch-name , но это изменение пока только локальное. Чтобы все остальные увидели исправленную ветку в удалённом репозитории, отправьте её туда:
$ git push --set-upstream origin corrected-branch-name
Теперь проверим, где мы сейчас находимся:
$ git branch --all * corrected-branch-name main remotes/origin/bad-branch-name remotes/origin/corrected-branch-name remotes/origin/main
Обратите внимание, что текущая ветка corrected-branch-name , которая также присутствует и на удалённом сервере. Однако, старая ветка всё ещё по-прежнему там, но её можно удалить с помощью команды:
$ git push origin --delete bad-branch-name
Теперь старое имя ветки полностью заменено исправленным.
Изменение имени главной ветки
Предупреждение
Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.
Переименуйте локальную ветку master в main с помощью следующей команды:
$ git branch --move master main
После этого, локальной ветки master больше не существует, потому что она была переименована в ветку main .
Чтобы все остальные могли видеть новую ветку main , вам нужно отправить её в общий репозиторий. Это делает переименованную ветку доступной в удалённом репозитории.
$ git push --set-upstream origin main
В итоге, состояние репозитория становится следующим:
$ git branch --all * main remotes/origin/HEAD -> origin/master remotes/origin/main remotes/origin/master
Ваша локальная ветка master исчезла, так как она заменена веткой main . Ветка main доступна в удалённом репозитории. Старая ветка master всё ещё присутствует в удалённом репозитории. Остальные участники будут продолжать использовать ветку master в качестве основы для своей работы, пока вы не совершите ряд дополнительных действий.
Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:
- Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.
- Обновите конфигурацию всех запускаемых тестов.
- Исправьте скрипты сборки и публикации артефактов.
- Поправьте настройки репозитория на сервере: задайте новую ветку по умолчанию, обновите правила слияния, а также прочие настройки, которые зависят от имени веток.
- Обновите документацию, исправив ссылки, указывающие на старую ветку.
- Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.
После того, как вы выполнили все эти задачи и уверены, что ветка main работает так же, как ветка master , вы можете удалить ветку master :
$ git push origin --delete master
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. Форки
Как подтянуть изменения из master в свою ветку visual studio
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Ветка master — еще раз
Мастер — это основная ветка проекта, в которую заливается только рабочий проверенный код. Новый функционал в конце концов оказывается в мастере. В этой ветке находится тот же самый код, что и на боевом сайте
В различных компаниях и командах могут быть приняты другие соглашения насчет веток. Например, что весь функционал сначала сливается в промежуточную ветку. Но в наших уроках мы будем исходить из того, что ветка мастер — главная и в нее в итоге заливаются все остальные ветки
Подробнее о разных соглашениях мы поговорим во второй части курса.
Что такое мердж или слияние веток
Это перенос кода из одной ветки в другую. Например, когда мы заканчиваем работу над веткой, например, сделали новый функционал или поправили багу, мы сливаем ее в мастер. В мастере код проверяется еще раз и выкладывается на боевой сервер.
Сливать друг в друга можно любые ветки. Технически, с точки зрения git нет никакой разницы, сливается ветка с новым функционалом в мастер или наоборот. Для нас мастер — это основная ветка разработки, а для git это просто ветка.
Мы будем говорить, что новая ветка сливается в мастер, когда мы закончили работать над функционалом и хотим выложить его на боевой сайт. Тогда мы сливаем ветку в мастер и выкладываем мастер в продакшен.
Мастер сливается в ветку или мастер подтягивается в ветку, когда мы продолжаем работать над веткой, но хотим периодически подтягивать новые коммиты с сервера — новый код, который написали наши коллеги. Если работа над веткой идет довольно долго, есть смысл подтягивать изменения из мастера хоть каждый день.
Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.
Мердж ветки в мастер
Выполняется после завершения работы над своей веткой при помощи команды 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 не может понять, чей вариант правильный. Это называется возникновения конфликта.
Узнай 2 способа, как можно обновить свою ветку последними изменениями с основной ветки разработки.
Обычно, когда разрабатывается какой-то функционал, создается отдельная ветка, которая ответвляется от основной линии разработки — master или develop (мы будем использовать master ). Однако, чем дольше мы работаем над своей веткой, тем больше будет окончательное слияние (merge).
Когда мы работаем в команде, то очень часто коллеги добавляют изменения в репозиторий. Для того, чтобы стянуть последние изменения, нужно перейти на основную ветку master и сделать git pull .
Хорошей практикой является создание отдельной ветки для разработки наших новых функциональностей или даже обратных исправлений. Тем не менее, настоятельно рекомендуется синхронизировать её с основной линией разработки, которая может быть master или с какой-либо отдельной веткой, как можно чаще.
Основная причина заключается в том, что тогда мы можем сразу же адаптироваться к изменениям, которые другие разработчики внесли в основной код приложения. Кроме того, таким образом мы избежим действительно очень больших проблем слияния в конце, когда ветка будет завершена.
Для обновления своего кода, прежде всего, нужно стянуть все изменения. Нам нужно убедиться, что мы синхронизированы и обновлены. Будучи на основной ветке master , делаем:
Затем переходим на нашу ветку разработки. Теперь для синхронизации с веткой master у нас есть разные возможности.
Настоятельно рекомендуется так делать, если это общая ветка. Если мы пушнем данные изменения в удаленный репозиторий origin/master , то другие разработчики тоже смогут работать над этим же кодом.
Однако, если эта ветка только наша и над ней работаем только мы, тогда можно использовать команду git rebase : возьмёт каждый коммит из master и объединит их поверх коммитов в нашей ветке.
В результате наша ветка будет просто смещена вверх, как если бы мы только что создали её из последней версии master ветки. Однако, это действие меняет id этих же коммитов. Опять же, желательно делать git rebase только в том случае, если у нас личная ветка и она не делится с другими.
Давай выполним rebase. Будучи на ветке разработки делаем git rebase с master .
Что он делает? — перематывает HEAD и заменяет нашу работу поверх master :
Теперь наши коммиты содержат все последние изменения, произошедшие в master .
Обновите код в локальном репозитории с изменениями от других членов команды, используя следующие команды:
- fetch , который скачивает изменения из удаленного репозитория, но не применяет их к коду.
- merge , который применяет изменения, взятые из, в fetch ветвь в локальном репозитории.
- pull — Объединенная команда, которая выполняет, fetch а затем merge .
Из этого руководства вы узнаете, как выполнить следующие задачи:
Видеообзор
При наличии конфликта слияния между фиксацией, которую вы еще не отправили, и фиксацией, которую вы собираете или извлекать, устраните эти конфликты , прежде чем завершить обновление кода.
Вы скачиваете изменения в локальную ветвь с удаленного компьютера через fetch . Fetch запрашивает удаленный репозиторий о всех фиксациях и новых ветвях, которые были отправлены другими пользователями, но у вас нет и загружают их в репозиторий, создавая локальные ветви по мере необходимости.
Fetch не объединяет изменения в локальные ветви. Он скачивает только новые фиксации для проверки.
Чтобы обеспечить очистку списка ветвей и их обновление, настройте Git для очистки удаленных ветвей во время получения. Этот параметр можно настроить из командной строки или в Visual Studio.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
Visual Studio использует представление синхронизации в Team Explorer для изменения. Изменения, скачанные, fetch не применяются, пока вы не fetch или не синхронизируйте изменения.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В поле Синхронизациявыберите извлечь , чтобы обновить список входящих фиксаций.
Выполните git fetch команду из командной строки, чтобы загрузить изменения в локальную ветвь.
После запуска git fetch вы увидите результаты, аналогичные приведенным в следующем примере:
Обновление ветвей с помощью Merge
Примените изменения, загруженные fetch с помощью merge команды. Объединить принимает фиксации, полученные от fetch , и пытается добавить их в локальную ветвь. Слияние сохраняет историю фиксаций локальных изменений. Когда вы предоставляете общий доступ к ветви с помощью push-уведомлений, Git знает, как другие пользователи должны объединять ваши изменения.
Проблема заключается в том, что merge фиксация, полученная из, fetch вступает в конфликт с существующей неотправленной фиксацией в ветви. Git обычно очень разумен для разрешения конфликтов слияния автоматически, но иногда необходимо Разрешить конфликты слияния вручную и выполнить слияние с новой фиксацией.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
Team Explorer выполняет слияние при выполнении запроса или синхронизации из представления изменений .
Синхронизация — это Объединенная операция извлечения удаленных изменений и последующей передачи локальных. Эта операция синхронизирует фиксации в локальной и удаленной ветви.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В окне Синхронизациявыберите Синхронизация.
Выполнение merge без флагов или параметров добавляет фиксации, скачанные из fetch , в локальную ветвь. Git добавляет фиксацию слияния при наличии конфликтов. Эта фиксация слиянием имеет две родительские фиксации, по одному для каждой ветви, и содержит изменения, зафиксированные для разрешения конфликтов между ветвями.
Укажите —no-commit параметр для слияния без фиксации. Команда пытается выполнить слияние, но не фиксирует окончательные изменения. Этот параметр дает возможность проверить измененные файлы перед тем, как завершить слияние с фиксацией.
Выборка и слияние с помощью инструкции Pull
Pull выполняет, fetch а затем merge для загрузки фиксаций и обновления локальной ветви в одной команде, а не на двух. Используйте pull , чтобы сделать ветвь текущей с удаленной, если вы не беспокоитесь о просмотре изменений перед их слиянием в собственную ветвь.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
В Team Explorer нажмите кнопку Главная и выберите синхронизировать.
В разделе Синхронизациявыберите извлечь , чтобы получить удаленные изменения и объединить их в локальную ветвь.
git pull без каких-либо параметров fetch изменения, которые у вас нет, origin будут изменены merge для текущей ветви.
Извлечение удаленной ветви в локальную ветвь путем передачи сведений об удаленной ветви в pull :
pull Команда — это удобный способ непосредственного слияния работы из удаленной ветви с локальной ветвью.
Обновление ветви с использованием последних изменений из Main
При работе в ветви может потребоваться внести последние изменения из основной ветви в ветвь. Существует два подхода, которые можно использовать: перебазовый или слияние.
- Перебазовая база данных принимает изменения, внесенные в фиксации в текущей ветви, и воспроизводит их в журнале другой ветви. Перезапись переписывает журнал фиксаций текущей ветви. Журнал начинается с последней фиксации в целевой ветви перебазы данных.
- Слияние объединяет изменения из исходной ветви в целевую, используя фиксацию слиянием, которая станет частью журнала фиксаций.
В этой статье демонстрируется этот merge подход. дополнительные сведения о rebase методах, которые подходят для вашего сценария, и рекомендации по их использованию см. в разделе rebase перебазовый Pro.
Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
git pull origin main Команда объединяет git fetch команды и git merge . чтобы это правильно сделать в Visual Studio интеграции, необходимо выполнить синхронизацию в Team Explorer , чтобы сделать часть. Это обеспечит актуальность локального репозитория Git с удаленным источником.
Чтобы объединить последние изменения из основной ветви в ветвь, выполните следующие действия.
На Team Explorer нажмите кнопку Главная и выберите пункт ветви.
Ознакомьтесь с целевой ветвью. Щелкните правой кнопкой мыши целевую ветвь и выберите команду объединить из.
Укажите слияние из ветви в этом примере, а затем выберите объединить.
При наличии конфликтов слияния Team Explorer сообщает о ней. Устраните фиксации слияния перед следующим шагом.
Чтобы объединить последние изменения из Main в ветвь, в этом примере с именем users/jamal/readme-fix можно использовать следующие команды:
Сетевой график в моем репозитории выглядит следующим образом:
Где: M отправляются коммиты на master , 1 отправляются коммитами на branch-1 и 2 отправляются на branch-2 .
Как видите, коммиты из branch-1 были отправлены, запрошены для «запроса на вытягивание» и объединены в master .
Я на branch-2 и работаю в соответствии со своими задачами.
Мне нужен исходный код от мастера, чтобы закончить их.
Первый вопрос: что мне делать, чтобы передать исходный код с мастера на мой branch-2 ?
Второй вопрос: что мне делать, если у меня есть локальные изменения после нажатой второй фиксации на branch-2 , и я хотел бы сделать то же самое, что и выше?
2 ответа
Обновление — я забыл ответить на второй вопрос
Вы можете либо объединить master в свою ветку, rebase свою ветку в более позднюю фиксацию на главном сервере, либо cherry-pick коммиты, которые вносят необходимые изменения. Что делать, зависит от того, какой рабочий процесс вы (и ваша команда, если применимо) хотите использовать.
Преимущество merge в том, что он не перезаписывает историю и не дублирует коммиты. В некотором смысле это самая простая операция, но она создает то, что многие считают более сложной историей. (Нет однозначного ответа на вопрос, какой тип истории «лучше»; это зависит от того, как вы хотите использовать историю.) Если вы решите объединиться, вы можете сделать что-то вроде
Это предполагает, что ваш местный мастер обновлен. Если это не так, вы можете либо обновить его, либо сделать
По умолчанию pull — это ярлык для » fetch и merge «, поэтому вы также можете
Лично я обычно не использую pull таким образом; Я использую его только тогда, когда обновляю ветку из собственного апстрима. Но все же это допустимый вариант.
Преимущество rebase в том, что он позволяет избежать фиксации слияния и создает более линейную историю, которую предпочитают некоторые люди, и часто не требует, чтобы вы сохраняли повторяющиеся фиксации (т.е. он создает копии коммитов, но вы часто можете когда закончите, выбросьте оригиналы). История не так отражает то, как на самом деле было написано программное обеспечение, и, в частности, она может содержать коммиты, которые не собираются чисто, даже если вы в противном случае поддерживали политику «чистой проверки». И это переписывание истории; если ветка, к которой вы rebase уже предоставили общий доступ (т.е. она была push привязана к источнику в любой момент), то это может вызвать проблемы [1].
Если вы решите выполнить перебазирование, вы можете сказать
Как и в случае слияния, вы можете сначала fetch, and update master from its upstream or substitute origin / master for master as needed. You can also configure pull to do a rebase instead of a merge`, но это не считается «безопасной» конфигурацией, и вы должны делать это только в том случае, если вам очень комфортно со всеми задействованными операциями.
Где — это выражение, которое преобразуется в нужную фиксацию, например, его идентификатор фиксации (хэш) или относительное выражение (например, master
2 будет вторым родительским элементом, т. е. от третьего до последнего фиксации) ветвь master ).
Если у вас есть незафиксированные локальные изменения, вы должны быть немного осторожны. Самые эффективные средства защиты git от потери данных не применяются к копии рабочего дерева. git обычно старается избегать удаления данных в рабочем дереве, если только указанная вами команда не подразумевает, что вы хотите, чтобы она перезаписала рабочее дерево. (К сожалению, иногда не очевидно, какие команды будут работать таким образом.)
Так что самое безопасное, что нужно сделать, перед (слиянием, перебазированием или выбором вишни) — спрятать ваши изменения.
А потом восстановите их
Имейте в виду, что это может привести к конфликтам слияния (поскольку ваши локальные изменения могут повлиять на тот же кусок кода, что и коммиты, которые вы добавили в свою ветку). Кроме того, по умолчанию это отключает все ваши локальные изменения. Если вам нужно разделить поэтапные изменения и неустановленные изменения, вы можете сказать
Но в случае конфликта слияния во время pop команда завершится ошибкой, если задана опция —index . (На этом этапе вы либо откажетесь от опции —index , либо проделаете более сложные процедуры, чтобы применить свои изменения. «Более сложные обручи» я могу рассмотреть, если необходимо.)
Операции, которые вы пытаетесь выполнить, лучше всего выполнять путем слияния или перебазирования.
Толкать и тянуть — просто случайно по отношению к тому, что вы пытаетесь сделать. Они просто следят за тем, чтобы ваша локальная копия репо синхронизирована с тем, что находится на удаленном компьютере. Все фактические операции выполняются исключительно локально. Если в вашей ветке есть локальные коммиты, они будут использоваться.
Чтобы получить master в свою ветку, вы можете либо перебазировать master на master, либо слить master in. Если вы работаете над личной веткой и у вас есть разрешение принудительно продвигать коммиты без быстрой перемотки вперед, rebase сохранит вашу историю в чистоте:
Если, с другой стороны, вы работаете совместно или у вас нет разрешений на принудительную отправку, используйте слияние:
Git и TFS: история дружбы
Git — распределенная система контроля версий, где каждый разработчик имеет копию всего репозитория, что означает отличную поддержку оффлайн-разработки. Еще у Git есть хорошая, понятная модель бранчинга, и разработчику не надо долго думать о том, как создавать локальные или приватные бранчи для удобства работы. В общем, с Git все хорошо, и на MSDN есть посвященный Git бранч.
Проект Git в Team Foundation Service
После регистрации в TFS на странице команд есть новая кнопка — New Team Project + Git. Пара кликов — и проект Git готов.
Собственно, на этом все. 🙂 Но это — верхушка айсберга, внутри интеграция гораздо сложнее. Дальше — про то, как из Visual Studio подключиться и поманипулировать нашим Git-проектом.
Visual Studio и Git
Делаю сразу оговорку — Visual Studio — не замена существующему UI Git. Visual Studio может быть заменой, но чаще используется в совокупности с другими средствами. Если Git был создан внутри TFS, то у разработчика появляются некоторые фичи, пришедшие из TFS, например, Work Items, но VS спокойно работает с любыми локальными репозиториями и заслуженными Git-деятелями в лице GitHub и BitBucket.
Для подключения к Git-репозиторию достаточно нажать TEAM | Connect to Team Foundation Server.
Откроется Team Explorer. Как видите, у меня уже есть склонированный (с GitHub) репозиторий, и тут же — репозиторий TFS. Для клонирования нового репозитория Git можно нажать Clone и ввести данные подключения.
Для подключения аккаунта Visual Studio Online нажмем Select Team Projects, выберем аккаунт и установим, какой репозиторий надо подтянуть к нам в VS.
После подключения проектов выберем нужный и нажмем в контекстном меню кнопку Clone.
На этом процесс клонирования закончен — в бранче Local Git Repositories в Team Explorer появится склонированный репозиторий. Повторюсь — с помощью Clone можно клонировать любой Git-репозиторий.
Еще одна интересная фича интеграции Visual Studio и Git — это возможность создать новый проект и сразу добавить его в локальную систему контроля версий. Для этого при создании нового проекта в VS достаточно отметить Add to source control.
Перед тем, когда вы будете коммитить что-то в репозиторий, нужно установить данные для коммитов — нажать на Changes и предупреждение о том, что нужно ввести данные.
Полезные функции на этой странице есть еще внутри Repository Settings — можно настроить .gitIgnore и .gitattributes.
Дальше можно коммитить.
Чтобы сделать Pull и получить последние апдейты от команды, нужно перейти на Commits и нажать Fetch для того, чтобы сначала посмотреть, что там вообще придет (и есть ли чему придти).
Все хорошо — нажмем Pull и получим последний апдейт. Дополнительные сведения можно найти тут — Pull changes from the team.
Использование бранчей
Для использования бранчей в Team Explorer выделена специальная секци Branches.
После подключения к репозиторию доступна только master.
Создадим новый бранч, нажав New Branch.
Поскольку бранчи Git локальны до момента Push, новый бранч будет размещен в Unpublished Branches. Поменять бранч для коммитов можно на уже упоминавшейся выше странице Commits.
Замерджить контент можно, нажав Merge и выбрав бранчи. Подробнее про бранчи и мерджи — Git Branching.
Если в процессе мерджа или пулла возникнут конфликты, они тут же могут быть разрезолвены (самые простые, конечно).
Для просмотра истории достаточно нажать View History в контекстном меню бранча.
По нажатию на коммит получим подробные сведения о том, что произошло.
Многое из этого также доступно на портале TFS. Для того, чтобы перейти туда из VS, нужно на странице проекта в Team Explorer нажать Web Portal.
Читайте также:
- Убрать ассоциацию размеров автокад
- Как сделать планер в ворде
- Как пишется автокад на английском
- Как сделать ввод начальных остатков в 1с комплексная
- Кнопка изменить активность в 1с
Как подтянуть мастер в свою ветку?
Чтобы подтянуть мастер в свою ветку, следуйте следующим шагам:
- Создайте локальную ветку, ответвленную от основной ветки (например, master).
- Перебазируйте вашу локальную ветку поверх origin/master с помощью команды git rebase.
- Выполните перемотку или бесконфликтное слияние вашей ветки с владельцем.
Не проводите rebase уже отправленных коммитов в публичный репозиторий, чтобы избежать проблем.
Для синхронизации вашей ветки с основной линией разработки (master или другой), рекомендуется следующее:
- Перейдите на основную ветку (например, master) и выполните команду git pull, чтобы стянуть последние изменения от коллег.
- Хорошей практикой является создание отдельной ветки для разработки новых функциональностей или исправлений.
- Синхронизируйте вашу ветку с основной линией разработки как можно чаще, чтобы быстро адаптироваться к изменениям.
Мердж или слияние веток — это процесс переноса кода из одной ветки в другую. Когда вы закончили работу над своей веткой, например, добавили новый функционал или исправили ошибку, вы можете сливать ее с основной веткой (например, master).
Важно помнить, что если в процессе разработки вашей ветки основная ветка (master) сильно изменилась, рекомендуется сначала влить мастер в вашу ветку для предварительного тестирования.
При возникновении конфликтов во время слияния, вам нужно разрешить их вручную. Просмотрите все файлы, в которых возникли конфликты, и выполните команды git add и git commit, чтобы завершить слияние.
Также можно периодически вливать в вашу ветку новые изменения из основной ветки (master), чтобы ваша ветка не отклонялась слишком далеко от основной версии проекта.