Использование интеграции Git в Visual Studio Code
Редактор Visual Studio Code (VS Code) стал одним из самых популярных для веб-разработки. Его популярность обусловлена множеством встроенных возможностей, в том числе интеграции с системой контроля исходного кода, а именно с Git. Использование возможностей Git из VS Code позволяет сделать рабочие процессы более эффективными и надежными.
В этом учебном модуле мы изучим интеграцию контроля исходного кода в VS с помощью Git.
Предварительные требования
Для этого обучающего модуля вам потребуется следующее:
- Git, установленный на вашем компьютере. Более подробную информацию о том, как добиться этого, можно найти в учебном модуле Введение в Git.
- Последняя версия Visual Studio Code, установленная на вашем компьютере.
Шаг 1 — Знакомство с вкладкой Source Control
Прежде всего, чтобы воспользоваться преимуществами интеграции контроля исходного кода, следует инициализировать проект как репозиторий Git.
Откройте Visual Studio Code и запустите встроенный терминал. Вы можете открыть его, используя сочетание клавиш CTRL + ` в Linux, macOS или Windows.
Используя терминал, создайте каталог для нового проекта и перейдите в этот каталог:
Затем создайте репозиторий Git:
Также вы можете сделать это в Visual Studio Code, открыв вкладку Source Control (иконка выглядит как развилка дороги) в левой панели:
Затем нажмите кнопку Open Folder:
При нажатии кнопки откроется проводник файлов, где будет открыт текущий каталог. Выберите предпочитаемый каталог проекта и нажмите Open.
Затем нажмите Initialize Repository:
Если теперь вы посмотрите на свою файловую систему, вы увидите, что она содержит каталог .git . Чтобы сделать это, используйте терминал для перехода в каталог проекта и вывода его содержимого:
Вы увидите созданный каталог .git :
Это означает, что репозиторий инициализирован, и теперь вам следует добавить в него файл index.html .
После этого на панели Source Control вы увидите, что рядом с именем вашего нового файла отображается буква U. Обозначение U означает, что файл не отслеживается, то есть, что это новый или измененный файл, который еще не был добавлен в репозиторий:
Вы можете нажать значок плюс (+) рядом с файлом index.html , чтобы включить отслеживание файла в репозитории.
После этого рядом с файлом появится буква A. A обозначает новый файл, который был добавлен в репозиторий.
Чтобы записать изменения, введите команду отправки в поле ввода в верхней части панели Source Control. Затем нажмите иконку отметки check для отправки файла в репозиторий.
После этого вы увидите, что несохраненных изменений нет.
Теперь добавьте немного содержания в файл index.html .
Вы можете использовать ярлык Emmet для генерирования базовой структуры кода HTML5 в VS Code, нажав ! , а затем клавишу Tab . Теперь добавьте что-нибудь в раздел , например, заголовок , и сохраните файл.
На панели исходного кода вы увидите, что ваш файл изменился. Рядом с именем файла появится буква M, означающая, что файл изменен:
Для практики давайте запишем это изменение в репозиторий.
Теперь вы познакомились с работой через панель контроля исходного кода, и мы переходим к интерпретации показателей gutter.
Шаг 2 — Интерпретация показателей Gutter
На этом шаге мы рассмотрим концепцию Gutter («Желоб») в VS Code. Gutter — это небольшая область справа от номера строки.
Если ранее вы использовали сворачивание кода, то в области Gutter находятся иконки «Свернуть» и «Развернуть».
Для начала внесем небольшое изменение в файл index.html , например, изменим содержание внутри тега . После этого вы увидите, что измененная строка помечена в области Gutter синей вертикальной чертой. Синяя вертикальная черта означает, что соответствующая строка кода была изменена.
Теперь попробуйте удалить строку кода. Вы можете удалить одну из строк в разделе вашего файла index.html . Обратите внимание, что в области Gutter появился красный треугольник. Красный треугольник означает строку или группу строк, которые были удалены.
Теперь добавьте новую строку в конец раздела и обратите внимание на зеленую полосу. Вертикальная зеленая полоса обозначает добавленную строку кода.
В этом примере описаны индикаторы области Gutter для случаев изменения, удаления и добавления строки:
Шаг 3 — Просмотр отличий файлов
VS Code также позволяет посмотреть отличия между разными версиями файла. Обычно для этого нужно загружать отдельный инструмент diff, так что встроенная функция повысит эффективность работы.
Чтобы посмотреть отличия, откройте панель контроля исходного кода и дважды нажмите на измененный файл. В этом случае следует дважды нажать на файл index.html . Откроется типовое окно сравнения, где текущая версия файла отображается слева, а ранее сохраненная в репозитории версия — справа.
В этом примере мы видим, что в текущей версии добавлена строка:
Шаг 4 — Работа с ветвлением
Вы можете использовать нижнюю панель для создания и переключения ветвей кода. В нижней левой части редактора отображается иконка контроля исходного кода (которая выглядит как дорожная развилка), после которой обычно идет имя главной ветви или ветви, над которой вы сейчас работаете.
Чтобы создать ветвление, нажмите на имя ветви. Откроется меню, где вы сможете создать новую ветвь:
Создайте новую ветвь с именем test .
Теперь внесите изменение в файл index.html , чтобы перейти в новую ветвь test , например, добавьте текст this is the new test branch .
Сохраните эти изменения ветви test в репозитории. Затем нажмите на имя ветви в левом нижнем углу еще раз, чтобы переключиться обратно на главную ветвь master .
После переключения обратно на ветвь master вы увидите, что текст this is the new test branch , сохраненный для ветви test , отсутствует в главной ветви.
Шаг 5 — Работа с удаленными репозиториями
В этом учебном модуле мы не будем вдаваться в детали, но панель Source Control также предоставляет доступ для работы с удаленными репозиториями. Если вы уже работали с удаленными репозиториями, то вы увидите знакомые вам команды, такие как pull, sync, publish, stash и т. д.
Шаг 6 — Установка полезных расширений
В VS Code имеется не только множество встроенных функций для Git, но и несколько очень популярных расширений, добавляющих дополнительные функции.
Git Blame
Это расширение дает возможность просматривать информацию Git Blame в панели состояния для текущей выделенной строки.
Английское слово Blame имеет значение «винить», но не стоит беспокоиться — расширение Git Blame призвано сделать процесс разработки более практичным, а не обвинять кого-то в чем-то плохом. Идея «винить» кого-то за изменения кода относится не к буквальному возложению вины, а к идентификации человека, к которому следует обращаться с вопросами в отношении определенных частей кода.
Как вы видите на снимке экрана, это расширение выводит на нижней панели инструментов небольшое сообщение, указывающее, кто изменял текущую строку кода, и когда было сделано это изменение.
Git History
Хотя вы можете просматривать текущие изменения, сравнивать версии и управлять ветвлением с помощью встроенных функций VS Code, они не дают возможности просматривать историю Git. Расширение Git History решает эту проблему.
Как можно увидеть на снимке ниже, это расширение позволяет тщательно изучать историю файла, автора, ветви и т. д. Чтобы активировать показанное ниже окно Git History, нажмите на файл правой кнопкой мыши и выберите пункт Git: View File History:
Также вы сможете сравнивать ветви и записанные в репозиторий версии, создавать ветви из записанных версий и т. д.
Git Lens
GitLens дополняет возможности Git, встроенные в Visual Studio Code. Это расширение помогает визуализировать принадлежность кода через аннотации Git Blame и линзу кода, просматривать и изучать репозитории Git из среды VS Code, получать полезные аналитические данные с помощью мощных команд сравнения, а также выполнять многие другие задачи.
Расширение Git Lens — одно из самых мощных и популярных среди сообщества разработчиков расширений. В большинстве случаев его функции могут заменить каждое из вышеперечисленных двух расширений.
В правой части текущей строки, над которой вы работаете, отображается небольшое сообщение о том, кто внес изменение, когда это было сделано, а также сообщение о записи изменения в репозиторий. При наведении курсора на это сообщение выводится всплывающий блок с дополнительной информацией, включая само изменение кода, временную метку и т. д.
Также данное расширение предоставляет много функций, связанных с историей Git. Вы можете легко получить доступ к разнообразной информации, включая историю файлов, сравнение с предыдущими версиями, открытие определенных редакций и т. д. Чтобы открыть эти опции, вы можете нажать на текст на нижней панели состояния, где указан автор, изменивший строку кода, а также время ее изменения.
При этом откроется следующее окно:
Это расширение имеет очень много функций, и потребуется время, чтобы разобраться со всеми открываемыми им возможностями.
Заключение
В этом учебном модуле вы научились использовать интеграцию с системой контроля исходного кода в VS Code. VS Code предоставляет множество функций, для использования которых раньше нужно было загружать отдельный инструмент.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Как настроить чтобы файлы проекта в директории локального репозитория не исчезали при смене ветки git в программе VS Code?
При работе с репозиторием через программу SmartGit если создается и выбирается новая ветка, то файлы из других веток никуда не пропадают и видны в директории локального репозитория. А если создавать или выбирать ветку в программе VS Code, то файлы и каталоги других веток пропадают из директории локального репозитория. Как это исправить? Вот был похожий вопрос, но там не было решения как это изменить: Куда уходят папки и файлы при смене ветки Git или переход на другой комит, в локальном репозитории?
Отслеживать
задан 20 июн 2022 в 20:48
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Я использую git stash для того, чтобы «спрятать» изменения в какой-либо ветке перед переходом/созданием другой. После переключения обратно просто извлекаю stash. Можно для этого использовать и меню в VS Code.
Отслеживать
ответ дан 20 июн 2022 в 21:05
Михаил Шамшурин Михаил Шамшурин
1 1 1 бронзовый знак
У меня VS Code при нажатии Pop Stash (извлечь спрятанное) выдает There are no stashes in the repository.
21 июн 2022 в 7:51
@Святослав Скорее всего ты сначала ничего не добавил в stash. ДОбавляешь в stash — перключаешься на дргую ветку — делаешь что тебе надо в этой ветке — возврращаешься назад — делаешь pop stash. Попробуй еще расширение для VS Code «Git Lens». Там можно будет посмотреть тайники, которые ты создавал. Меню с изменениями слева и там внизу будет меню «STASHES».
3.5 Ветвление в Git — Удалённые ветки
Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространённым способом является использование веток слежения.
Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удалённым репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Имена веток слежения имеют вид / . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .
Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.
Примечание
«origin» — это не специальное название
Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .
Рисунок 30. Серверный и локальный репозитории после клонирования
Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.
Рисунок 31. Локальная и удалённая работа может расходиться
Для синхронизации ваших изменений с удалённым сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.
Рисунок 32. git fetch обновляет ветки слежения
Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add , как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.
Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки
Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone , которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin , Git ничего не получит, но создаст ветку слежения с именем teamone/master , которая будет указывать на тот же коммит, что и ветка master на сервере teamone .
Рисунок 34. Ветка слежения teamone/master
Отправка изменений
Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.
Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :
$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfixЭто в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.
Примечание
Не вводите каждый раз свой пароль
Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.
Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .
Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.
В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :
$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfixНеобходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.
Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:
$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .
Отслеживание веток
Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.
При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b / . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :
$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:
$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:
$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .
Если у вас уже есть локальная ветка и вы хотите настроить её на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.
$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.Примечание
Сокращение Upstream
Если у вас настроена отслеживаемая ветка, вы можете ссылаться на неё с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .
Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.
$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something newИтак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удалённую ветку.
Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:
$ git fetch --all; git branch -vvПолучение изменений
Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.
Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.
Удаление веток на удалённом сервере
Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:
$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfixВсё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.
Git и Visual Studio: как правильно приготовить
Некоторое время назад мы анонсировали поддержку Git в Visual Studio и TFS. Для того, чтобы научиться правильно готовить все это, я сам прошел весь путь и хочу рассказать вам о нем. Ниже — о том, как использовать Git в VS.
Что нужно:
Зарегистрировать бесплатный аккаунт Visual Studio Online
Скачать и установить Visual Studio 2012/2013
На установленную студию поставить Visual Studio Tools for Git
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
Чтобы сделать Pull и получить последние апдейты от команды, нужно перейти на Commits и нажать Fetch для того, чтобы сначала посмотреть, что там вообще придет (и есть ли чему придти).
Все хорошо — нажмем Pull и получим последний апдейт. Дополнительные сведения можно найти тут — Pull changes from the team.
Push
C Push все просто — в том же окне Commits нажмем Push. Получим сообщение о том, что все хорошо. Почитать подробнее про Push можно здесь — Push your changes.
Использование бранчей
Для использования бранчей в Team Explorer выделена специальная секци Branches.
После подключения к репозиторию доступна только master.
Создадим новый бранч, нажав New Branch.
Поскольку бранчи Git локальны до момента Push, новый бранч будет размещен в Unpublished Branches. Поменять бранч для коммитов можно на уже упоминавшейся выше странице Commits.
Замерджить контент можно, нажав Merge и выбрав бранчи. Подробнее про бранчи и мерджи — Git Branching.
Если в процессе мерджа или пулла возникнут конфликты, они тут же могут быть разрезолвены (самые простые, конечно).
Для просмотра истории достаточно нажать View History в контекстном меню бранча.
По нажатию на коммит получим подробные сведения о том, что произошло.
Многое из этого также доступно на портале TFS. Для того, чтобы перейти туда из VS, нужно на странице проекта в Team Explorer нажать Web Portal.
Уже на портале можно изучить общее состояние репозитория…
… и подробную информацию об этих коммитах.
Резюме
Мы кратко посмотрели на то, как выглядит очень простой процесс взаимодействия Visual Studio и Git. Как говорилось в самом начале, плод интеграции Git в Visual Studio — это не намек на то, что Visual Studio полностью заменит рабочий процесс. Но то, что одна из самых популярных IDE стала отлично поддерживать одну из самых популярных систем контроля версий — это, на мой взгляд, замечательный факт, и обязательно понравится тем, кто использует и то и другое.
- Блог компании Microsoft
- Git
- Visual Studio