Git — версионирование кода

Инструмент, без которого "программист" на практике неполон — и, что приятно, целиком работающий из терминала, снова возвращая практику блока 2 в дело.

Проблема, которую решает Git

Знакомая многим ситуация без системы контроля версий: script.py, script_v2.py, script_final.py, script_final_ДЕЙСТВИТЕЛЬНО_финал.py — попытка вручную сохранять историю изменений копированием файлов быстро превращается в хаос без понятной хронологии, кто что менял и почему. Git решает это системно: хранит всю историю изменений одного файла (или целого проекта) в структурированном виде, позволяя в любой момент вернуться к любой прошлой версии, посмотреть, что именно изменилось между двумя моментами времени, и безопасно экспериментировать, не рискуя потерять рабочую версию.

Репозиторий, коммит — базовые понятия

Репозиторий — папка проекта, за изменениями в которой следит Git. Коммит (commit) — зафиксированный "снимок" состояния файлов проекта на определённый момент, с обязательным сопроводительным сообщением, объясняющим, что было изменено и зачем.

Базовый рабочий цикл — команды из терминала

$ git init # превратить текущую папку в git-репозиторий
$ git status # какие файлы изменены, что ещё не зафиксировано
$ git add script.py # подготовить конкретный файл к коммиту
$ git add . # подготовить все изменённые файлы разом
$ git commit -m "Добавил обработку ошибок" # зафиксировать снимок с сообщением
$ git log # история всех коммитов

Все эти команды — обычные команды терминала (главы 09–12), Git не требует отдельного графического приложения, хотя такие тоже существуют как удобная надстройка поверх тех же самых команд.

.gitignore — что не нужно отслеживать

Не всё в папке проекта стоит включать в историю версий. Файл .gitignore перечисляет то, что Git должен игнорировать:

# .gitignore
myenv/ # виртуальное окружение из главы 20 — воссоздаётся заново из requirements.txt
__pycache__/ # скомпилированный байт-код .pyc из главы 05 — не исходный код, пересоздаётся автоматически
.DS_Store # служебный файл macOS, не имеющий отношения к самому проекту

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

Ветки — работа над изменениями без риска для рабочей версии

$ git branch new-feature # создать новую ветку
$ git switch new-feature # переключиться на неё
$ # ... вносишь изменения, коммитишь их в этой ветке ...
$ git switch main # вернуться на основную ветку
$ git merge new-feature # влить изменения ветки обратно в основную

Ветка — параллельная линия истории, позволяющая экспериментировать с изменениями, не затрагивая основную (обычно называемую main) версию проекта, пока эксперимент не окажется удачным и не будет осознанно "влит" обратно.

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

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

$ git clone https://github.com/user/repo.git # скачать существующий репозиторий
$ git push # отправить свои коммиты на сервер
$ git pull # получить новые коммиты с сервера

История коммитов — надёжнее, чем ручная отмена

Ещё один слой защиты, которого не было у rm/del

В главах 09 и 10 честно говорилось: команды rm и del удаляют файл безвозвратно, без корзины. Для кода под управлением Git ситуация другая — случайно удалённая или испорченная строка кода, если она была ранее закоммичена, восстановима из истории коммитов даже после серьёзных правок или удаления файла целиком. Это не оправдание неосторожности с настоящими файлами данных вне репозитория, но веский практический довод коммитить рабочий код чаще, а не только в конце дня "на всякий случай".

Почему это не опционально для серьёзной работы

Практически ни один реальный профессиональный проект (и подавляющее большинство открытых проектов, доступных для изучения и переиспользования) не существует без Git — это отраслевой стандарт, а не просто одна из многих альтернатив. Освоение основ Git на этом этапе — не факультативное дополнение, а завершение того, что делает написанный в блоках 3–4 код готовым к реальной, а не только учебной практике.

Что дальше

Следующая глава возвращает книгу к тому, с чего, возможно, начинался твой интерес к электронике вообще — но уже не с паяльником, а с Python, управляющим Arduino напрямую.

Глава25 — Git

Блок5 — Что добавили от себя

Далее26 — Python и Arduino

СтатусГотово · рев. 1

Предыдущая глава ← 24 · Основы ООП Следующая глава 26 · Python и Arduino →

Книга бесплатна для чтения. Автор — Тариел Бежанидзе, компьютерный мастер в Батуми · tariel.ge · все бесплатные книги. Копировать текст целиком на другие сайты — только со ссылкой на источник.