4. GitHub: командная работа и публикация

GitHub, Git и репозиторий: кто за что отвечает

Люди часто смешивают эти три вещи в одну. Из-за этого GitHub кажется чем-то страшным и запутанным. На деле роли очень простые: Git помнит историю, репозиторий хранит проект вместе с этой историей, а GitHub даёт этому проекту место в интернете.

Можно представить это как школьную работу. Вы пишете её в тетради у себя дома. Сама тетрадь — это репозиторий. Память обо всех исправлениях, черновиках и прошлых версиях — это Git. А шкафчик вне дома, где лежит копия тетради и откуда её можно показать другим, — это GitHub.

Из-за этой разницы проще понимать, что именно происходит во время работы. Когда вы что-то меняете в проекте, Git запоминает изменения. Когда проект лежит у вас на компьютере, вы работаете с локальным репозиторием. Когда такая же копия появляется на GitHub, это уже удалённый репозиторий.

Пример из жизни: вы пишете инструкцию, потом переделываете её три раза. Git хранит все версии. Репозиторий держит их вместе с файлами. GitHub позволяет открыть доступ к этой инструкции по ссылке и не пересылать её заново после каждой правки.

Зачем GitHub, если у вас уже есть папка на компьютере

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

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

• Вы что-то испортили и хотите вернуть вчерашнюю версию. В обычной папке люди начинают плодить файлы вроде «финал», «финал_точно», «финал_последний». В репозитории история уже хранится аккуратно: можно найти нужный момент и вернуться к нему без хаоса в названиях.

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

• Проект — это не только код. Там могут лежать инструкции, презентации, тексты, исследования, таблицы и картинки. GitHub удобен не только программистам: для вас это может быть просто аккуратное место, где живёт весь проект целиком, а не только один файл.

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

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

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

Публичный и приватный репозиторий

Когда вы создаёте репозиторий на GitHub, вам сразу нужно решить: показывать его всем или только выбранным людям. Это не экзамен на смелость и не правило «как правильно». Это просто настройка двери. Либо она открыта для всех, либо только для тех, кому вы дали ключ.

Самая частая ошибка новичка — думать, что public опасен, потому что любой сможет всё испортить. Но здесь есть две разные вещи. Первая — кто может смотреть. Вторая — кто может менять. Public открывает просмотр. Доступ на изменения вы выдаёте отдельно. Поэтому открытый репозиторий удобен для портфолио, шаблонов и инструкций. Его легко добавить в резюме, отправить клиенту или показать коллеге одной ссылкой. Public ещё полезен, когда вы хотите, чтобы проект нашли без вашего участия.

Private нужен там, где лежат черновики, внутренние заметки, платные материалы или данные клиентов. Здесь правило очень простое. Если вам было бы неприятно увидеть это на большом экране в кафе, держите репозиторий private. Так вы работаете спокойно, убираете лишнее и приглашаете только нужных людей. Это особенно удобно, когда проект ещё сырой и вы сами не уверены, что в нём уже можно показывать другим. Если вы делаете заказ для клиента, закрытый режим тоже удобен.

Решение не навсегда. Настройку можно поменять позже. Многие проекты сначала живут как private. Когда всё приведено в порядок, их открывают как public. Это обычный путь. Например, вы готовите исследование в закрытом виде, а потом открываете готовую документацию, демо-версию или полезный шаблон. Так безопасность и удобство не мешают друг другу.

Когда GitHub удобнее архива и облачного диска

Архив и облачный диск хорошо работают, когда у вас один файл и одна отправка. Но проект почти никогда так не живёт. Сегодня вы поправили текст, завтра добавили инструкцию, послезавтра заменили картинки. В итоге появляются папки вроде «финал», «финал_точно», «финал_последний», а у людей на руках остаются разные версии. GitHub удобен там, где проект должен жить в одном месте, а не разъезжаться по письмам, мессенджерам и случайным ссылкам.

• Вы собираете пакет материалов для клиентов или коллег. Это могут быть инструкции, шаблоны, презентации и примеры файлов. Вместо того чтобы каждый раз пересылать новый ZIP-архив, вы держите всё в одном repository и даёте одну ссылку. Люди открывают тот же адрес и видят свежую версию, а не старую папку из переписки двухнедельной давности.

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

• Вы хотите делиться не всем, а только нужной частью проекта. Один repository можно сделать public, чтобы показать работу всем, а другой — private, чтобы оставить доступ только своим. Это удобнее, чем вручную собирать отдельный архив без лишних файлов и каждый раз думать, не забыли ли вы убрать что-то внутреннее.

• Вы работаете над проектом у себя на компьютере, но хотите иметь надёжную копию вне него. Если ноутбук сломается или папка случайно повредится, GitHub остаётся внешней копией проекта. При этом это не просто склад файлов, а то же самое место, откуда вы потом можете открыть доступ другим людям, не пересобирая всё заново.

• Вы передаёте проект новому человеку. Дизайнеру, редактору, помощнику или заказчику не нужно присылать десять ссылок: «тексты тут, картинки тут, последняя версия вот тут». Вы даёте доступ к одному repository, и человек видит цельную картину. Это особенно спасает, когда проект состоит не из одного документа, а из многих связанных частей.

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

README и Markdown как карта проекта

Без README проект понятен только вам, и то пока вы ещё помните, что именно меняли вчера вечером. Через неделю вы уже забываете, где лежит главное, какой файл открывать первым и где спрятана последняя рабочая версия. Другой человек откроет репозиторий и увидит просто набор папок, документов и названий, которые что-то значат только для вас.

README в самой верхней папке работает как табличка у входа и короткий план здания, который видно сразу. В нём полезно написать, что это за проект, зачем он нужен, для кого сделан, что в нём главное и где лежат ключевые материалы. Туда же удобно добавить ссылку на готовую версию, правила обновления, контакты и одно простое «с чего начать».

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

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

Как GitHub помогает публиковать сайт или приложение

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

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

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

С приложением картина другая. Ему часто нужно сначала подготовить файлы для интернета, а потом обновляться после ваших изменений. Поэтому такие проекты обычно отправляют на Netlify или Vercel, которые подключаются к GitHub и делают это автоматически. Например, страницу с правилами клуба удобно держать на GitHub Pages, а онлайн-калькулятор расходов — на Netlify или Vercel.

Когда нужен образ Docker вместо набора файлов

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

1. Вы отдаёте приложение заказчику для просмотра

   Заказчику нужен не набор папок, а понятный способ открыть проект на своём компьютере и увидеть тот же результат, что видите вы. Образ Docker здесь удобнее файлов, потому что он ближе к формату «взял и запустил».

2. Вы публикуете полезный инструмент для других людей

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

3. Вы передаёте проект другому человеку, который будет с ним работать дальше

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

4. Вы возвращаетесь к своему проекту через полгода или меняете компьютер

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

5. У вас на одном ноутбуке всё работает, а на другом — нет

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

Что подготовить перед первой синхронизацией

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

Логика тут очень бытовая. Перед отправкой проекта в GitHub вы как будто готовите посылку: складываете всё в одну коробку, пишете адрес и решаете, кто сможет её открыть. Когда это готово заранее, ИИ не тратит время на догадки и может спокойно сделать остальное.

1. Подготовьте одну рабочую папку проекта на компьютере В ней должно лежать всё, что относится к работе: тексты, изображения, таблицы, код. Лучше, чтобы это была одна папка, открытая в VS Code, а не файлы в разных местах. Если проект разбросан по рабочему столу, в GitHub уедет только то, что лежит в выбранной папке.

2. Проверьте, что Git уже установлен Это программа, которая замечает изменения в файлах и помогает отправить их в GitHub. Если Git на компьютере нет, синхронизация просто не стартует. На практике это выглядит так: ИИ или редактор сообщает, что Git не найден, и дальше работа останавливается.

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

4. Заранее выберите тип доступа: public или private Public подходит, если вы хотите просто дать ссылку любому человеку. Private нужен, если внутри есть черновики, внутренние документы или материалы только для команды. Это решение лучше принять до первой отправки, чтобы потом не переделывать доступ на ходу.

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

Регистрация в GitHub и создание первого репозитория

Под рукой держите рабочую почту. Ещё заранее придумайте имя пользователя латиницей. Если аккаунт в GitHub у вас уже есть, пропустите шаги 1–3 и сразу создавайте репозиторий.

1. Откройте регистрацию GitHub

   • Откройте страницу github.com/signup. В центре экрана будет форма на белом фоне.
   • В поле Email или Email address введите свою почту и нажмите зелёную кнопку Continue.
   • Страница не закроется. Вместо первого поля появится следующий экран регистрации.

2. Придумайте пароль и имя пользователя

   • В поле Password введите пароль и нажмите Continue. Если пароль слабый, GitHub покажет подсказку прямо под полем.
   • На следующем экране появится поле Username. Введите имя пользователя латиницей.
   • Если имя свободно, под полем появится зелёная отметка. После этого снова нажмите Continue.

3. Подтвердите почту и войдите в аккаунт

   • GitHub пришлёт код на вашу почту. Скопируйте код из письма и вставьте его в поле подтверждения на странице регистрации.
   • После проверки вы попадёте на стартовый экран GitHub. Иногда сайт задаёт ещё пару простых вопросов. Обычно там есть кнопка Continue или вариант пропустить настройку.

4. Откройте страницу создания репозитория

   • На верхней тёмной панели справа нажмите значок +. Это маленький плюс рядом с аватаркой.
   • В выпадающем меню выберите пункт New repository. Откроется страница с формой создания репозитория.
   • Если хотите попасть туда напрямую, можно открыть github.com/new. Но через кнопку + вы быстрее запомните, где это лежит.

5. Заполните форму нового репозитория

   • В поле Repository name введите короткое имя проекта. Например: my-notes или site-vizitka.
   • Поле Description можно заполнить, а можно оставить пустым. Это просто короткая подпись под названием.
   • Ниже выберите видимость: Public или Private. Ещё ниже не ставьте галочки Add a README file, Add .gitignore и Choose a license. Для первой синхронизации удобнее пустой репозиторий.

6. Создайте репозиторий

   • Внизу страницы нажмите зелёную кнопку Create repository.
   • Откроется страница нового репозитория. Вверху будет его имя, а в центре — блок Quick setup с подсказками для подключения проекта.

Проверка простая: в адресе страницы будет что-то вроде github.com/ваше-имя/имя-репозитория. Если внутри ещё нет файлов и виден блок Quick setup, всё получилось. Репозиторий готов к первой синхронизации с вашей папкой проекта.

Как дать ИИ доступ к GitHub через token

Перед началом проверьте три вещи: у вас уже есть аккаунт на GitHub, вы вошли в него в браузере, и у вас открыт инструмент, через который ИИ работает с проектом, например VS Code. Здесь идея простая: вы не даёте ИИ пароль от аккаунта, а выдаёте отдельный цифровой пропуск с нужными правами.

1. Откройте github.com. В правом верхнем углу нажмите на круглый значок профиля, в выпадающем меню выберите Settings с иконкой шестерёнки — откроется страница настроек с длинным меню слева.

2. В самом низу левого меню нажмите Developer settings. На новой странице слева появится ещё одно меню; в нём откройте Personal access tokens, затем пункт Tokens (classic). Справа загрузится страница со списком токенов и кнопкой Generate new token.

3. Нажмите кнопку Generate new token в правой части страницы и выберите Generate new token (classic). GitHub может попросить ещё раз ввести пароль. На форме в поле Note напишите понятное имя, например VS Code AI access, а в поле Expiration выберите срок, например 30 days, чтобы доступ не висел бесконечно.

4. Прокрутите страницу до блока Select scopes. Если ИИ должен работать и с закрытыми репозиториями, поставьте галочку repo; если только с открытыми, достаточно public_repo. Затем внизу страницы нажмите зелёную кнопку Generate token — откроется страница с длинной строкой из букв и цифр на светлом фоне.

5. Сразу скопируйте эту строку кнопкой копирования справа от token или обычным выделением. Потом откройте VS Code: в левой вертикальной панели нажмите Extensions — это значок из четырёх квадратиков, найдите своё ИИ-расширение, нажмите маленькую шестерёнку рядом с его названием и выберите Extension Settings. В открывшейся странице найдите поле GitHub Token, Personal Access Token или Access Token, вставьте token и сохраните — обычно после этого появляется надпись Connected, Authorized или зелёная галочка.

Если GitHub перестал показывать token после закрытия страницы, это нормально: его показывают только один раз. Если забыли сохранить или случайно отправили не туда, вернитесь в список токенов в GitHub, удалите старый и создайте новый; в чатах, README и обычных .txt файлах такие ключи хранить не стоит.

Первая синхронизация: commit и push

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

Первая синхронизация — это не одна магическая кнопка, а короткая цепочка действий. Сначала вы включаете историю изменений для папки проекта. Потом связываете эту папку с нужным репозиторием на GitHub. После этого ИИ фиксирует текущее состояние проекта и отправляет его в интернет. Обычно вы просто пишете такую задачу ИИ в VS Code, а не вспоминаете команды по памяти.

1. Сначала вы просите ИИ проверить, есть ли у папки проекта история изменений Git. Если её ещё нет, ИИ инициализирует Git и подготавливает папку к синхронизации.

2. Потом вы просите ИИ связать локальный проект с вашим репозиторием на GitHub. Для этого нужен точный адрес репозитория, иначе ИИ не поймёт, куда отправлять файлы.

3. Дальше ИИ делает первый commit. У этого сохранения должна быть короткая понятная подпись, например: «первая версия проекта» или «добавлены основные файлы». Потом вам будет легче читать историю и понимать, что менялось.

4. После этого ИИ делает push. На странице репозитория в GitHub появляются файлы, папки и первая запись в истории изменений. Если файлов в GitHub нет, значит цепочка оборвалась раньше, и нужно проверить связь с репозиторием или доступ к GitHub.

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

Зачем нужен .gitignore и как он работает

Пока проект живёт только на вашем компьютере, лишние файлы и секреты в папке — это ваша внутренняя история. Как только проект связан с GitHub, каждый push уносит эти файлы в интернет. Один невнимательный момент — и в репозитории оказывается пароль от сервиса, черновик, который не хотелось показывать, или куча служебных файлов редактора. Убрать их задним числом сложнее, чем не дать им попасть туда сразу.

Часто путают .gitignore и выбор между public и private. Это разные настройки. Public или private решает, кто вообще видит проект целиком. .gitignore решает, какие файлы в этот проект попадают. Поэтому он нужен и для публичных, и для приватных проектов. В публичном — чтобы не утекли секреты и личные заметки. В приватном — чтобы история не распухала от служебных файлов и репозиторий оставался чистым.

Как это выглядит на практике. В корне папки проекта лежит файл с именем .gitignore. Внутри — список шаблонов: имена файлов, расширения, папки. При каждом commit Git проверяет этот список. Всё, что в нём указано, остаётся у вас на компьютере, но не попадает ни в commit, ни в push. Сам .gitignore вы тоже коммитите: так правила одинаковы у всех, кто потом клонирует проект.

Локальный .gitignore в папке проекта

Локальный .gitignore лежит в корне репозитория и описывает правила именно этого проекта. Он работает для всех, кто скачивает проект с GitHub, потому что сам попадает в историю. Поэтому команда видит одинаковые правила: что считается мусором и не должно уходить в репозиторий, а что — часть проекта.

• .env, secrets.json и другие файлы с паролями. В репозиторий такие файлы попадать не должны. Неважно, public проект или private, секреты лучше держать только на своём компьютере. Если случайно ушло в public — считайте, что ключ скомпрометирован, и меняйте сам ключ.

• node_modules/, venv/, __pycache__/. Это папки со скачанными пакетами и временными файлами. Они пересоздаются автоматически при первом запуске и не нужны в истории. Без них репозиторий остаётся лёгким и быстро загружается.

• .DS_Store, Thumbs.db. Это служебные файлы, которые macOS и Windows создают сами. Команде они неинтересны, а в истории только шумят.

• build/, dist/, *.log. Собранные версии проекта и логи работы программ. Исходники в репозитории есть, а результат сборки и рабочие логи пересоздаются при каждом запуске.

• Черновики и личные заметки. Файлы вроде TODO_private.md, draft-*.md или папка scratch/ — то, чем вы не готовы делиться. В .gitignore можно написать шаблон, например scratch/, и вся эта папка останется только у вас.

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

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

Глобальный .gitignore для всех ваших проектов

Разделение здесь простое. Локальный .gitignore — это правила проекта, они одинаковы у всей команды и живут в репозитории. Глобальный .gitignore — это правила про вас и ваш компьютер, они лежат у вас дома и работают для всех ваших проектов сразу. Так ваши личные мелочи не захламляют чужие репозитории, а общие правила проекта остаются общими.

Самый частый вопрос новичка: «если я использую VS Code, добавить .vscode/ в локальный или в глобальный?». Ответ зависит от команды. Если у всех одинаковый редактор и они договорились держать общие настройки вместе, тогда в локальный. Если редакторы у всех разные и каждый настраивает под себя, тогда в глобальный — так чужие настройки никому не мешают. Если сомневаетесь, глобальный почти всегда безопаснее.

Подключить такой файл тоже просто. Обычно это два действия: вы создаёте файл ~/.gitignore_global со своими правилами и один раз говорите Git использовать его как глобальный. Это задача ровно на одну команду в терминале, и её можно спокойно поручить ИИ в VS Code. После этого правила действуют для всех ваших проектов без повторной настройки.

Что делать, если файл уже попал в репозиторий

Самая частая ловушка с .gitignore такая. Вы сделали первый commit и push, а потом сообразили, что забыли добавить .env в список. Добавляете правило, делаете новый commit, но файл всё равно виден в истории на GitHub. Это не ошибка. .gitignore говорит Git: «со следующего раза этот файл не трогай». Но если он уже успел занести файл в историю, одного правила мало: файл надо отдельно снять с учёта.

1. Сначала снимите файл с учёта Попросите ИИ в VS Code перестать отслеживать этот файл в Git, не удаляя его с диска. Это отдельное действие: оно говорит Git «забудь, что я за ним следил», но файл у вас в папке остаётся.

2. Проверьте, что правило уже есть в .gitignore Если правила ещё нет, при следующем commit Git снова возьмёт файл в историю. Сначала правило, потом снятие с учёта.

3. Сделайте новый commit и push В свежей версии проекта на GitHub этого файла уже не будет. Дальше работаете как обычно.

4. Если это был секрет — смените сам секрет Это самое важное. Файл исчез из свежей версии, но остаётся в прошлых commit. Любой, кто открывал репозиторий до исправления, мог его увидеть. Для обычного мусора это неважно. Для пароля или ключа действует правило безопасности: если секрет хотя бы раз был в открытом месте, считайте его скомпрометированным. Удалите этот ключ в сервисе, создайте новый и работайте с ним.

Есть ещё способ полностью вычистить файл из всей истории репозитория, чтобы и в прошлых commit его не было. Это тяжёлая операция: она переписывает историю и может сломать работу других людей в команде. На уровне первых шагов с GitHub достаточно знать, что такой способ существует, и при утечке секрета всё равно в первую очередь менять сам секрет, а не надеяться только на чистку истории.

Как дать ссылку на репозиторий и пригласить участников

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

1. Открываем нужный репозиторий

   • На GitHub нажмите в правом верхнем углу на круглую аватарку.
   • В выпадающем меню выберите Your repositories. Откроется список ваших проектов.
   • Нажмите на название нужного репозитория. На его странице сверху увидите имя проекта и маленькую плашку Public или Private.

2. Копируем обычную ссылку на проект

   • На главной странице репозитория найдите зелёную кнопку Code. Она стоит над списком файлов, ближе к правому краю.
   • Нажмите Code. Появится небольшое окно с адресом проекта.
   • Убедитесь, что выбран вариант HTTPS, и нажмите значок копирования справа от ссылки. Он похож на две маленькие карточки.
   • На секунду появится галочка. Это знак, что ссылка скопировалась и её можно вставить в письмо или сообщение.

3. Выбираем способ доступа

   • Посмотрите на плашку рядом с названием репозитория.
   • Если там Public, любой человек с этой ссылкой сможет открыть страницу и читать файлы.
   • Если там Private, одной ссылки мало. Без приглашения GitHub обычно покажет человеку страницу Page not found.
   • Для private-репозитория, и для public-репозитория с правом правок, нужен следующий шаг.

4. Приглашаем участника в репозиторий

   • На странице репозитория нажмите вкладку Settings в верхнем меню. Обычно она стоит справа. Если вкладки нет, у вас нет прав владельца.
   • В левой панели найдите блок Access и откройте пункт Collaborators. В некоторых аккаунтах он может называться Manage access.
   • На открывшейся странице нажмите кнопку Add people или Add collaborators. Она заметная, в правой части экрана.
   • В поле поиска введите имя человека на GitHub или его email, выберите нужный вариант из списка и нажмите кнопку Add … to this repository.
   • Если GitHub предложит выбрать права, поставьте Read для просмотра или Write для правок, а потом подтвердите приглашение.

5. Проверяем, что приглашение ушло

   • После отправки вы вернётесь на страницу доступа. Напротив имени человека появится статус Pending.
   • GitHub отправит приглашение через уведомления и на email.
   • Когда человек нажмёт Accept invitation, статус Pending исчезнет. После этого доступ уже работает.

Если всё настроено правильно, public-репозиторий открывается по ссылке сразу. У private-репозитория приглашённый человек виден в Settings → Collaborators уже без статуса Pending.

Как оформить README для корня и важных подпапок

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

Хорошая схема такая: README в корне работает как карта всего проекта, а README в важных подпапках — как табличка на двери конкретной комнаты. В корне вы объясняете, что это за проект, для кого он, как им пользоваться и где что лежит. В подпапке вы пишете только то, что относится к ней: что внутри, что можно менять, что трогать нельзя, в каком порядке смотреть файлы. Тогда новый человек не бродит вслепую, а идёт по понятным указателям.

1. Сделайте корневой README главным входом в проект

   В начале напишите простыми словами, что это за проект и зачем он нужен. Ниже дайте короткую карту структуры: какие папки есть и что в них лежит. Ещё ниже добавьте правила старта: что читать первым, какие файлы самые важные, куда смотреть за примерами.

2. Добавляйте README не в каждую папку, а только в важные

   Если папка маленькая и в ней два понятных файла, отдельное описание не нужно. Но если папка содержит документы, шаблоны, изображения, код, исследования или рабочие материалы, README сильно экономит время. Он отвечает на вопрос: «Что это за место и как с ним обращаться?».

3. Пишите README как инструкцию для уставшего человека

   Не надейтесь, что названия файлов всё объяснят сами. Используйте короткие блоки: «что здесь», «с чего начать», «что обновлять», «чего не делать». Хороший признак — человек без ваших подсказок понял, куда нажать глазами и какой файл открыть первым.

4. Держите README живым, а не декоративным

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

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

Pull request, branch и fork: безопасный путь для изменений

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

Если человек уже в вашей команде и может писать в repository, он чаще делает branch. Это отдельная дорожка внутри того же проекта. На ней можно менять файлы, делать commit и push, не трогая рабочую версию. Это похоже на черновик рядом с чистовиком: черновик живёт отдельно, пока вы не одобрите перенос. Такой путь удобен для сотрудников и постоянных участников. Если доступа на запись нет, человек делает fork. Это уже личная копия проекта в его аккаунте на GitHub, где он может работать без риска для вашего оригинала.

После этого человек открывает pull request. По смыслу это записка владельцу: «Я подготовил правки, посмотрите их отдельно». Вы видите, какие файлы он менял и что именно добавил или убрал. В одном месте собирается весь разговор об этой правке. Можно спокойно проверить каждое изменение, а не угадывать, что произошло вчера вечером. Если находите проблему, просите поправить её в той же branch или в том же fork. Рабочая версия всё это время остаётся как была.

Когда правки вам подходят, вы делаете merge. Это момент, когда одобренные изменения переходят в основной проект. Например, вам прислали исправление опечатки, новый абзац в инструкции или маленькое улучшение страницы. Человек из команды мог сделать это через branch, а внешний помощник — через fork. Вы проверили правку, сделали merge, и она стала частью общего проекта. Если не сделали merge, ничего не ломается, потому что предложение так и остаётся отдельно. Поэтому эта схема удобна даже для маленькой команды или редкой помощи со стороны.

Как открыть и принять pull request в интерфейсе

Если вы меняли проект в своей branch или fork, GitHub позволяет передать эти изменения владельцу аккуратно. Сначала участник открывает pull request, потом владелец смотрит разницу и решает: принять, попросить правки или закрыть заявку.

1. Участник открывает форму для pull request Откройте нужный репозиторий на GitHub. Если вы недавно отправили изменения, над списком файлов часто появляется жёлтая плашка с зелёной кнопкой Compare & pull request справа. Нажмите её. Если плашки нет, в верхней части репозитория нажмите вкладку Pull requests, потом зелёную кнопку New pull request в правом верхнем углу. Откроется страница сравнения двух веток.

2. Участник выбирает, откуда и куда отправлять изменения На странице сравнения найдите два выпадающих списка: слева base, справа compare. В base выберите ветку владельца, чаще всего main. В compare выберите свою ветку. Ниже GitHub покажет список изменённых файлов: удалённое будет красным, новое — зелёным. Если сверху видно сообщение Able to merge, нажмите зелёную кнопку Create pull request.

3. Участник оформляет заявку В верхнем поле введите короткий заголовок, например: «Добавил страницу с инструкцией». В большом поле Add a description напишите, что именно вы поменяли и на что владельцу смотреть. После этого нажмите зелёную кнопку Create pull request. Откроется страница заявки с номером, например #12, и статусом Open.

4. Владелец открывает заявку Откройте репозиторий на GitHub, нажмите вкладку Pull requests в верхней части страницы и выберите нужную заявку из списка. Откроется её страница с вкладками Conversation, Commits и Files changed. По названию и номеру легко понять, что вы смотрите именно тот pull request.

5. Владелец проверяет изменения Нажмите вкладку Files changed в верхней части заявки. GitHub покажет разницу построчно: красные строки с минусом убраны, зелёные с плюсом добавлены. Если хотите оставить замечание к конкретному месту, наведите курсор на строку и нажмите синюю иконку + слева. Если проверка закончена, нажмите кнопку Review changes справа сверху.

6. Владелец принимает решение по проверке После нажатия Review changes справа откроется маленькая панель с вариантами Comment, Approve и Request changes. Если всё хорошо, выберите Approve, при желании добавьте короткий комментарий и нажмите зелёную кнопку Submit review. Если нужны исправления, выберите Request changes и тоже нажмите Submit review. Заявка останется открытой, а участник увидит, что именно надо поправить.

7. Владелец принимает или закрывает pull request Если заявка одобрена и вы хотите добавить изменения в основную ветку, вернитесь на вкладку Conversation, прокрутите вниз и нажмите зелёную кнопку Merge pull request, затем кнопку Confirm merge. После этого на странице появится фиолетовая метка Merged. Если принимать изменения не нужно, нажмите серую кнопку Close pull request — заявка закроется, а код в основную ветку не попадёт.

Проверка простая: у принятого pull request видна метка Merged, а новые файлы уже есть в основной ветке. У отклонённого pull request будет статус Closed, и проект останется без этих изменений.