company_banner

Работа с Git в Visual Studio 2012

    imageНекоторое время назад была опубликована статья «Интеграция Team Foundation Services с Git и другие новые возможности». Нас очень порадовало, что читатели проявили к ней живой интерес и прислали нам отзывы и вопросы. Мы учтем их в процессе совершенствования наших инструментов и услуг, так что следите за нашими новостями. В этой публикации хотелось бы рассказать, как разработчики могут начать использовать инструменты Git в Visual Studio и сервис Git в TFS.

    Прежде чем приступить, давайте вспомним ключевые моменты, указанные Брайаном Харри (Brian Harry):

    Развертывание на клиенте и сервере — это стандартный вариант применения Git. Клиент работает практически с любым репозиторием Git: локальным, корпоративным, Codeplex, GitHub, BitBucket… Служба TFS поддерживает практически любой клиент Git: служебные программы командной строки Git, XCode, службу поддержки Eclipse Git… Это базовый принцип, изложенный в первый день. Речь идет не о синхронизации, а о предоставлении полноценных и совместимых функций Git.


    Гибкость Visual Studio позволяет работать именно с тем, что нужно: локальной службой, службой TFS или сторонних поставщиков.
    Для того чтобы вы смогли работать с Git в Visual Studio 2012 вам необходимо установить Visual Studio Tools for Git.

    Создание новых локальных репозиториев



    Одно из основных преимуществ Git — возможность выполнения многих задач локально. Visual Studio обеспечивает несколько удобных способов создания локального репозитория:
    1. Создание пустого локального репозитория
    2. Создание нового решения в локальном репозитории системы управления версиями Git
    3. Размещение существующего решения в локальном репозитории системы управления версиями Git


    Создание пустого локального репозитория


    Итак, требуется создать пустой локальный репозиторий. В Visual Studio это можно сделать за считаные секунды.
    Перейдите на страницу Connect (Установить подключение) и создайте новый репозиторий.



    Откройте репозиторий. В командном обозревателе он будет задан в качестве активного.



    Сделайте commit файлам .gitattributes и .gitignore, созданные Visual Studio. Эти файлы необходимы для правильной работы Git в среде Visual Studio.




    Новый локальный репозиторий Git готов!

    Теперь его можно опубликовать, и его смогут использовать все члены рабочей группы.

    Создание нового решения в локальном репозитории



    Новый проект кода можно поместить в локальный репозиторий системы управления версиями Git.



    Данный вариант наиболее полно рассматривается в руководстве на портале Welcome Portal.

    Размещение существующего решения в локальном репозитории системы управления версиями Git


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




    Репозиторий создан. Осталось только сделать Сommit файлам.



    Добавление существующего локального репозитория


    Возможно, у вас имеется несколько репозиториев, для работы с которыми используются другие клиентские средства. Независимо от того, имеется ли удаленный доступ к локальному репозиторию, можно добавить его в Visual Studio: либо отдельный репозиторий, либо все репозитории из указанного каталога (см. пример ниже).



    Добавив репозиторий, откройте его и приступайте к работе в Visual Studio.



    Кстати, вы обратили внимание на полезную команду Open in Command Prompt (Открыть в командной строке)? Возможно, она понадобится вам для выполнения особых задач. Если средства командной строки еще не установлены, можно сделать это сейчас:



    Клонирование удаленного репозитория Git на компьютер разработчика



    Неважно, где размещен репозиторий Git — в TFS, CodePlex, GitHub, Bitbucket или другом месте. Visual Studio позволит работать с этим репозиторием. Чтобы начать совместную работу над кодом в удаленном репозитории, клонируйте код на свой компьютер.

    Клонирование репозитория Git TFS на компьютер разработчика


    Если вы приступаете к новому командному проекту Git либо просто настраиваете для этого компьютер, вам в любом случае нужно клонировать проект на компьютер.



    Клонирование стороннего репозитория Git на компьютер разработчика
    Рабочая группа хранит часть кода в GitHub или другой службе (например, CodePlex или Bitbucket)? Имеется возможность клонировать код на локальный компьютер и работать с ним в Visual Studio.



    Публикация локального репозитория



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

    Публикация в TFS


    Кроме того, код можно опубликовать в Team Foundation Service.



    Публикация в службе сторонних поставщиков


    Ветвь кода можно опубликовать в удаленном репозитории, размещенном у стороннего поставщика, например в CodePlex, GitHub или Bitbucket.



    После публикации



    После публикации ветви Visual Studio выполняет следующие действия:
    1. Задает локальный репозиторий в качестве удаленного.
    2. Отправляет активную ветвь (в большинстве случаев это «Master») в удаленном репозиторий.


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

    Управление подключениями


    Страница Connect (Установить подключение) — это нововведение, появившееся в Visual Studio 2012 Update 2. На этой странице показаны и доступны для контроля все репозитории, в которых осуществляется управление версиями.



    Щелкните правой кнопкой мыши по нужному репозиторию, а затем выберите Open (Открыть) или другую команду.



    Статьи о инструментах разработки


    Напоминаем что дополнительную информацию о различных аспектах возможностей Visual Studio вы можете узнать из блога Инструменты для разработчиков
    Microsoft
    775,00
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией

    Комментарии 30

      +6
      Помойму с git, удобней и понятней работать через консоль.
        +5
        В принципе ведь ничто и не мешает работать через консоль. Кому то так удобно, а кому то понравится интеграция в среду.
          –4
          В принципе ведь ничто и не мешает работать через консоль

          Убогая убогость консоли Windows мешает :)
            +4
            Откройте уже для себя ru.wikipedia.org/wiki/Windows_PowerShell
              0
              да, это лучше cmd — согласен -но всё же продолжает являться всё тем же огрызком нормальной консоли… Взять хотя бы отсутвие grep (закидывайте меня аналогами, закидывайте!), плюс куча отголосков и просто «у нас не так как у остальных» от MS.
                0
                Попробуйте cygwin/msys + mintty. Получите привычное окружение и неплохой эмулятор терминала.
                  +1
                  да, я статью на хабре читал. И это всё просто прекрасно, пока не попробушь консоль например в Linux… ммм… точнее пока не попробуешь и хотя бы чуть-чуть не раскуришь (ну для прокуренного виндузятника сразу прямо бойко и просто с консолью работать не получится — но это только дело привычки… хорошей привычки).
                    0
                    И гемморой при попытке из него запустить нечто, пытающееся использовать API виндовой консоли, да.
                      0
                      Это конечно в первую очередь касается гита.
                        0
                        Вы когда с гитом работаете, вы (если случай не примитивный) работаете не только с ним. Вполне возможно, что захочется запустить какой-нибудь скрипт на PowerShell, например, или, скажем, консольный NuGet. Да даже банальный git bisect run запускает внешнюю команду.
                    0
                    «Лучше cmd»… :) PowerShell — это настоящая объектная сценарная оболочка. По сути, почти «нормальный» язык программирования, недалеко (относительно, конечно) от C#. Сравнивать ее с текстовыми вообще не очень корректно, это другой уровень.

                    Можно такое сравнение привести — это как данные из plain text выдирать, или из JSON/XML.
                    Вроде конечно и из plain text выдрать можно, и некоторым даже нравится (можно регексом по нему шпарить), но, на мой скромный взгляд, для людей со структурным мышлением второе как-то пособнее будет.
                      0
                      хотел сначала ответ бааальшой написать…

                      … но в течение рабочего дня поддался-таки на провокацию и загрузил-таки PowerShell с сайта MS на рабочий офисный комп…

                      … поставил…

                      … запустил…

                      ввёл git commit --amend

                      … и увидел, что русские буквы в комментарии просто отсутсвуют — пустые пробелы и ничего больше — (комментарии в utf-8 на всякий случай, да-да не utf-16, или что там MS выбрала в качестве своего единоличного и правильного определения Unicode?)

                      cmd хоть бракозябры выводил :(

                      И после этого мне будут рассказывать про «настоящую объектную сценарную оболочку» :)

                      Весело это всё :)))

                      Да и убеждать .net программиста в том, что у них в кончерватории что-то не то — неблагодарное дело — он же полностью в Винде — другого особо и не знает, не щупал, не пробовал… А если и пробовал, то после первой же проблемы вынес вердикт, что «говно это всё», ведь на Винде проблемы ближе и привычнее :) Знаю, сам таким был :)
                        0
                        Жаль, что у вас негативный опыт :)
                        Честно говоря, я этот аспект (удобство оболочки в смысле сидения в ней как в постоянной основной рабочей среде) мало знаю, ибо (кто бы мог подумать :) ) не работаю в консоли постоянно.

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

                        Я скорее говорю именно про язык PS, а не интерфейс программы-консоли PS.

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

                        На PS я в привычном мне объектно-ориентированном стиле описал структуру среды, структуру развертываемого решения. Конфигурации сред просто как DSL читаются (ну, по сути это и есть DSL). И это все чудо заработало чуть не с первого раза.

                        Что не так и удивительно, т.к. набирал я код большей части в PowerShellISE, где даже автозаполнение по полям и методам PS-объектов есть. И не только PS-объектов, а весь .NET Framework и любые кастомные классы тоже вызываются «как родные».

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

                        А, например, для C#-ра, которому иной раз надо что-то там заавтоматизировать, PS — находка.
                          0
                          У меня не негативный опыт — он у меня разный…

                          Я могу вам сказать, что в своё время я был прожжёным виндузятником, и не с первого раза перешёл в какой-то мере на linux. Это было сложно, жутко непривычно, потому что многое там оказалось другим, а что-то и просто не работало (в Винде на самом деле также, как я понял со временем — просто все привыкли)… И подходы, как ни странно тоже…

                          Но немного (поверьте, реально немного — просто лень переборол на один вечер) разобравшись в работе с консолью, освоив основные её хаки в linux, увидел ту самую настоящую красоту, который, к сожалению, я не смог увидеть в Виндоуз за долгие годы…

                          Но я не стал прямо прожжённым линуксойдом: без графики жить не могу, да и прекрасно осознаю, что в linux полно своих проблем, с которыми виндузятники вряд ли когда-нибудь встретятся… Но это точно не консоль — там это на высшем уровне!

                          А вот столкнувшись на второй буквально команде в PS с той болью, что я испытывал долгие вечера, отлаживая bat-скрипты (было дело, каюсь) — как-то даже расхотелось дальше возиться, хотя я примерно и понимаю в чём проблема :)
                    +2
                    Он тормоз дикий, да и всё равно в окошке cmd пускается и имеет пачку своих проблем. Лучше уж bash+conemu для работы с гитом.
                      0
                      У него есть своё окно…
                        0
                        А чем оно лучше cmd.exe? По мне так те же яйца но в профиль, то же отсутствие истории между сеансами, те же сложности с копипастом.
                –2
                Даже больше, надежней и быстрее. И работает одинаково везде, я например, на VS2010 еще сижу.
                  0
                  Конечно, особенно разрешать конфликты под win32.
                    0
                    Ну не всегда. Это в случаях с сильным разветвлением хорошо, а если просто синхронизироваться с мастером, то консоль — это лишнее.
                    +1
                    Есть ли в планах поддержка Mercurial?
                      0
                      Пока ничего не можем сказать по этому поводу.
                        0
                        Надеюсь Вы прикрутите его в скором времени :)
                      0
                      Ни на одной из версий не получилось подключиться к своему git-серверу (не TFS или github) :(
                      репозитории в формате: gsis@repo.example.com:project.git

                      С локальными репозиториями работать довольно удобно, но без подключения к серверу — неюзабельно :(
                        0
                        попробуйте gsis@repo.example.com:project
                        без .git
                          0
                          Не помогло :(
                          Кстати у меня авторизация по ключу, а не паролю. Подозреваю, что из-за этого :(
                        +1
                        А в не облачном TFS он уже работает нормально? Не нужно использовать уже TFS-Git?
                          0
                          А мержить как?
                            0
                            Планируется ли (в Visual Studio Tools for Git) поддержка MSVS 2010?
                              0
                              Все круто. Но самая главная проблема — при использовании гита на visualstudio.com нельзя редактировать build definitions -> таким образом нельзя деплоить azure приложения прямо с билд сервера. Это очень расстроило.

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

                              Самое читаемое