github desktop для чего нужен

Практическое занятие «Используем клиент GitHub для десктопа»

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

Типичный процесс использования десктопного клиента

В этом разделе мы научимся использовать десктопный клиент GitHub для управления процессом Git.

Для настройки репозитория Git используя клиента GitHub Desktop:

В списке измененных файлов зеленый знак + означает добавление нового файла. Желтый круг означает изменения существующего файла.

Если посмотреть репозиторий в сети, то увидим, что внесенные изменения были перенесены в основную ветку в источнике. Можно перейти на вкладку History в клиенте GitHub Desktop (вместо вкладки Changes) или перейти в меню View > Show History, чтобы просмотреть ранее внесенные изменения.

Создание ветки

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

После создания ветки, в центре раскрывающееся меню будет указывать на ту ветку, в которой мы работаем. Создание ветки копирует существующий контент (из ветки master) в новую ветку (development).

Изменения в файле показывают удаленные строки красным и новые строки зеленым цветом. Цвета помогают увидеть, что изменилось.

Обычно новую ветку создают, когда вносят значительные изменения в контент. Например, нужно обновить раздел («Раздел X») в своих документах. Возможно, опубликовать другие обновления не нужно, прежде чем публиковать подробные изменения в Разделе X. Если работа была в той же ветке, было бы сложно выборочно загружать обновления для нескольких файлов за пределами Раздела X без отправки обновлений, которые сделали к файлам в разделе Х.

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

Слияние (merge) ветки development с master

Теперь научимся объединять наши ветки.

После слияния веток изменения будут отображаться и в файле в ветке master.

После этого наши изменения будут отображены в репозитории на GitHub.

Слияние ветки через pull request

Теперь объединим ветку development с master, используя процесс pull request. Мы притворимся, что клонировали репозиторий разработчика, и хотим, чтобы разработчик влил наше изменение в ветку development. (Другими словами, у нас может нет прав на слияние веток в мастер.) Для этого мы создадим запрос на извлечение (pull request).

На сайте GiHub pull request выглядит так:

Pull Request

Стрелка влево (указывающая из ветви development в направлении master) указывает, что запрос на извлечение («PR») хочет объединить ветку development с основной веткой.

Чтобы увидеть, какие изменения объединяются с мастером, можете щелкнуть вкладку Files changed (которая появляется на дополнительной навигационной панели вверху). Затем кликаем Merge pull request для объединения в ветке и Confirm merge, чтобы завершить объединение.

Теперь получим обновления, которые мы слили в master ветку, в свою локальную копию. В GitHub Desktop выбираем master ветку и кликаем кнопку Fetch origin. Fetch получает последние обновления из источника, но не обновляет локальную рабочую копию с изменениями.

После нажатия кнопка Fetch origin изменится на Pull Origin.

Проверим файлы и обратим внимание, что обновления, которые изначально были в ветке development, теперь отображаются и в master.

Управление конфликтами слияния

Предположим, мы внесли изменения в свою локальную копию файла в хранилище, а кто-то другой изменяет этот же файл, используя интерфейс браузера GitHub.com. Изменения противоречат друг другу. Что происходит?

Когда нажимаем Push origin от клиента GitHub Desktop, увидим сообщение о том, что хранилище было обновлено с момента последнего извлечения:

Кнопка, которая раньше говорила «Push origin», теперь говорит «Pull origin». кликаем «Pull origin». Теперь получаем еще одно сообщение об ошибке, которое говорит:

Если решим зафиксировать свои изменения, то увидим сообщение, которое гласит:

GitHub Desktop отображает восклицательный знак рядом с файлами с конфликтами слияния. Откройте файл конфликта и найдите маркеры конфликта ( и >>>>>>> ). Например, такие:

Устраняем все конфликты, изменив содержимое маркеров, а затем удалив маркеры. Например, обновите содержимое до этого:

Теперь нужно снова добавить файл в Git. В GitHub Desktop внесем изменения в обновленные файлы. Кликаем Push origin. Обновления на локальном компьютере отправляются на удаленный компьютер без каких-либо конфликтов.

Заключение

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

Источник

Как работать в программе GitHub Desktop

Самая короткая инструкция о том, как сохранить файлы в GitHub и ничего не сломать. И самое главное — никакой консоли, всё через окошки и с помощью мышки. Для этого используем GitHub Desktop.

Внимание! GitHub Desktop не работает на Windows 7 x32, поэтому если у вас эта версия системы, обновитесь до Windows 10 или воспользуйтесь программой GitKraken на свой страх и риск.

В этой статье идёт рассказ о системах контроля версий. Если вы совсем ничего о них не знаете, прочитайте статьи «Словарь терминов для Git и GitHub» и «Введение в системы контроля версий», чтобы понять терминологию и разобраться, зачем мы вообще это делаем.

Регистрация и вход

Если у вас ещё нет аккаунта на GitHub, то о его создании есть отдельная статья в блоге Академии.

После первого входа в GitHub Desktop вас попросят ввести ваши логин и пароль от GitHub.com. После этого у вас появится доступ ко всем репозиториям, сохранённым в профиле.

Создание репозитория

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

На главном экране GitHub Desktop выбираем пункт «Create a New Repository on your hard drive».

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

После этого нажимаем на Create repository, ждём несколько секунд и готово — на компьютере появилась папка, которой можно пользоваться для разработки вашего проекта.

Клонирование репозитория

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

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

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

Работа с репозиторием. Меняем файлы и сохраняем обратно

Вне зависимости от того, создали вы репозиторий или клонировали его, так выглядит GitHub Desktop с открытым репозиторием, в котором мы пока ничего не меняли.

Слева — поле для измененных файлов, справа — служебная информация. Слева снизу — поле для коммитов.

Если не усложнять, то склонированный репозиторий это просто каталог на компьютере. Можно нажать «Show in Finder» на Mac или «Show in Explorer» в Windows и откроется папка, где лежат все файлы, которые есть в репозитории.

Давайте добавим какой-нибудь файл. Например, я добавил в локальный репозиторий (скопировал в папку) файл index.html, который взял отсюда. Вы можете загрузить файл с кодом вашего проекта или изменить уже существующий.

Сразу после добавления или изменения файла в окне GitHub Desktop будет видно, что изменилось — если мы добавили целый новый файл, то все строчки будут с плюсиками и зелёные. Это значит, что они были добавлены в файл и GitHub Desktop раньше их никогда не видел.

Загружаем новый репозиторий на GitHub

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

После того, как мы добавили какой-то код в свежесозданный репозиторий, нужно сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Текст должен быть лаконичным и в то же время сообщать о том, что делает коммит. Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте». Вводим имя жмём большую синюю кнопку «Commit to main»

Изменения, которые мы внесли и сохранили, пока локальны. Их нужно послать на GitHub. Чтобы опубликовать свежесозданный репозиторий на GitHub, нажмите Publish repository.

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

Готово — после этого репозиторий появится в вашем профиле на GitHub.com.

Добавляем код и коммитим изменения

Репозиторий создан и загружен на GitHub, теперь нужно добавить немного кода.

Когда вы допишете код в файлы, которые находятся в репозитории, вы сможете просмотреть все их изменения в окне GitHub Desktop. Вот здесь, например, мы изменили «второй» на «третий» в тексте страницы — и изменения сразу видны, можно проверить, что всё исправленное будет загружено.

Дальше действуем по проверенной схеме — коммитим изменения.

В центре главного экрана появится предложение запушить коммит в удалённый репозиторий. Соглашаемся и жмём Push origin.

Готово! Теперь, если зайти на GitHub.com, в наш репозиторий, увидим уже изменённый файл, который мы только что отправили.

Всё получилось — теперь вы можете создать или склонировать репозиторий, добавить туда файлы, опубликовать всё это на GitHub.com, не прикасаясь к консоли. Это ли не чудо!

В этой статье была показана работа только с основной веткой репозитория. Если вы хотите разобраться, как создавать новые ветки (и зачем это нужно) и добавлять их в основную ветку, прочитайте статью «Работа с git через консоль». Это более сложная статья, поэтому можете сделать небольшой перерыв и вернуться к ней позже.

Источник

Github desktop для чего нужен

👨‍💻 Практическое занятие: Используем клиент GitHub для десктопа

Типичный процесс использования десктопного клиента

В этом разделе мы научимся использовать десктопный клиент GitHub для управления процессом Git.

Вместо работы в Wiki GitHub (как делали в предыдущем разделе по GitHub ), будем работать в обычном Git-репозитории. В Wiki GitHub есть некоторые ограничения, когда дело касается отправки запросов.

Для настройки репозитория Git используя клиента GitHub Desktop:

выбор адреса клонирования репозитория

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

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

Закоммитим изменения в левом нижнем углу и кликнем на Commit to development.

Нажимаем Publish branch (в верхней части окна GitHub Desktop), чтобы сделать локальную ветку также доступной в Origin (GitHub). (Всегда существует две версии ветки: локальная версия и удаленная версия.)

Слияние (merge) ветки development с master

Теперь научимся объединять наши ветки.

В GitHub Desktop переключитесь на ветку, в которую вы хотите объединить ветку development. В селекторе веток выберите ветку master.

Переходим Branch > Merge into Current Branch

В окне слияния выбираем ветку development и кликаем Merge development into master

После слияния веток изменения будут отображаться и в файле в ветке master.

После этого наши изменения будут отображены в репозитории на GitHub.

Слияние ветки через pull request

На сайте GiHub pull request выглядит так:

Напишем причину запроса на извлечение и нажмем Create pull request.

На этом этапе разработчики получат запрос по электронной почте с просьбой объединить их изменения. Попробуем себя в роли разработчика, перейдя на вкладку Pull requests (на GitHub), чтобы проверить и подтвердить запрос. Пока запрос на слияние не вызывает конфликтов, видна кнопка Merge pull request.

После нажатия кнопка Fetch origin изменится на Pull Origin.

Более подробное руководство по созданию запросов извлечения с использованием интерфейса GitHub см. В разделе Процесс Pull request на GitHub. Работать с Pull Request нужно уметь, если планируется участие в опен-сорс проектах.

Управление конфликтами слияния

Если решим зафиксировать свои изменения, то увидим сообщение, которое гласит:

Источник

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):

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

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

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

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

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

Читайте также: jaguar smart key что это

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

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

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

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

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

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

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

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

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

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

Нажатие 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 clone. Например:

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

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

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

то вы обнаружите в ней множество исполняемых файлов, которые эмулируют команды. Как уже было сказано, справкой 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

Источник