Git для разработчиков Visual Studio и .NET

Пару недель назад я написал вступительную статью « Git Explained for Beginners », целью которой было представить Git новичкам на основе базовой структуры дерева Git. Поскольку эта статья оказалась довольно популярной, и поскольку в настоящее время я планирую представить для наших разработчиков .Net эту тему, я решил написать эту статью, используя аналогичный подход, но демонстрируя использование Git из Visual. Студия.

терминология

Для ознакомления с терминологией 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

В качестве одного из следующих шагов вам нужно правильно установить провайдера исходного кода в Visual Studio, поскольку у вас их может быть больше (например, TFS). Это делается в настройках Visual Studio в разделе «Source Control»:

Конфигурирование провайдера контроля версий

Вы должны увидеть запись «Git Source Control Provider». Выберите это и подтвердите ваши настройки. После этого вы также должны убедиться, что он правильно ссылается на ваши установки Git и Git Extensions:

Настройка вашего ключа SSH

Многие репозитории Git-сервера допускают разные модели аутентификации:

через https или
путем генерации ключа SSH .

Лично я предпочитаю последнее, так как ненавижу постоянно вводить свои учетные данные.

Чтобы получить руководство по генерации открытого ключа SSH, просто обратитесь к документации по GitHub, которая довольно подробно и хорошо объяснена.

Ну, вот и все, что касается установки. Теперь вы должны быть готовы начать.

Давайте начнем: создайте новый Git-репозиторий

Прежде всего, я просто создаю проект консоли, так как основное внимание здесь уделяется не созданию чего-то приятного и работающего, а скорее демонстрации интеграции Git в Visual Studio. Как только проект создан, мы можем настроить локальный репозиторий Git.

Это можно сделать, щелкнув правой кнопкой мыши по решению и выбрав «Создать Git Repository»:

После этой операции вы должны увидеть репозиторий для успешной настройки:

Более того, вы должны увидеть некоторые файлы, перечисленные в окне ожидающих изменений в Git:

Ожидающие изменения перечислены поставщиком контроля версий 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 точно показывает разницу изменений до того, как мы их передадим

Разница изменений, отображаемых в окне Pending Changes

После внесения изменений дерево продвинулось и обратите внимание, что сейчас masterи my-feature-branchуказывают на разные места. HEADнаходится в нашей ветви функций, поскольку она является текущей активной.

Слияние и разрешение конфликтов

Вернемся к мастеру . Мы можем сделать это — снова — используя кнопку ветви Checkout из меню «Git Extensions».

Мы должны выбрать в masterкачестве нашего филиала и продолжить.

Примечание: есть варианты того, как вы хотите обрабатывать любые локальные изменения, которые еще не были зафиксированы, то есть хранить их.

Дерево Git отражает это переключение на masterветку, так как оно HEADтеперь правильно указывает masterснова.

В этом разделе я хотел бы продемонстрировать, как разрешить конфликт слияния. Чтобы это работало, нам нужно создать еще один коммит, masterкоторый конфликтует с изменениями my-feature-branch. Таким образом, давайте изменим Person.csсоответственно.

Наше дерево теперь более четко отражает существование нашей ветви функций.

Выполнение слияния

Учтите , что мы хотим объединить изменения , сделанные в my-feature-branchк master. Этот процесс инициируется с помощью кнопки Merge из меню Git Extensions.

Откроется диалоговое окно, позволяющее нам указать детали слияния.

Прежде всего, мы выбираем название филиала, которое есть my-feature-branch. Тогда есть два других варианта:

«Держите один ветку , если это возможно (ускоренная перемотка вперед)» — быстрый вперед объясняется следующим

[…] Другими словами, когда вы пытаетесь объединить один коммит с коммитом, который можно получить, следуя истории первого коммита, Git упрощает задачу, перемещая указатель вперед, потому что нет другой работы по слиянию воедино — это называется «перемотка вперед». Git SCM: базовое ветвление и слияние

Очевидно, это работает только тогда, когда нет конфликтов.

«Всегда создавать новый коммит слияния» — это просто создаст новое сообщение коммита, явно указывающее, что что-то было слито.

Как и ожидалось, ускоренная пересылка завершается неудачно, и мы получаем уведомление о конфликте слияния

Окно Pending Changes показывает конфликт слияния

Git SCP спросит вас, нужно ли разрешать или игнорировать конфликты. Если вы ответите положительно, откроется диалоговое окно со всеми конфликтующими файлами.

Нажмите «Начать объединение», чтобы открыть настроенный инструмент объединения. В моем случае это открывает «kdiff3». Это может зависеть от вашей системы, в зависимости от того, как вы настроили установку Git.

После того, как вы разрешили все конфликты …

… Вы можете продолжить процедуру фиксации.

Опять же, дерево Git хорошо отражает слияние

Перейти к определенному коммиту

Переход к определенной фиксации довольно прост и может быть выполнен с помощью команды Browse из меню Git Extensions. Это открывает внешний графический интерфейс, визуализирующий дерево Git.

Оттуда вы можете использовать контекстное меню и нажать « Оформить заказ выбранной ревизии».

В результате вы перейдете в режим отсоединенной головы . На самом деле, посмотрите на дерево:

HEADбольше не указывает на ветку, но на конкретный коммит в истории. Чтобы вернуться назад, вы всегда можете просто выполнить проверку на masterкакой-либо произвольной ветви.

отмена

Откат может быть выполнен по-разному и с разными последствиями.

Файлы, не созданные для фиксации

Отменить локальные изменения, которые еще не были зафиксированы, довольно легко, и это можно сделать, просто щелкнув правой кнопкой мыши измененный файл и выбрав «Отменить изменения файла»

Ой, я забыл включить…

Если вы уже внесли изменения в свой репозиторий и узнаете, что забыли что-то включить в этот же коммит (например, комментарий к этой строке кода)…

Совершенное изменение, которое мы хотим отменить ..

… Тогда Git обладает приятной и удобной функциональностью: команда Amend Last Commit . Просто добавьте забытое изменение и нажмите кнопку.

В результате ваш последний коммит также будет включать эти изменения, не оставляя следов, что вы фактически сделали два разных коммита.

«Вернуть» уже совершенные изменения

Но теперь предположим, что мы хотим вернуться полностью, отменив последнее изменение, которое мы сделали. Мы хотим, однако, явно показать, что «возвращение» изменений.

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

Чтобы использовать функцию «отменить», используйте «Обзор» в меню Git Extensions, щелкните правой кнопкой мыши на коммите, который вы хотите отменить, и выберите « отменить коммит» :

Это внесет изменения, которые вы можете затем внести обратно в репозиторий Git.

Дерево после фиксации отмененных изменений:

Отменить уже совершенные изменения

Давайте посмотрим, что мы делали раньше:

мы добавили свойство к Person.cs
мы выполнили возврат добавления свойства

По сути, наши двое перекрывают друг друга. Поэтому, если мы находимся в нашем локальном репозитории и не синхронизировали эти изменения с каким-либо удаленным аналогом, мы могли бы подумать о том, чтобы полностью удалить обе фиксации из нашей истории. Это не приносит никакой пользы, кроме ведения домашнего хозяйства. Чтобы это произошло, мы можем использовать команду сброса . Мы выбираем момент времени (т.е. фиксацию), до которого мы хотим сбросить настройки, и нажимаем «Сбросить текущую ветвь сюда»:

У вас будут разные возможности

В этой ситуации я предпочитаю делать полный сброс, так как мне не важно сохранять изменения в каталоге. После сброса наше дерево Git не отслеживает предыдущие коммиты:

Совместное использование / синхронизация вашего репозитория

До сих пор мы работали исключительно с нашим локальным Git-репозиторием. Чтобы опубликовать наш репозиторий , чтобы поделиться им с друзьями, нам нужно отправить его в какое-нибудь удаленное место. Это можно сделать из меню Git Extensions, выбрав команду Push .

Откроется новое диалоговое окно, из которого вы можете выбрать удаленное местоположение.

Если вы еще не настроили какие-либо удаленные местоположения, вы должны сделать это с помощью «Управление удаленными».

Примечание. По соглашению «Git remote», указывающий на репозиторий источника, называется origin .

После успешной настройки пультов вы можете выбрать один из них и нажать на него.

… и успехов!

Теперь файлы находятся в удаленном хранилище, в моем случае на внутреннем сервере GitLab нашей компании:

клонирование

Точно так же ваш товарищ по команде должен выполнить противоположную операцию, а именно загрузить (клонировать) репозиторий, который вы только что открыли, на свою локальную рабочую станцию.

Чтобы клонировать существующий репозиторий, используйте меню Visual Studio и выберите команду « Клонировать репозиторий ».

Откроется диалоговое окно, в котором вы можете ввести URL-адрес хранилища Git, место назначения клона, а также ветку, которую вы хотите оформить (обычно master).

Дерево теперь также показывает ссылки на удаленные аналоги (origin / HEAD и origin / master).

Я хочу перенести проект TFS в Git

Если у вас уже есть проект, размещенный на TFS, и вы хотите перенести его в Git, вы можете использовать инструмент Microsoft git-tf .

Git-TF — это набор кроссплатформенных инструментов командной строки, которые облегчают обмен изменениями между TFS и Git. Git-TF Codeplex

Как описано на сайте проекта, вы можете просто выполнить клонирование вашего TFS-репозитория, например

git tf clone http://myserver:8080/tfs/collectionName $/TeamProjectA/Main --deep

Не забудьте --deepдополнение, чтобы убедиться, что вы копируете всю историю. В противном случае вы просто клонируете последний набор изменений TFS. После того, как вы успешно клонировали репозиторий TFS, вы можете просто добавить пульт дистанционного управления в свой новый репозиторий Git-сервера.

git remote add origin git@mygitserver.com:mygituser/myreponame.git

..и затем выполнить

git push -u origin master

Примечание:-u нужен , как вы публикуете в masterотрасли впервые на пульте ДУ.