Как подтянуть изменения из master в свою ветку visual studio

Обновлено: 07.07.2024

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Ветка 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 обычно очень разумен для разрешения конфликтов слияния автоматически, но иногда необходимо Разрешить конфликты слияния вручную и выполнить слияние с новой фиксацией.

Team Explorer выполняет слияние при выполнении запроса или синхронизации из представления изменений .

Синхронизация — это Объединенная операция извлечения удаленных изменений и последующей передачи локальных. Эта операция синхронизирует фиксации в локальной и удаленной ветви.

В Team Explorer нажмите кнопку Главная и выберите синхронизировать.

В окне Синхронизациявыберите Синхронизация.

Выполнение merge без флагов или параметров добавляет фиксации, скачанные из fetch , в локальную ветвь. Git добавляет фиксацию слияния при наличии конфликтов. Эта фиксация слиянием имеет две родительские фиксации, по одному для каждой ветви, и содержит изменения, зафиксированные для разрешения конфликтов между ветвями.

Укажите --no-commit параметр для слияния без фиксации. Команда пытается выполнить слияние, но не фиксирует окончательные изменения. Этот параметр дает возможность проверить измененные файлы перед тем, как завершить слияние с фиксацией.

Выборка и слияние с помощью инструкции Pull

Pull выполняет, fetch а затем merge для загрузки фиксаций и обновления локальной ветви в одной команде, а не на двух. Используйте pull , чтобы сделать ветвь текущей с удаленной, если вы не беспокоитесь о просмотре изменений перед их слиянием в собственную ветвь.

В Team Explorer нажмите кнопку Главная и выберите синхронизировать.

В разделе Синхронизациявыберите извлечь , чтобы получить удаленные изменения и объединить их в локальную ветвь.

git pull без каких-либо параметров fetch изменения, которые у вас нет, origin будут изменены merge для текущей ветви.

Извлечение удаленной ветви в локальную ветвь путем передачи сведений об удаленной ветви в pull :

pull Команда — это удобный способ непосредственного слияния работы из удаленной ветви с локальной ветвью.

Обновление ветви с использованием последних изменений из Main

При работе в ветви может потребоваться внести последние изменения из основной ветви в ветвь. Существует два подхода, которые можно использовать: перебазовый или слияние.

Перебазовая база данных принимает изменения, внесенные в фиксации в текущей ветви, и воспроизводит их в журнале другой ветви. Перезапись переписывает журнал фиксаций текущей ветви. Журнал начинается с последней фиксации в целевой ветви перебазы данных.
Слияние объединяет изменения из исходной ветви в целевую, используя фиксацию слиянием, которая станет частью журнала фиксаций.

В этой статье демонстрируется этот merge подход. дополнительные сведения о rebase методах, которые подходят для вашего сценария, и рекомендации по их использованию см. в разделе rebase перебазовый Pro.

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`, но это не считается «безопасной» конфигурацией, и вы должны делать это только в том случае, если вам очень комфортно со всеми задействованными операциями.

Где <commit> - это выражение, которое преобразуется в нужную фиксацию, например, его идентификатор фиксации (хэш) или относительное выражение (например, 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.

Читайте также: