В чём разница между `git add`, `git commit` и `git push`, и что обязательно нужно исключить из репозитория через `.gitignore` при работе аналитика?

Короткий ответ

git add помечает изменённые файлы для включения в следующий коммит, git commit сохраняет эти изменения локально с сообщением, а git push отправляет локальные коммиты в удалённый репозиторий; из репозитория стоит исключать пароли/токены к базам данных, большие сырые датасеты и локальные конфиги через .gitignore.

Как это работает подробнее

• Как это работает: репозиторий Git состоит из трёх зон — рабочая директория (файлы на диске), staging area (то, что подготовлено к коммиту через add) и история коммитов (локальная до push); .gitignore — это файл с шаблонами путей, которые Git не будет отслеживать и предлагать добавить.

Пример кода

git_workflow.shКопировать

echo "db_password=***" > config.ini
echo "config.ini" >> .gitignore
echo "*.csv" >> .gitignore
git add analysis.py .gitignore
git commit -m "Добавил скрипт расчёта конверсии"
git push origin main

Что использовать на практике

• На практике: типичный .gitignore аналитика включает *.csv, *.xlsx (если это не маленькие справочники), .env, config.ini с кредами, __pycache__/, .ipynb_checkpoints/; реальные датасеты и секреты хранят отдельно (хранилище данных, секрет-менеджер), а в репозитории — только код и, возможно, небольшие тестовые данные.
• Пример и проверка. Проверка: git status после этого должен показывать config.ini и data.csv как untracked/ignored, а не как файлы, готовые к коммиту.

Подводные камни

• Частые ошибки: закоммитить файл с паролем к базе один раз — даже если потом его удалить, он останется в истории Git и его нужно будет специально вычищать; забыть git push и подумать, что коллеги уже видят изменения, хотя они есть только локально; делать git add . не глядя и случайно закоммитить временные файлы.