На карте
GitHub Desktop показывает, что изменилось в файлах проекта, помогает сохранить понятную историю работы и отправить результат на GitHub. Он пригодится, если вы редактируете сайт, храните инструкции или работаете с кодом, который подготовил ИИ.
Разберём путь от подключения проекта до изменения, которое видно на GitHub. Понадобятся аккаунт GitHub, приложение Desktop и редактор обычного текста. Программировать для этого не обязательно.
Инструкция сверена с официальной документацией 3 октября 2026 года. Проход через интерфейс приложения при подготовке текста не выполнялся.
Что делают Git, GitHub и GitHub Desktop
Git хранит историю изменений проекта. GitHub размещает репозитории в интернете и даёт инструменты совместной работы. GitHub Desktop позволяет выполнять основные операции Git через окно приложения.
Репозиторий — папка проекта вместе с историей. В ней могут находиться исходники сайта, Markdown-документы, настройки или другие файлы. Для текстовых файлов особенно удобно сравнивать версии: видно, какая строка появилась и какая исчезла.
У сохранения работы есть несколько уровней:
| Действие | Что происходит |
| Сохранить файл в редакторе | Новое содержимое записывается в папку на компьютере |
Сделать коммит — Commit | Выбранные изменения попадают в локальную историю Git |
Отправить коммиты — Push | Локальная история передаётся в репозиторий на GitHub |
Если вы нажали Commit, файл ещё может отсутствовать на GitHub. Если нажали Push, это не обязательно обновило работающий сайт: выпуск зависит от настроек проекта. Как устроены коммиты и отправка изменений.
Установка и вход
Скачайте приложение с официальной страницы GitHub Desktop. На дату проверки поддерживаются macOS 12 и новее, Windows 10 64-bit и новее; официальной версии для Linux нет. Требования к системе.
Запустите Desktop и выберите вход в GitHub.com. Приложение откроет браузер для авторизации. Проверьте учётную запись, подтвердите доступ и вернитесь в Desktop. Авторизация в Desktop.
Проверьте имя и email для коммитов: в macOS это GitHub Desktop → Settings → Git, в Windows — File → Options → Git. Эти данные сохраняются в истории; в публичном репозитории email будет виден другим. Настройка автора коммитов.
Файлы вы будете менять в отдельном редакторе. Desktop нужен для просмотра изменений и работы с историей.
Как открыть свой проект
Проект уже есть на GitHub
Выберите File → Clone Repository, найдите репозиторий на вкладке GitHub.com, укажите локальную папку и нажмите Clone.
Клонирование скачивает файлы и историю на компьютер. Вы получаете рабочую копию, связанную с исходным репозиторием. Чтобы отправлять изменения обратно, нужны права записи. Клонирование репозитория.
Если скачиваете чужую программу ради использования, сначала прочитайте её раздел установки. Клонирование исходников само по себе программу не устанавливает.
Вы начинаете новый проект
Выберите File → New Repository. Укажите имя, например project-notes, и родительскую папку. Включите создание README: в нём удобно описать назначение проекта. Нажмите Create Repository.
Проект пока находится на компьютере. Для размещения на GitHub нажмите Publish repository, проверьте владельца и видимость. Оставьте Keep this code private, если репозиторий не предназначен для всех. Завершите публикацию и откройте View on GitHub.
В браузере должны появиться нужный репозиторий, выбранная видимость и файл README. Создание первого репозитория.
.env и выгрузки с личными данными.Как сохранить очередное изменение
В верхней части окна проверьте Current Repository: здесь должно быть имя нужного проекта. Затем посмотрите Current Branch, то есть текущую ветку.
Ветка хранит отдельную линию изменений. Она полезна, когда вы хотите подготовить правку, не включая её сразу в основную версию проекта.
Перед новой задачей убедитесь, что предыдущая работа сохранена и вкладка Changes пуста. Если там есть незавершённые правки, сначала разберитесь с ними. Затем выберите основную ветку, обычно main, и нажмите Fetch origin. Эта кнопка проверяет новые коммиты на GitHub; если появится Pull origin, получите их. Так новая работа начнётся с актуальной версии. Синхронизация ветки.
Создайте ветку через Current Branch → New Branch. Дайте ей имя по задаче, например update-project-description. Убедитесь, что она выбрана. Работа с ветками.
Теперь откройте README в текстовом редакторе. Допустим, в нём было:
# Сайт студии
Информация о студии и её проектах.
Вы уточнили назначение:
# Сайт студии
Портфолио студии, описание проектов и контакты для сотрудничества.
Сохраните файл и вернитесь в Desktop. На вкладке Changes появится изменённый README. Справа будет сравнение версий, или diff: удалённый текст и добавленный вместо него.
Прочитайте разницу. Если в списке есть посторонние файлы, выясните причину. Галочки определяют, какие изменения войдут в коммит; снятая галочка не удаляет правку из файла.
В поле Summary напишите, например: «Уточнено назначение сайта». Нажмите Commit to update-project-description. На вкладке History должна появиться запись с этим сообщением. Выбор файлов и создание коммита.
Старайтесь сохранять одной записью законченную небольшую правку. «Уточнено назначение сайта» через месяц объяснит историю лучше, чем «Изменения 7».
Как отправить работу на GitHub
У новой ветки нажмите Publish branch. Для следующих коммитов этой ветки используется Push origin. Здесь origin обозначает связанный удалённый репозиторий. Публикация ветки.
Откройте репозиторий в браузере и выберите именно update-project-description. Проверьте текст README и сообщение последнего коммита. В основной ветке прежний текст пока сохранится.
Если правка готова для основной версии, создайте запрос на её включение — Pull Request. В Desktop откройте Preview Pull Request, проверьте целевую ветку и список изменений, затем перейдите через Create Pull Request в браузер. Добавьте понятное описание и создайте запрос. Создание Pull Request.
Создание запроса ещё не объединяет ветки. Включение правки в основную ветку, или merge, выполняется после проверки по правилам проекта. В репозитории рабочего сайта это действие может запускать автоматический выпуск.
Полезные сценарии
Проверить работу ИИ перед отправкой. Агент изменил файлы сайта в локальной папке. Откройте этот репозиторий в Desktop, прочитайте список файлов и diff, затем проверьте сам сайт. Сохраните только понятные изменения. Результат — коммит с известным составом; корректность программы подтверждают её запуск и проверки.
Вести историю инструкций. У вас есть инструкции в Markdown, которые регулярно уточняются. Сохраняйте смысловые изменения отдельными коммитами. Когда понадобится выяснить, почему поменялся порядок работы, откройте History и нужную запись. Для документов Word или PDF построчное сравнение не будет таким же удобным.
Продолжить работу на другом компьютере. Отправьте коммиты с первого компьютера. На втором откройте тот же репозиторий и ветку, получите изменения через Fetch origin и Pull origin. Сверьте последнюю запись в истории. Несохранённые в коммитах или неотправленные изменения таким способом не переедут. Синхронизация локальной и удалённой ветки.
Что проверить, если результат отличается
| Ситуация | С чего начать |
Изменённого файла нет в Changes | Сохраните файл в редакторе; проверьте его папку и выбранный репозиторий |
| Коммит есть, а на GitHub старая версия | Проверьте отправку и выбранную в браузере ветку |
| Desktop не разрешает отправить изменения | Прочитайте ошибку: возможны нехватка прав, правила ветки или новые коммиты на сервере |
| При получении изменений возник конфликт | Сравните конфликтующие фрагменты и решите, какое содержимое должно остаться; не выбирайте версию наугад |
| После работы ИИ изменилось слишком много файлов | Остановите отправку и разберите состав правки; размер списка сам по себе ничего не говорит о качестве |
Если ошибка уже попала в отправленный коммит, можно сделать отменяющий коммит — Revert. Он сохраняет историю и добавляет обратное изменение. Это отличается от удаления незакоммиченных правок через Discard Changes. Перед отменой проверьте, какие файлы она затронет. Варианты работы с коммитами.
Следующий шаг
Для знакомства с репозиториями и совместной работой прочитайте руководство по GitHub для новичков.
Если проект уже меняет ИИ, начните с привычки проверять состав каждой правки перед отправкой. Desktop помогает сделать эту проверку видимой.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
