На тестовом сайте форму исправили, а после следующего обновления ошибка вернулась. Где потерялась правка: в рабочей папке разработчика, при объединении кода или при установке на сервер? Без истории приходится искать ответ по переписке. С Git можно сравнить сохранённые состояния и выяснить, какие изменения вошли в конкретную версию.
Мы в Гуси-Лебеди предлагаем смотреть на контроль версий через эту практическую задачу. Разберём Git простыми словами, покажем путь изменения от файла до коммита и объясним, что заказчику стоит получить вместе с исходниками. Примеры ниже учебные, а не описание проекта клиента.
Что такое Git и что хранится в репозитории
Git, произносится «гит», является распределённой системой контроля версий. Она хранит историю сохранённых состояний файлов: можно узнать, что изменилось, сравнить версии и продолжить работу от выбранного состояния. Большую часть операций с локальной историей можно выполнять без подключения к серверу. В официальной книге Pro Git этот принцип объясняется через снимки проекта.
Для сайта в Git обычно помещают исходный код, конфигурационные шаблоны и документацию. Но состав задаёт команда. Живая база данных, загруженные пользователями фотографии и реальные пароли не появляются в истории автоматически. Поэтому фраза «всё лежит в Git» требует уточнения: что именно там находится и как восстановить остальную часть проекта?
Репозиторий содержит историю и служебные данные Git. Рабочая папка содержит файлы, с которыми вы сейчас работаете. Коммит фиксирует подготовленный снимок и связывает его с описанием изменения. У него есть идентификатор, по которому можно обратиться к конкретному сохранённому состоянию. Идентификатор помогает различать версии, но сам по себе не подтверждает, что код проверен и работает.
Представьте, что разработчик меняет форму обратной связи. История позволяет сравнить код до правки и после неё, увидеть затронутые файлы и прочитать описание. Это гораздо предметнее сообщения «сделал форму». Однако ответ на вопрос «пришло ли обращение в CRM?» всё равно нужно получить проверкой отправки. История кода и результат работы сайта решают разные задачи.
Как изменение попадает в коммит: рабочая папка, индекс и история
Нажатие «Сохранить» в редакторе меняет файл на диске. Git ещё не записал это состояние в историю. Между редактированием и коммитом есть индекс, или staging area: область подготовки, в которой вы выбираете содержимое следующего снимка.
Такой промежуточный шаг полезен, когда в рабочей папке одновременно идут разные задачи. Например, исправление формы готово, а переделка меню ещё нет. В следующий коммит можно включить исправление, оставив незавершённую работу отдельно. Не обязательно сохранять все изменённые файлы одним коммитом.
Рассмотрим простой случай. Git уже установлен, в учебном репозитории есть отслеживаемый файл README.md, а имя и почта автора настроены. Вы изменили описание проекта. Следующие команды выполняются из папки этого репозитория:
git status
git diff
git add README.md
git diff --cached
git commit -m "Уточнено описание проекта"
git log -1 --onelinegit status показывает состояние рабочей папки и индекса. git diff позволяет посмотреть ещё не подготовленные изменения отслеживаемого файла. После git add README.md текущая версия этого файла попадает в индекс. git diff --cached показывает подготовленное отличие от последнего коммита. Затем git commit фиксирует подготовленный снимок, а git log -1 --oneline выводит краткую запись о последнем коммите.
Важная деталь: индекс не обновляется сам после редактирования. Если после git add снова изменить README.md, коммит запишет ранее подготовленную версию. Более поздняя правка останется в рабочей папке. Чтобы включить её, нужно повторно подготовить нужное содержимое. Именно поэтому перед коммитом полезно посмотреть и статус, и подготовленное отличие. Это поведение разобрано в главе Pro Git о записи изменений.
Для нового проекта сначала создают репозиторий, для существующего обычно получают его копию через git clone. Установка и первоначальная настройка зависят от среды; актуальные варианты есть на официальной странице установки Git. Изучать основной цикл удобно на отдельном учебном файле, чтобы разобраться в состоянии индекса до работы с кодом сайта.
Описание коммита тоже часть понятной истории. «Правки» не объясняет намерение. «Исправлен текст ошибки при пустом телефоне» помогает связать код с задачей. Небольшое логически цельное изменение проще обсуждать, чем смесь формы, меню и случайного форматирования в одном сохранении.
Зачем нужны ветки и почему слияние требует проверки
Ветка позволяет продолжать отдельную линию работы в репозитории. Например, основная ветка содержит принятый код, а в другой готовится новая форма. Сохранённые коммиты новой ветки не становятся частью основной только потому, что разработчик закончил редактирование. Их нужно включить в неё по принятому в проекте порядку.
Пусть один разработчик добавляет новое поле, а другой в это время меняет проверку телефона. Каждый работает над своей задачей. При объединении, или merge, Git пытается совместить изменения. Если обе ветки по-разному изменили одну и ту же часть файла, может возникнуть конфликт. Он означает, что автоматически выбрать итоговое содержимое не удалось. Это не основание бездумно принять «нашу» или «их» версию: нужно понять, как форма должна работать после обеих правок.
Бывает и другой случай: слияние прошло без конфликта, но поведение стало неправильным. Изменения могли затронуть разные строки и при этом зависеть друг от друга. Поэтому отсутствие сообщения о конфликте не является успешным тестом. Для нашего примера следует проверить обязательность нового поля, допустимый формат телефона, отображение ошибки и отправку обращения. Механика слияния и конфликтов описана в официальном руководстве Git.
В командном процессе перед включением правки удобно показывать её через pull request или merge request в выбранном сервисе. Там можно обсудить код, приложить условия проверки и отметить ограничения. Это инструменты площадки для совместной работы, а не обязательные команды самого Git.
Не существует одного подходящего всем названия веток или порядка выпусков. Для небольшого сайта и сервиса с несколькими поддерживаемыми версиями могут понадобиться разные договорённости. Важнее понимать, откуда начинается задача, кто принимает результат и какое состояние попадёт на сервер. Название main само по себе готовность к выпуску не доказывает.
Git, GitHub и удалённый репозиторий: где работает команда
Git управляет версиями. GitHub является платформой для хранения репозиториев и совместной работы; это различие объясняет документация GitHub. Для размещения можно выбрать и другой подходящий сервис либо собственную инфраструктуру. Сам выбор хостинга не заменяет правила доступа, ревью и выпуска.
Локальный коммит ещё не означает, что коллеги получили изменение. Для обмена с удалённым репозиторием используются отдельные операции. Их полезно различать даже заказчику, который не вводит команды самостоятельно:
| Операция | Что происходит | Чего это не подтверждает |
|---|---|---|
clone | Создаётся локальная копия репозитория | Что в ней есть база данных и все материалы работающего сайта |
fetch | Получаются данные из удалённого репозитория | Что изменения уже включены в текущую рабочую ветку |
pull | Получаются данные и выполняется их интеграция с учётом выбранного режима | Что объединённый код прошёл проверку |
push | Передаются изменения в удалённый репозиторий | Что эта версия уже установлена на сайт |
Порядок обмена подробно рассмотрен в главе Pro Git об удалённых репозиториях. Отправка кода может запускать автоматическую сборку или установку, если такой процесс отдельно настроен. Без этой настройки push не становится командой публикации сайта.
Для бизнеса важен контроль над доступом: кто владеет репозиторием, кто принимает изменения и сможет ли другая команда продолжить работу. При разработке серверной части проекта также стоит документировать зависимости и требования к окружению. Копия исходников без этих сведений может оказаться недостаточной для запуска.
Что заказчику получить вместе с историей проекта
Просить «выдать Git» слишком неопределённо. Мы советуем согласовать конкретный комплект передачи. Он нужен, чтобы следующий специалист смог разобраться в проекте, собрать его и сопоставить исходники с установленной версией.
- Адрес репозитория и доступ с согласованными правами, а не чужой личный пароль.
- Идентификатор коммита или метку версии, которая установлена на сайте.
- Инструкцию запуска с версиями зависимостей и порядком настройки окружения.
- Перечень материалов, которые хранятся отдельно: база данных, пользовательские файлы, необходимые настройки.
- Порядок приёма изменений, выпуска и действий при неудачном обновлении.
Секреты, например токены сервисов, следует передавать и хранить отдельно от общей истории исходников. Если пароль уже оказался в коммите, удаления строки из текущего файла недостаточно: старое состояние может сохраняться в истории. В документации GitHub о чувствительных данных отдельно рассматриваются отзыв учётных данных и очистка истории. Такое исправление требует разбора конкретного случая.
Для приёмки доработки полезна короткая связка: задача, сохранённое изменение, проверенный результат, установленная версия. В учебном примере с формой это означает: согласовали новое поле, сохранили код, проверили отправку с нужными данными, установили именно проверенное состояние и снова прошли сценарий на публичном сайте. Результат теста на стенде не стоит записывать как результат проверки сайта после выпуска.
Возврат к старому коду тоже не восстанавливает весь проект автоматически. За это время могли измениться данные в базе, пользовательские файлы или состояние внешнего сервиса. План восстановления должен учитывать то, что затрагивает обновление. Git помогает найти нужные исходники, а порядок резервного копирования и восстановления согласуется отдельно.
В сопровождении и доработке сайта история становится полезной, когда по ней можно восстановить ход работы: что хотели изменить, что сохранили, что проверили и что выпустили. Для нас в Гуси-Лебеди это предметный способ обсуждать результат с командой, а не просто ещё один технический термин в отчёте.