22 ноября 2016 в 11:27

GitHub для пользователей Windows


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

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

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

Если вы вдруг не знакомы, то я хочу немного познакомить вас с системой управления версиями по имени Git. Под катом вас ожидает описание того, как использовать GitHub вместе с Visual Studio.

Актуальное расширение называется GitHub Extension for Visual Studio. Оно подходит для Visual Studio 2015 и выше. Скачать vsix можно с github странички или с Visual Studio gallery.

Установить расширение можно и при установке Visual Studio:


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

Push – отправка изменений из локального репозитория в удаленный репозиторий (в нашем случае он будет расположен на GitHub).

Fetch – получение изменений из удаленного репозитория для сравнения и возможного последующего слияния.

Merge – слияние. Применение изменений совершенных в другом репозитории текущим репозиторием. Что-то вроде объединения двух репозиториев.

Pull – комбинация fetching и merging. Сперва из удаленного репозитория получается список изменений, а затем изменения применяются к текущему репозиторию.

То есть, если кто-то кроме вас поработал и совершил изменения в репозитории GitHub, то вы можете последовательно совершить 2 действия: Fetch, а затем Merge. Или же вы можете сразу выполнить Pull. После этого в вашем локальном репозитории отобразятся совершенные изменения.

После установки GitHub Extension for Visual Studio, панель Team Explorer будет выглядеть так:


Если панель Team Explorer скрыта, то отобразить ее можно через меню «View» / «Вид». Подключившись к GitHub (нажав Connect… и введя логин с паролем) получим возможность склонировать репозиторий GitHub или создать новый (кнопочки Clone и Create):


При клонировании будут выведен список репозиториев к которым у вас есть доступ:


При создании репозитория, вы сможете ввести его название, описание и выбрать лицензию, в соответствии с которой разрешено использование кода:


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

На случай, если вы хотите очень хорошо спрятать от посторонних глаз котлету репозиторий, то вы можете пометить его как Private. Но для этого нужна платная подписка.

Для студентов GitHub предлагает специальное предложение — Student Developer Pack, которое в частности включает в себя бесплатное неограниченное количество приватных репозиториев.

После создания репозитория необходимо создать проект. Лично я предпочитаю наоборот, сначала создать проект и только затем его добавить в Git. Можно при создании проекта создать и репозиторий Git. Для этого достаточно поставить галочку.


Если эту галочку при создании проекта не поставить, а просто открыть проект в VS, то в меню Файл станет доступен пункт «Add to Source Control» / «Добавить в систему управления версиями»


После его нажатия, проект будет добавлен в систему управления версиями Git, и внутри папки с проектом будет создана локальная папка .git. В Team Explorer это будет выглядеть так:


Переключившись между Team Explorer и Solution Explorer можем совершить какие-то изменения в проекте. После любых изменений можно совершить коммит — своеобразную точку восстановления. Для этого вернемся в Team Explorer, в меню которого имеется кнопка с нарисованным на ней домиком. Нажатие на нее приведет вас в главное меню:


Кнопка «Changes» / «Изменения» позволит зафиксировать изменения (при этом обязательно необходимо указать комментарий с описанием изменений). Но все действия пока что будут совершены только с локальным репозиторием git.

При создании проекта иногда создается так называемый «Initial commit», в котором пишется что-то вроде «Проект был создан за три дня». Если вы только что создали проект, то изменений в нем пока что еще нет. А если изменений нет, то коммит создать не получится. Я добавлял строку с текстом, поэтому в комментарии постарался описать это коротко, но понятно:


Можно просмотреть совершенные изменения. Для этого на интересующем нас файле нужно вызвать контекстное меню и выбрать «Compare with Unmodified...» / «Сравнить с неизмененной…»


Получим примерно такое вот сравнение:


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

Теперь, давайте, опять перейдем в главное меню, нажав домик. Для того чтобы отправить изменения на GitHub необходимо нажать кнопку «Sync» / «Синхронизация».


Так как наш проект еще не был опубликован на GitHub, то нам предложат это сделать:


Кстати, .git вполне можно опубликовать не только на GitHub, но и на Visual Studio Team Services.

Если мы публиковали проект ранее, то в списке исходящих фиксаций будет расположен наш коммит:


Нажатие Push приведет к отправке изменений в репозиторий, расположенный на сервере GitHub.

Совершив для пробы некоторые изменения прямо через браузер в репозитории, расположенном на GitHub (да, так тоже можно), я снова зашел в синхронизацию и нажал Fetch:


Здесь двойным кликом можно открыть информацию о коммите:


И кликнув уже на файл просмотреть изменения:


В том же самом окне синхронизации можно просмотреть историю:


Историю можно просматривать в простом представлении и в подробном:



Теперь, давайте представим, что мы работаем в команде и кто-то другой уже совершил какие-то изменения в своем локальном репозитории и отправил из в GitHub. И вы тоже совершили изменения в том же самом файле и в той же самой строке. В таком случае при синхронизации с GitHub у вас возникнет конфликт:


Кликнув на Conflicts получим такое вот окошко в котором после клика на файле откроется меню с кнопкой Merge:


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


После внесения изменения нужно нажать Accept Merge (в верхнем левом углу), после чего сделать коммит:


Страничка самого расширения на GitHub: github.com/github/visualstudio

Github Desktop и PowerShell environment for Git


Github Desktop — утилита совершенно независимая и с Visual Studio никак не связанная. Скачать можно здесь.


Утилита доступна для пользователей Mac и Windows. Вместе с ней устанавливается и командная строка Git Shell. Фактически это PowerShell с набором скриптов для интеграции с Git. Называется PowerShell environment for Git. Сокращенно posh-git.

На GitHub страничке проекта posh-git можно найти краткую инструкцию о том, как установить командную строку posh для git вручную.

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

Чтобы просмотреть текущую конфигурацию и убедится, что Git присутствует, можно выполнить команду:

git config –list

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

git clone https://github.com/programmersommer/Barcode_Scanner_UWP.git BarcodeScanner

После выполнения этой команды, в текущей директории появится папка с проектом. Кроме http:// и https:// поддерживаются и протоколы SSH и git://. Если перейти в папку с проектом с помощью команды cd (в случае примера cd BarcodeScanner), то командная строка преобразится:


Строка статуса PowerShell отобразит текст posh~git, что обозначает, что вы попали в среду PowerShell для Git. Можно выполнить команду git status, чтобы узнать, не требуется ли синхронизировать локальный репозиторий. Ответ может быть таким:


Самые популярные команды это те, которые мы уже рассматривали в рамках интерфейса расширения VS: git fetch, git merge, git push. Если вы зайдете в директорию (наименование PortableGit_xxx директории, я так полагаю, может быть несколько иным):

C:\Users\{user_name}\AppData\Local\GitHub\PortableGit_284a859b0e6deba86edc624fef1e4db2aa8241a9\usr\bin

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

Например, если в директории проекта появится новый файл, то команда git status выдаст:


А значит добавить файл нужно командой git add index.html. Теперь изменения нужно подтвердить с помощью git commit. Эта команда откроет текстовый редактор, который установлен по умолчанию. В нем необходимо в первую строку ввести текст, описывающий совершенные изменения. Если начать строку с символа #, то это будет комментарий. Комментарии можно оставить в строках ниже. Если не оставить никакого текста с описанием коммита, то коммит не произойдет. Можно указать текст коммита сразу в коммандной строке с помощью параметра –m. Например: git commit –m «File index.html added»


Теперь можно с помощью git push отправить изменения в GitHub репозиторий. Если это ваш репозиторий. Чужой репозиторий вы можете скопировать к себе, создав развилку/копию репозитория — Fork. Сделав какие-то изменения, вы сможете предложить их автору оригинального репозитория создав pull request.

На этом позвольте завершить описание возможностей работы с GitHub для пользователей Windows. Если хотите продолжить изучение, то на MVA вы можете посмотреть курс GitHub for Windows Users
Алексей Соммер @asommer
карма
49,2
рейтинг 2,4
разработка универсальных приложений Windows

Комментарии (27)

  • 0
    Для Visual Studio Code тоже наверное есть аналогичное расширение?
  • +2

    Описка


    Можно указать текст коммита сразу в коммандной строке с помощью параметра –C

    Должно быть -m

    • 0
      Ну, да, спасибо, -C использует сообщение старого коммита и не открывает окно текстового редактора для правки текста.
  • +1
    Поиграться и вернуться в нормальный тёплый git-cli. Я по крайней мере так и сделал.
  • +12

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


    Если вы вдруг не знакомы, то я хочу немного познакомить вас с системой управления версиями по имени Git. Под катом вас ожидает описание того, как использовать GitHub вместе с Visual Studio.

    Автор хочет познакомить нас с Git, но дальше пишет про Github.


    Перед тем как продолжить, нужно выучить немного терминов.

    Push – отправка изменений из локального репозитория в репозиторий GitHub.

    Неправда! Push — отправка изменений из локального репозитория в любой удалённый репозиторий, необязательно Github!


    Напоследок, небольшой FAQ:


    Q: Github — самый популярный хостинг для Git-репозиториев?
    A: Да. По крайней мере, для проектов с открытым кодом.


    Q: Github — единственный хостинг для Git-репозиториев?
    A: Нет. Из популярных ещё есть Bitbucket и Gitlab. Кстати, Gitlab можно развернуть на своём сервере.
    А ещё, если вот эти красивые UI не нужны, то можно поднять голый Git-сервер на своём сервере.


    Q: Чтобы пользоваться Git, обязательно нужен хостинг для Git-репозиториев?
    A: Нет.

    • –7
      Ну, спасибо, что не замолчали.
      1. Для того чтобы научиться работать с GitHub необходимо познакомиться и с Git. Все верно. Что здесь не так?
      2. Push рассматривается в контексте работы с GitHub. Слово английское и означать может много что.
    • 0

      Более того, большая часть функционала, приписываемая GitHub Extension на самом деле встроена в VS. Без установленного расширения, в VS вы не сможете только:


      • зарегистрироваться на GitHub;
      • создать репозиторий на GitHub (но можно создать локальный репозиторий, и сделать push в любой уже существующий удаленный);
      • сделать clone, выбрав репозиторий из списка (но можно сделать clone набрав/вставив URL);
      • быстро открыть в браузере страницы Pulse, Graphs, Issues, Wiki;
      • создать Pull Request на основе существующего branch (но сам branch создать можно);
      • быстро открыть существующий Pull Request в браузере.

      В общем, расширение пока не дает чего-то особо полезного.

      • +1
        Как это не создать пул реквест? И открыть его в браузере можно.
        • 0

          Не совсем понял. Как можно без установленного GitHub Extension в VS создать Pull Request на GitHub или открыть его в браузере?
          Или речь идет о Pull Request для VSTS/TFS? Но оно, если не ошибаюсь, доступно только в VS Enterprise и не работает с GitHub.

          • 0
            Извиняюсь. Прочитал как вообще не создать пул реквест.
  • +1
    Использую Github Desktop, хотя дизайн его, конечно, абсолютная хипстота и оставляет желать сильно лучшего. Даже древняя черепаха и то удобнее.
  • 0
    Использую SourceTree совместно с BitBucket. Он позволяет приватные репозитарии делать.
  • 0

    вот кстати меня очень сильно удивляет, почему для windows до сих пор не существует нормального консольного клиента git. Под "нормальным" я подразумеваю то, что он как минимум


    • управляется с помощью командлетов powershell, со всем фаршем в виде автодополнения, возврата объектов, и т.п.;
    • не имеет никаких внешних зависимостей, в частности OpenSSL и GNU coreutils, и по максимуму использует встроенные в windows средства;
    • хранит ключи в стардартном месте. То есть в %APPDATA%, а лучше в специальном хранилище с ограниченным доступом
    • 0
      GitHub же предлагал поставить GitBash консоль, с подсветкой синтаксиса. Было довольно неплохо.
  • 0
    Если ваш проект хранится только у вас на диске, то с поломкой диска вас ожидают неприятности. Даже регулярный бэкап не всегда сможет вас спасти.

    Это конечно же, основной юзекейс на 2016 год :)


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

    А насколько нужны такие инженеры? Может их сначала в тренинг центр направить или коридоры подметать? Ну может, хотя бы ментора им назначить и запретить гадить в master?


    создав так называемую ветку — Fork

    Ветка это branch. Это, что называется, устоявшийся термин.
    Fork — это вилка, вилки нет, насколько я слышал, этот термин не переводится в рунете, а если и переводится то, скорее как клон или копия репозитория.


    Серьёзно, интеграция git в очередную ide без введения в git, да ещё и заточенную под конкретное ide и под github? Может тут ещё нужна подборка инфографики? Не, без комиксов точно — не разобраться.
    Напомнило это издание.


    Как по мне, основное назначение современных vcs, это организация контроля для объединения множеств изменений от набора организаций/команд/разработчиков в различные тематические подборки таких изменений, чаще всего именуемых релизами или версиями.


    Вы же предлагаете людям вводную заключённую в двойной vendor-lock без обьяснения процесов и принципов работы. Имхо прочтение git-magic (почти соразмерного вашей статье, картинок конечно меньше) в разы полезней.


    Определитесь это вводная в git или в набор интерфейсов доступных в windows для работы с git. Если, про набор интерфейсов список более чем не полный, начиная с официально поставляемых производителем этого ПО. Если про git — то тема не раскрыта.


    Если вы агент github и/или microsoft и это рекламная статья — примите мои глубочайшие извинения.

  • 0
    Подборка лучших советов из комментариев:
    1. Если вы пишете про GitHub, то пишите только про GitHub. GitHub и Git совершенно разные вещи, которые не взаимосвязаны.
    2. С помощью GitHub расширения для VS командой push можно отправить изменения в любой репозиторий
    3. В Visual Studio уже встроена поддержка GitHub и совсем не нужно рассказывать о каком-то еще расширении
    4. Если вы хотите внести вклад в чужой проект, то вам нужно сделать его branch
    • 0
      Если вы хотите внести вклад в чужой проект, то вам нужно сделать его branch

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


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


      В случае github, принято вносить вклад с помощью, как вы верно заметили — Fork'ов, но этот термин либо не переводится, либо переводится как клон или копия. Fork это по сути ещё один репозиторий, клонированный с исходного. Просто github(не git) ведёт подсчёт кто кого форкнул. И предоставляет дополнительные инструменты для того что бы упростить обмен между fork и upstream репозиториями. Понятие fork гораздо старше чем git, и произошло видимо от одноимённого вызова posix, который создаёт точную копию процесса. Например, IceWeasel это fork Firefox. Хотя гитом на тот момент ни один из этих проектов не пользовался.


      GitHub и Git совершенно разные вещи, которые не взаимосвязаны.

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

        • 0

          Так, и что по вашему тут означает термин "ветка"? Fork или branch?


          Topic branches (тематические ветки, слово "тематические" часто опускается), могут быть не только в вашем репозитории но и в его форках. Как упражнение можете подумать, почему на github бытует термин pull request а на gitlab и bitbucket например термин merge request. Это, видимо, обусловленно основными вариантами использования этих инструментов ну, и историческими причинами. Можно, например, посмотреть на различия github flow и оригинального gitflow.

          • 0
            Я понял ваше мнение. В нем есть логика.
            Да, для того, чтобы различать fork и branch, возможно, стоит говоря по-русски называть fork — клоном, а branch — веткой.
            Но какие могут быть претензии ко мне, если на официальном сайте (смотрите ссылку выше) англоязычный термин “fork” это создание ветвления проекта.
            • 0

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


              Из той же статьи на gh:


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

              А, учитывая, что страница на середине переходит на английский язык, видимо, сей первод ещё не очень то и готов. На что намекает, как минимум и то что pull request переведён как "запрос на слияние" хотя это скорее про merge request. Видимо автор перевода не придумал как перевести более точно (я вот тоже затрудняюсь).

              • +1
                Это тема для отдельного разговора вроде «Login или Log in?»
                Кстати, термин клон уже занят созданием локальной копии на компьютер, так что для fork не совсем подходит.
                • 0

                  Технически fork производится средствами clone.

                  • 0
                    Развилка хорошо по смыслу подходит и является синонимом ответвлению. Слова копия и клон этот смысл не передают.
                    • 0

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

  • +1
    Что вы все ругаетесь? Я вот в закладки сохраню… Неплохое введение, чтобы нубам показывать, а то не все с командной строки и прочих powershell'ов начинали… Понадобится им сделать что-то более трудоемкое — начнут копать и git и bash, а нет — так и…

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