Слияние веток visual studio
терминология
Для ознакомления с терминологией Git, пожалуйста, обратитесь к моей предыдущей статье .
Настройка рабочей станции / Visual Studio
В последнее время Microsoft, похоже, признает Git в качестве ценной альтернативы своей проприетарной TFS (Team Foundation Server) тому, что касается контроля версий, и поэтому начала выпускать свое собственное расширение Visual Studio, которое в настоящее время находится в фазе «предварительного просмотра». Вы можете найти его здесь: Visual Studio Tools for Git (Microsoft)
Скотт Хансельман также написал об этом. Я быстро попробовал плагин и, хотя он отлично интегрируется с Visual Studio (в основном, как TFS), он все еще слишком большой бета на мой вкус.
В настоящее время лучшая альтернатива, которую я нашел, — это установить Git Extensions для Windows и Git Source Control Provider Visual Studio Plugin. В следующих разделах рассматриваются соответствующие установки.
Установите Git Extensions для Windows
Первым шагом является загрузка Git Extensions из соответствующего Google Code Repository .
Его мастер установки установит все, что вам нужно для полной настройки Git, установки Git (из git-scm ) в различные инструменты Unix для Git Bash.
После того, как вы все установили, убедитесь, что все записи в контрольном списке Git Extension проходят для беспроблемной работы с Git.
Вы найдете этот контрольный список при открытии приложения Git Extensions, а затем перейдя к Plugins > Settings .
Установка Git Source Control Provider
Git Source Control Provider — это расширение с открытым исходным кодом, которое использует установку Git вашей машины и интегрирует ее в Visual Studio.
Если вы успешно настроили Git (следуя процедуре, упомянутой выше), вы можете продолжить и установить расширение Git Source Control Provider для Visual Studio. Возможно, самый простой способ — через диалоговое окно «Расширения и обновления», в котором вам нужно просто выполнить поиск «git source control».
В качестве одного из следующих шагов вам нужно правильно установить провайдера исходного кода в Visual Studio, поскольку у вас их может быть больше (например, TFS). Это делается в настройках Visual Studio в разделе «Source Control»:
Вы должны увидеть запись «Git Source Control Provider». Выберите это и подтвердите ваши настройки. После этого вы также должны убедиться, что он правильно ссылается на ваши установки Git и Git Extensions:
Настройка вашего ключа SSH
Многие репозитории Git-сервера допускают разные модели аутентификации:
Лично я предпочитаю последнее, так как ненавижу постоянно вводить свои учетные данные.
Чтобы получить руководство по генерации открытого ключа SSH, просто обратитесь к документации по GitHub, которая довольно подробно и хорошо объяснена.
Ну, вот и все, что касается установки. Теперь вы должны быть готовы начать.
Давайте начнем: создайте новый Git-репозиторий
Прежде всего, я просто создаю проект консоли, так как основное внимание здесь уделяется не созданию чего-то приятного и работающего, а скорее демонстрации интеграции Git в Visual Studio. Как только проект создан, мы можем настроить локальный репозиторий Git.
Это можно сделать, щелкнув правой кнопкой мыши по решению и выбрав «Создать Git Repository»:
После этой операции вы должны увидеть репозиторий для успешной настройки:
Более того, вы должны увидеть некоторые файлы, перечисленные в окне ожидающих изменений в Git:
Просто щелкните их все, добавьте содержательный комментарий и подтвердите их, нажав кнопку «Подтвердить».
Git SCP (отныне ссылающийся на расширение Git Source Control Provider для VS) предоставляет очень удобный и удобный механизм для просмотра реальной ситуации в вашем Git-репозитории, а именно путем визуализации лежащего в его основе дерева Git. Просто нажмите кнопку «История» …
… В окне «Ожидающие изменения» откроется новое окно с красивым графиком:
Пока что ничего особенного, но это показывает, что наш первоначальный коммит создал примечание, на которое (как и ожидалось) указывают HEAD и master. Нажатие на узел открывает дополнительные детали, такие как задействованные файлы и соответствующие различия.
.gitignore
Важным аспектом, который я не упомянул в предыдущем уроке по Git, является концепция файла .gitignore . Этот файл в основном содержит набор строк, указывающих, какие артефакты должны игнорироваться Git. Обычно это специфичные для IDE файлы или скомпилированные двоичные файлы.
Из коробки Git SCP уже создает тот, который подходит для Visual Studio. В противном случае вы можете обратиться к проекту Gitignore GitHub, который представляет собой набор файлов .gitignore для различных типов IDE и языков программирования.
Создать и зафиксировать новый файл
Просто добавьте новый файл в ваш проект Visual Studio. Я добавил Person.cs с некоторым контентом. Вы должны сразу увидеть изменения, перечисленные в окне Pending Changes.
Примечание. Вы можете открыть окно « Ожидающие изменения », щелкнув правой кнопкой мыши проект или файл решения Visual Studio и выбрав «Git (master)», а затем «Ожидающие изменения».
Опять же, как и прежде, выберите файлы, которые вы хотите включить, добавьте содержательный комментарий и зафиксируйте их.
Наше дерево после коммита выглядит так:
Создать (особенность) ветку
Чтобы создать новую ветку, нажмите кнопку « Расширения Git» в окне ожидающих изменений, а затем « Создать ветку».
Это действие откроет новое диалоговое окно, позволяющее вам сначала выбрать точку в истории, с которой вы хотите перейти, а затем указать ее имя:
Примечание: мы также устанавливаем флажок «Оформить заказ после создания», и сразу же переключаемся на новую ветку. Это как-то похоже на git checkout -b <branch-name> команду на оболочке.
Диалоговое окно подтверждения показывает успешность операции и выполненную команду в оболочке.
Более того, в окне Pending Changes мы теперь видим текущую ветвь, в которой мы находимся, которая является только что созданной «my-feature-branch».
Теперь мы можем изменить существующий файл — скажем, наш Person.cs — и зафиксировать его. Окно Pending Changes точно показывает разницу изменений до того, как мы их передадим
После внесения изменений дерево продвинулось и обратите внимание, что сейчас master и my-feature-branch указывают на разные места. HEAD находится в нашей ветви функций, поскольку она является текущей активной.
Слияние и разрешение конфликтов
Вернемся к мастеру . Мы можем сделать это — снова — используя кнопку ветви Checkout из меню «Git Extensions».
Мы должны выбрать в master качестве нашего филиала и продолжить.
Примечание: есть варианты того, как вы хотите обрабатывать любые локальные изменения, которые еще не были зафиксированы, то есть хранить их.
Дерево Git отражает это переключение на master ветку, так как оно HEAD теперь правильно указывает master снова.
Git является интерфейсом системы управления версиями по умолчанию в Visual Studio. Мы продолжаем расширять набор возможностей Git, постоянно анализируя результаты и учитывая ваши отзывы. Дополнительные сведения о недавно обновленных компонентах и ссылки на опрос, через который вы можете оставить свой отзыв, см. в записи блога, посвященной поддержке нескольких репозиториев в Visual Studio.
Теперь GIT является интерфейсом системы управления версиями по умолчанию в Visual Studio 2019. Начиная с версии 16.6 мы работаем над созданием набора функций на основе ваших отзывов. В версии 16.8 Git стал интерфейсом управления версиями по умолчанию для всех.
Мы продолжаем расширять набор возможностей Git в Visual Studio 2022. Дополнительные сведения о последнем обновлении компонентов см. в записи блога Поддержка нескольких репозиториев в Visual Studio.
Дополнительные сведения о Git
Использование GIT в Visual Studio
Мы подробно расскажем вам о том, как использовать новый интерфейс Git в Visual Studio. Однако если вы хотите сначала ознакомиться с кратким обзором, посмотрите следующее видео:
Длительность видео: 05:27 мин.
Существует три способа начать использование Git в Visual Studio для повышения производительности:
-
. Если ваш код не связан с GIT, можно создать новый репозиторий GIT. . Если код, с которым вы хотите работать, не находится на вашем компьютере, можно клонировать любые существующие удаленные репозитории. . Если у вас уже есть код на компьютере, его можно открыть с помощью пункта меню Файл > Открыть > Решение/проект (или Папка). Visual Studio автоматически определяет, имеется ли инициализированный репозиторий GIT.
Начиная с версии 16.8 Visual Studio 2019 включает полностью интегрированный интерфейс для работы с учетными записями GitHub. Теперь вы можете добавить в цепочку ключей учетные записи GitHub и GitHub Enterprise. Вы сможете добавлять и использовать их так же, как и учетные записи Майкрософт. Это позволит упростить доступ к ресурсам GitHub в Visual Studio. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.
Visual Studio включает полностью интегрированную учетную запись GitHub. Вы не только можете добавить учетные записи GitHub и GitHub Enterprise в цепочку ключей, но и использовать их так же, как учетные записи Майкрософт. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.
Создание репозитория GIT
Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. Подробные сведения см. в разделе Создание репозитория в Visual Studio.
Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. Для этого в строке меню выберите GIT > Создать репозиторий GIT. Затем в диалоговом окне Создание репозитория GIT введите свои данные.
Независимо от того, является ли репозиторий общедоступным или частным, лучше создать удаленную резервную копию кода, которая будет безопасно храниться в GitHub, даже если вы работаете сами по себе. Это также позволит вам получать доступ к коду с любого компьютера.
Вы можете создать исключительно локальный репозиторий GIT, выбрав параметр Только локальный. Вы также можете связать локальный проект с любым существующим пустым удаленным репозиторием, размещенным в Azure DevOps или у любого другого поставщика Git, с помощью параметра Существующий удаленный репозиторий.
Клонирование существующего репозитория GIT
В Visual Studio процесс клонирования прост. Пошаговые инструкции см. в разделе Клонирование репозитория в Visual Studio.
В Visual Studio процесс клонирования прост. Если вы знаете URL-адрес репозитория, который нужно клонировать, можно вставить его в разделе Расположение репозитория, а затем выбрать место на диске, в которое будет клонирован репозиторий.
Если вы не знаете URL-адрес репозитория, в Visual Studio можно легко перейти к существующему репозиторию GitHub или Azure DevOps и выбрать его.
Открытие существующего локального репозитория
После клонирования или создания репозитория GIT Visual Studio обнаружит его и добавит в список Локальные репозитории в меню GIT.
В нем можно быстро открывать репозитории GIT и переключаться между ними.
Просмотр файлов в обозревателе решений
При клонировании репозитория или открытии локального репозитория Visual Studio переключается в этот контекст GIT, сохраняя и закрывая все ранее открытые решения и проекты. Обозреватель решений загружает папку в корне репозитория Git и проверяет дерево каталогов на наличие просматриваемых файлов. К ним относятся такие файлы, как CMakeLists.txt или файлы с расширением SLN.
Visual Studio настраивает представление в зависимости от файла, загруженного в обозреватель решений:
- При клонировании репозитория, содержащего один SLN-файл, обозреватель решений напрямую загружает это решение.
- Если обозреватель решений не обнаруживает файлов SLN в репозитории, по умолчанию он загружает представление папки.
- Если репозиторий содержит несколько файлов SLN, то обозреватель решений выводит список доступных представлений для выбора.
Переключаться между текущим представлением и списком представлений можно с помощью кнопки Переключить представления на панели инструментов обозревателя решений.
Окно "Изменения GIT"
GIT отслеживает изменения файлов в репозитории в процессе работы и разделяет файлы на три категории. Это те же изменения, которые отображаются при вводе команды git status в командной строке.
- Файлы без изменений: эти файлы не были изменены с момента последней фиксации.
- Измененные файлы: эти файлы изменились с момента последней фиксации, но еще не были подготовлены для следующей фиксации.
- Промежуточные файлы: эти файлы содержат изменения, которые будут добавлены в следующую фиксацию.
В процессе работы Visual Studio отслеживает изменения в файлах проекта в разделе Изменения окна Изменения GIT.
Когда вы будете готовы подготовить изменения, нажмите кнопку + (плюс) для каждого из файлов, которые необходимо подготовить, или щелкните файл правой кнопкой мыши и выберите пункт Промежуточно сохранить. Можно также подготовить все измененные файлы одним щелчком мыши, используя кнопку "Промежуточно сохранить все" ( + ) в верхней части раздела Изменения.
При подготовке изменения Visual Studio создает раздел Подготовленные изменения. Только изменения из раздела Подготовленные изменения добавляются к следующей фиксации, которую можно выполнить, выбрав команду Зафиксировать промежуточные. Эквивалентная команда для этого действия — git commit -m "Your commit message" . Можно также отменить подготовку изменений, нажав кнопку – (минус). Эквивалентная команда для этого действия — git reset <file_path> для отмены размещения одного файла или git reset <directory_path> для отмены размещения всех файлов в каталоге.
Выбор существующей ветви
В Visual Studio текущая ветвь отображается в селекторе в верхней части окна Изменения GIT.
Текущая ветвь также доступна в строке состояния в правом нижнем углу интегрированной среды разработки Visual Studio.
В обоих местах можно переключаться между имеющимися ветвями.
Создание ветви
Можно также создать новую ветвь. Эквивалентная команда для этого действия — git checkout -b <branchname> .
Чтобы создать ветвь, достаточно ввести ее имя и указать существующую ветвь, на основе которой будет создана данная.
В качестве базовой можно выбрать существующую локальную или удаленную ветвь. Если флажок Извлечь ветвь установлен, вы автоматически переключитесь на новую ветвь после ее создания. Эквивалентная команда для этого действия — git checkout -b <new-branch><existing-branch> .
Окно "Репозиторий GIT"
В Visual Studio имеется новое окно Репозиторий GIT, в котором представлены все сведения о репозитории, включая все ветви, удаленные репозитории и журналы фиксации. Открыть это окно можно из меню GIT или Вид либо непосредственно из строки состояния.
Управление ветвями
При выборе в меню GIT пункта Управление ветвями отображается древовидное представление ветвей в окне Репозиторий GIT. В левой области можно использовать контекстное меню для извлечения, создания, объединения ветвей, перемещения изменений из одной ветви в другую, отбора изменений и других действий. Щелкнув ветвь, можно просмотреть ее журнал фиксаций в правой области.
При принесении ветви в окне Изменения GIT под раскрывающемся списком ветвей отображается индикатор, который показывает количество фиксаций, которые не были вытянуты из удаленной ветви. Он также показывает число локальных фиксаций, которые не были отправлены.
Сведения о фиксации
Разрешение конфликтов слияния
Во время слияния могут возникать конфликты, если два разработчика изменяют одни и те же строки в файле и GIT неизвестно, какой вариант правильный. В этом случае GIT прерывает слияние и сообщает о конфликтном состоянии.
Дополнительные сведения о конфликтах слияния и способах их обработки см. на странице Устранение конфликтов слияния.
В Visual Studio можно легко выявлять и устранять конфликты слияния. Во-первых, в верхней части окна Репозиторий GIT имеется золотистая информационная панель.
Но если ни одно из этих окон не открыто и вы переходите к файлу с конфликтами слияния, вам не придется искать следующий текст:
Редактор слияния
Редактор слияния в Visual Studio позволяет выполнять трехстороннее сравнение: в нем приводятся входящие изменения, текущие изменения и результат слияния. С помощью панели инструментов вверху редактора слияния можно переходить между конфликтами и просматривать результаты автоматического слияния в файле.
Настройка параметров GIT
Чтобы настроить параметры GIT на уровне репозитория, а также на глобальном уровне, выберите в строке меню пункты GIT > Параметры или Сервис > Параметры > Управление исходным кодом. Затем выберите нужные параметры.
Использование всех возможностей Team Explorer в Visual Studio
Новый интерфейс GIT — это система контроля версий по умолчанию в Visual Studio 2019 начиная с версии 16.8. Однако при желании этот интерфейс можно отключить. Чтобы вернуться в Team Explorer для Git, выберите Средства > Параметры > Среда > Функции предварительной версии и снимите флажок Новый пользовательский интерфейс Git.
Что дальше?
Хотя новый интерфейс Git теперь включен по умолчанию в Visual Studio 2019 начиная с версии 16.8, мы продолжаем добавлять новые функции для его совершенствования. Чтобы ознакомиться с новыми обновлениями интерфейса Git в предварительном выпуске, скачайте и установите его со страницы Visual Studio 2022, предварительная версия.
Мы продолжаем добавлять новые функции для расширения возможностей Git в Visual Studio. Дополнительные сведения о недавно обновленных компонентах и ссылки на опрос, через который вы можете оставить свой отзыв, см. в записи блога, посвященной поддержке нескольких репозиториев в Visual Studio.
Если у вас есть предложение, отправьте его нам. Мы будем рады вашему участию в работе над решением на портале Сообщества разработчиков.
В Visual Studio Code мне кажется, что мне разрешено только нажимать, извлекать и синхронизировать. Существует документированная поддержка конфликтов слияния, но я не могу понять, как на самом деле слить две ветки. Командная строка Git в VSC (нажмите F1) поддерживает только подмножество команд:
Попытка извлечь из альтернативной ветки или нажать на альтернативную ветвь дает:
Что я упускаю из виду?
Вы уверены, что проверили везде, qv этот блог, в котором обсуждается, как объединить две ветки?Обновление июнь 2017 г. (от VSCode 1.14 )
Возможность объединять локальные ветки была добавлена через PR 25731 и commit 89cd05f : доступная через команду " Git: merge branch ".
И PR 27405 добавил правильную обработку слияния в стиле diff3.
Вахид «s ответ Упоминание 1,17, но релиз сентября фактически не добавил ничего о слиянии.
Только октябрьская версия 1.18 добавила маркеры конфликтов Git
Начиная с версии 1.18, с помощью комбинации команды слияния (1.14) и маркеров слияния (1.18) вы действительно можете выполнять локальное слияние между ветвями.
Оригинальный ответ 2016 г .:
В документации по управлению версиями не упоминаются команды слияния, только статус слияния и поддержка конфликтов.
Даже последняя версия 1.3 июня не принесла ничего нового на фронт VCS.
Это поддерживается проблемой 5770, которая подтверждает, что вы не можете использовать VS Code как git mergetool , потому что:
Будет ли эта функция случайно включена в следующую итерацию?
Скорее всего, нет, это большая работа, поскольку необходимо реализовать интерфейс слияния .
Таким образом, фактическое слияние будет инициировано только из командной строки.
Я новичок в GIT, до сих пор я использовал TFS для Visual Studio Online для контроля версий и являюсь единственным разработчиком. Когда я создавал свой последний проект, я в некотором смысле вводил в заблуждение, что GIT был лучшим вариантом для этого.
Поэтому я зарегистрировался у своего хозяина. Затем, когда я собирался поработать над функцией, которую я прочитал, мне пришлось создать ветку (в TFS это было необязательно), поэтому я создал «development_print» как новую ветку и работал над своей функцией.
Теперь моя функция завершена, но я не знаю, как объединить ее с мастером. Сейчас я не заинтересован в нескольких ветвях, просто хочу, чтобы моя новая функция была объединена с мастером и осталась с мастером.
В VS есть опция ветка слияния , но она позволяет мне только слиться с development_print (я хочу, чтобы моя особенность была в master!), Поэтому она не позволяет мне установить Into Current Branch, а для Merge From Branch показано:
- Development_print
- мастер
- Происхождение / development_print
- Происхождение / мастер
Что немного сбивает с толку? кажется все задом наперед. Итак, как мне выйти из этого беспорядка, не потеряв всю работу, которую я делал над этой функцией?
3 ответа
Способ объединения ветки development_print с главной веткой приведен ниже:
VS -> Team Explorer -> Ветви -> Двойной щелчок по основной ветке -> Слияние -> выберите development_print для Слияния из ветви -> Слияние.
Поле выбора показывает:
Это означает, что у вас есть ветви development_print и master как для локальных, так и для удаленных. origin/ означает, что ветви существуют в удаленном.
Если вы не хотите ветку development_print после объединения, вы можете удалить ее для локальной и удаленной:
Team Explorer -> Филиалы -> выберите файл development_print -> щелкните правой кнопкой мыши -> Удалить -> выберите файл development_print в разделе удаленный доступ / источник -> Удалить филиал из удаленного узла.
Вы можете следовать руководству Microsoft "Создать работу в филиалах".
Кроме того, как показано в привыкании к Git в Visual Studio: Branches "из Jeremy Bytes (2014, но все равно должен применяться), вы можете вернуться в раздел« Branches »и выбрать« Merge ».
Это дает нам раскрывающиеся списки для заполнения:
Вы можете увидеть раздел ветки в "Управление жизненным циклом приложений Microsoft", также используется при создании ветки тем:
В VS переключитесь на основную ветвь, чтобы быть вашей текущей веткой, и из Team Explorer -> Branches вы должны получить параметры Merge в правильном порядке, где вы сможете выбрать в раскрывающемся меню «Merge from branch» ветку development_print и Поле «В текущую ветку» будет предварительно выделено мастером.
В Visual Studio Code кажется, что мне разрешено только нажимать, тянуть и синхронизировать. Существует документально подтвержденная поддержка конфликтов слияния, но я не могу понять, как на самом деле слить между двумя ветвями. Командная строка Git в VSC (нажмите клавишу F1) только облегчает подмножество команд:
Попытка тянуть от альтернативной ветви или Push к альтернативной ветви приводит к:
Что я пропускаю?
Обновление июнь 2017 (с VSCode 1.14 )
Возможность объединения локальных веток была добавлена с помощью PR 25731 и commit 89cd05f : доступна через команду " Git: merge branch ".
И PR 27405 добавлена правильная обработка слияния в стиле diff3.
Vahid s answer упомянуть 1.17, но это сентябрьский выпуск фактически ничего не добавило в отношении слияния.
Добавлен только один октябрь 1.18 Маркеры конфликтов Git
Начиная с версии 1.18, с помощью команды слияния (1.14) и маркеров слияния (1.18) вы действительно можете выполнять локальные слияния между ветвями.
Оригинальный ответ 2016:
В Version Control doc не упоминаются команды слияния, только статус слияния и поддержка конфликтов.
Даже последний выпуск 1.3 июня не принесет ничего нового в VCS.
Это поддерживается проблема 577 , которая подтверждает, что вы не можете использовать VS Code в качестве git mergetool , потому что:
Включена ли эта функция в следующую итерацию, случайно?
Вероятно, нет, это большое усилие, , поскольку необходимо реализовать интерфейс слияния .
Таким образом, фактическое слияние будет инициировано только из командной строки.
Читайте также: