Как загрузить последнюю версию репозитория?

Fork репозитория

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

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

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

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .

Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.

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

Добавляем файлы в проект

Вот, чем мы займемся:

git statusgit addgit commit -m “ “git push

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

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

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать . После внесения изменений создается снимок состояния репозитория, для чего используется команда. А через добавляется сообщение об этом снимке.

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

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

git push

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

Актуальность версии можно проверить в любое время через команду .

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

• Как писать Bash-однострочники для клонирования и управления GitHub/GitLab репозиториями
• Top 100 наиболее популярных репозиториев на GitHub
• Основы Git за 5 минут

Ветвление

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

Это ведёт нас ключевой особенности Git — ветвлению, возможности работать над разными версиями проекта. Это значит, что вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках (что делает её похожей на дерево). Каждая ветвь в Git содержит легковесный указатель HEAD на последний коммит в этой ветке, что позволяет без лишних затрат создать много веток. Совет: называйте ветку в соответствии с разрабатываемой в ней функциональностью. Ветка по умолчанию называется master.

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

Стандартные команды:

•  — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
•  — переключается на эту ветку. Можно передать опцию , чтобы создать новую ветку перед переключением;
•  — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

•  — привязывает текущую ветку к указанной удалённой ветке;
•  — аналог предыдущей команды;
•  — создаёт новую локальную ветку и начинает отслеживать удалённую;
•  — показывает локальные и отслеживаемые удалённые ветки;
•  — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем,  связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как  перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды . Чтобы вернуть изменения, используйте .

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

9 ответов

Лучший ответ

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

8

C1sc0
31 Авг 2019 в 10:17

Вы также можете просто клонировать репо, после того, как клонирование будет выполнено, просто выберите папку или подлость, которую вы хотите. Чтобы клонировать:

Затем перейдите в клонированный каталог DIR и найдите файл или каталог, который вы хотите скопировать.

-5

Stephen Rauch
2 Окт 2017 в 04:52

Вы можете загрузить всю папку в разделе «Клонирование» или «Параметры загрузки» (URL-адрес Git или «Загрузить Zip»).

1. Есть кнопка Download Zip

2. Используя команду, вы можете загрузить всю папку на свой компьютер, но для этого вам понадобится git на вашем компьютере. Вы можете найти URL-адрес Git uner

   git clone https://github.com/url

-2

Community
20 Июн 2020 в 09:12

Зависимость: и .

Например:

1

Kalpesh Kundanani
30 Авг 2019 в 05:17

Вы должны загрузить весь проект либо с помощью кнопки «Клонировать на рабочий стол», которая будет использовать собственную программу github, либо с помощью кнопки «Загрузить как zip».

А затем найдите эту папку в загруженном проекте.

Paran0a
11 Окт 2015 в 15:17

Как загрузить определенную папку из репозитория GitHub

Вот правильное решение в соответствии с этим :

• Создать каталог

• Настроить репозиторий git

• Настройте свой git-repo для загрузки только определенных каталогов

• Установите папку, которую вы хотите загрузить, например вы хотите загрузить только каталог документов из

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

• Загрузите репо как обычно

2

abu_bua
24 Июн 2020 в 14:41

Воспользуйтесь онлайн-инструментом GitZip. Он позволяет загружать подкаталог репозитория github в виде zip-файла. Команды git не нужны!

12

gdrt
11 Авг 2019 в 09:09

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

Командная строка:

Например, если вы хотите загрузить examples / with-apollo / папку из zeit / next.js, вы можете ввести следующее:

17

chuyik
7 Авг 2017 в 02:36

Вы можете загрузить файл / папку с github

Просто используйте

Например

(да, это svn. по-видимому, в 2016 году вам все еще понадобится svn, чтобы просто загрузить некоторые файлы github)

35

Anona112
5 Дек 2016 в 23:22

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

Создать репозиторий можно двумя способами:

• на сайте;
• через GitHub Desktop.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

Далее у нас есть возможность инициализировать репозиторий с файлом README. В нем может быть отображена информация о репозитории, о его использовании, установке файлов и т.д. Описание происходит в формате Markdown. Также за этой галочкой скрывается команда init, которая превращает пустую папку в Git-проект.

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

• GNU GPL;
• MIT;
• Unlicense;
• WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Далее нажимаем на зеленую кнопку Create repository. Вы увидите список файлов в своем репозитории (пока это только автоматически сгенерированный файл README с описанием проекта) и содержание README, если он есть, а также файлы .gitignore и LICENSE, если они создавались. Ссылка на репозиторий будет выглядеть так: https://github.com/username/your_repo_name.git .

Клонирование существующего репозитория

Второй вариант создания директории для контроля версий – копирование существующего проекта с другого сервера. Это актуально, когда осуществляется доработка готового проекта или вы желаете внедрить его компоненты в свой. В этом поможет команда git clone, о которой и пойдет речь далее. 

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

Для клонирования существующего репозитория понадобится ввести git clone <url>. Пример такой команды вы видите ниже:

git clone https://github.com/rep/rep

Данная команда позволила вам получить клон всех версий указанного репозитория (в качестве примера было взято название rep). Теперь на вашем сервере создана директория с указанным названием. К ней подключена поддержка контроля версий, то есть появилась папка .git. 

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

git clone https://github.com/rep/rep myrep

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

Cloning into 'Git'...

remote: Counting objects: 46, done.

remote: Compressing objects: 100% (25/25), done.

remote: Total 46 (delta 7), reused 43 (delta 4), pack-reused 0

Unpacking objects: 100% (46/46), done.

Checking connectivity... done.

Удаление локального Git-репозитория

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

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

rm -rf .git

Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:

rm -rf .git*

Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah, выполнить которую необходимо с указанием того же каталога. 

Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи! 

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

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

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

Перед тем как git начнет отслеживать изменения, нужно подготовить все необходимые конфигурационные файлы. Сначала инициализируем пустой репозиторий в нашей папке:

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

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

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Подмодули

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

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

Обновление подмодулей

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

Для получения состояния последнего коммита всех подмодулей необходимо выполнить
следующую команду:

или использовать аргументы по умолчанию команды git pull:

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status
каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо
зафиксировать изменения:

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

Добавление подмодулей

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

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано
какие подмодули следует клонировать при запуске команды git submodule update

Специализированные приложения

Вот примерный список приложений (на 2021 год), разработанных для работы с локальными и/или удаленными git-репозиториями.

Приложение	Достоинства	Недостатки	Описание
С клонированием и отправкой изменений на сервер
	+все основные операции (clone, pull, commit, push)+авторизация по паролю/ключу ssh+список репозиториев+обзов файлов репозитория+управление ветками+просмотр diff, merge файлов+список коммитов	-кривой перевод на русский язык-не всегда стабильно работает-нет issues, PR	Продолжение проекта SGitOpen source (github)
Pocket Git (139р)	+все основные операции (clone, pull, commit, push)+авторизация по паролю/ключу ssh+список репозиториев+обзов файлов репозитория+управление ветками+просмотр diff, merge файлов+история коммитов в виде графика	-нельзя одной командой зафиксировать изменения сразу нескольких файлов (нужно отдельно каждый файл пометить как stage, а лишь потом делать коммит)-довольно долго загружает список файлов, коммитов и др.
	+все основные операции (clone, pull, commit, push)+авторизация по паролю/ключу ssh+обзов файлов репозитория+список коммитов+управление ветками+просмотр diff файлов	-ошибка при попытке push (не вылезло окно авторизации)	Продолжение проекта SGitПроект заморожен (последнее обновление в 2019г)
			Продолжение проекта SGitOpen source (github)Проект закрыт
Agit			Open source (github)Проект закрыт в 2014
SGit			Open source (github)Проект закрыт в 2016
Без клонирования и отправки изменений
	+список репозиториев +обзов файлов репозитория +просмотр diff файлов +управление issues, PR	-работа только с удаленным репозиторием (без клонирования) -нет списка коммитов? -нет commit и push	Клиент для сервиса GitHub
GitNex Pro for Gitea (339р)	+авторизация по паролю/ключу ssh +несколько аккаунтов +список репозиториев +обзов файлов репозитория +просмотр diff файлов +управление issues, PR +создание репозитория +список коммитов +есть режим offline +поддержка markdown	-работа только с удаленным репозиторием (без клонирования) -нет commit и push	Клиент для сервиса Gitea Проект развивается Open source (исходники)
	+обзов файлов репозитория +список репозиториев +список коммитов +issues, PR	-работа только с удаленным репозиторием (без клонирования) -нет commit и push	Клиент для сервиса Bitbucket Проект заморожен (последнее обновление в 2019г)
Bitbeaker (исходники)		-ошибка при попытке войти: “Ошибка получения данных с bitbucket.org. Проверьте соединение с интернетом”	Клиент для сервиса Bitbucket Проект заморожен (последнее обновление в 2017г)
	+просмотр коммитов +обзов файлов репозитория +управление issues, PR и другое		Клиент для сервиса GitLab Open source (gitlab)
	+просмотр коммитов +обзов файлов репозитория +несколько аккаунтов +управление issues, PR +поддержка markdown и другое		Клиент для сервиса GitLab Open source (gitlab)
Другие: OpenHub, ForkHub, OctoDroid, GitPoint			Клиенты для сервиса GitHub

Для своих локальных репозиториев лично какое-то время использовал 2 продукта из первой категории: MGit и PocketGit. Но по мере увеличения объема репозитория пользоваться приложениями становится неудобно.

И тут на помощь пришел Termux.

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

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

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

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

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

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

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

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

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

Регистрация на GitHub

На главной странице заполняем форму справа и нажимаем “Sign up for GitHub”

Проходим проверку и нажимаем “Join a free plan”

На следующей странице можно заполнить небольшую анкету (можно не заполнять)

На этой же странице спускаемся в самый низ и нажимаем “Complete setup”

Проверяем свою почту. Если письмо пришло, переходим к следующему пункту.

Аккаунт GitHub успешно создан

Установка GitHub Desktop

Нажимаем “Download for Windows (64bit)” (операционная система может отличаться)

Запускаем скачанный файл. После установки в появившемся окне нажимаем “Sign in to GitHub.com”

В открывшемся окне браузера вводим в форму свои данные, как при регистрации, и нажимаем “Sign in”

Если браузер запросит, то подтвердить, что нужно “Открыть приложение GitHub Desktop”

Далее регистрационные данные перенесутся в форму конфигурации (настроек) Git — нажимаем “Continue”

Отключаем пункт “Yes, submit periodic usage stats”, если не хотите периодически передавать статистику работы GitHub Desktop и нажимаем “Finish”

Далее видим начальное окно GitHub Desktop

“Create a tutorial repository…“ — создать обучающий репозиторий

“Clone repository from the Internet…“ — клонировать (скопировать/скачать) репозиторий из GitHub к себе на компьютер

“Create a New Repository on your hard drive…“ — создать новый репозиторий на вашем жестком диске (на вашем компьютере) и добавить систему Git в проект

“Add an Existing Repository from your hard drive…“ — добавить на GitHub репозиторий, который уже есть на вашем компьютере и использует Git

Справа будут отображаться ваши репозитории, которые уже загружены на GitHub, но если только что зарегистрировались, то список будет пуст.

Итоги

Возможно, на первый взгляд, покажется сложным, но после небольшой практики, вся базовая работа с GitHub Desktop на начальном этапе сойдется к тому, что вы поработали с проектом на работе > сделали коммит (“Commit to main”) > отправили на GitHub (“Push origin”). Пришли домой > получили изменения из GitHub (“Pull origin”) и продолжаете работу дома.

1. “Commit to main”
2. “Push origin”
3. “Pull origin”

Возможно, через некоторое время напишу статью про другие возможности GitHub Desktop

Больше информации на официальном сайте GitHub Desktop

Друзья, стараюсь для вас, поддержите проект!

Подписывайтесь, впереди много всего интересного и полезного 😉

Telegram — https://t.me/frontips