Git — основа моей работы с кодом: версионирование, сохранение истории и, прежде всего, разделение публичного и внутреннего. На этой странице рассматривается нюанс GitHub / GitLab, ценность самостоятельно размещённого GitLab и дисциплина работы с репозиториями, которую я применяю ежедневно.
GitHub и GitLab — в чём нюанс
| Критерий |  GitHub |  GitLab |
|---|---|---|
| Модель размещения | SaaS (облако) | SaaS или самостоятельный хостинг (on-premise) |
| Свободное издание | Облачное предложение | Community Edition — открытый исходный код, можно установить у себя |
| Использование в этом проекте | Публичное · обучение · портфолио | Внутреннее · профессиональный код |
| Непрерывная интеграция | GitHub Actions | Встроенные пайплайны CI/CD |
| Отличительное преимущество | Сообщество, видимость | Суверенитет, полный контроль над данными |
Зачем нужен собственный GitLab? Размещение собственного GitLab (Community Edition, открытый исходный код) сохраняет код и его историю вне облака: контроль доступа, сроков хранения и резервного копирования, прямая интеграция с on-premise инфраструктурой и согласованность с подходом суверенитета и соответствия (ISO 27001). GitHub остаётся идеальным для того, что предназначено быть публичным (портфолио, обучение); внутренний GitLab — для того, что должно оставаться под контролем.
Два remote, два назначения
GitHub — публичный- Портфолио (веб-развёртывание)
- Учебные проекты
- База знаний (приватный репозиторий)
Внутренний GitLab — под контролем- Профессиональный код
- История хранится внутри организации
- Ограниченный и отслеживаемый доступ
Изоляция на уровне архитектуры: профессиональный код никогда не проходит через публичный репозиторий. Это не просто организационное правило — это структурное разделение remote.
Дисциплина и гигиена репозиториев
Состояние репозиториев (аудит)
| Проект | Remote | Статус |
|---|---|---|
| portfolio | GitHub | ✓ Чисто |
Обнаруженные лишние файлы
| Файл / папка | Проблема | Исправление |
|---|---|---|
.idea/ | Конфигурация PyCharm | git rm -r --cached .idea/ |
.venv/ | Виртуальное окружение Python | git rm -r --cached .venv/ |
dist/ | Сборка PyInstaller | git rm -r --cached dist/ |
*.lnk | Ярлыки Windows | Исключить через .gitignore |
🎯 Что важно запомнить
- Всегда создавайте
.gitignoreдо первогоgit add . - Удалённый репозиторий хранит копию отправленной в него истории; резервное копирование и восстановление проекта нужно документировать отдельно
- Храните токены (PAT) в менеджере учётных данных системы, никогда — в URL
- Только один активный remote на проект; переименуйте
master→main --allow-unrelated-historiesдля слияния двух историй без общего предка
💻 Первый чистый коммит (workflow)
bash — гигиена + первый push
# 1. .gitignore avant tout # .venv/ __pycache__/ .idea/ dist/ build/ *.spec .env *.lnk # 2. Nettoyer le staging si des parasites ont été indexés git rm -r --cached .idea/ .venv/ dist/ # 3. Branche principale + premier commit git branch -m master main git add . git commit -m "feat: initial commit" # 4. Remote (token dans le gestionnaire d'identifiants) git config --global credential.helper manager git remote add origin https://<gitlab-interne>/<utilisateur>/PROJET.git git push -u origin main # 5. Si le remote a déjà un commit initial (README auto) git pull origin main --allow-unrelated-histories git push -u origin main
Python
Automatisation
Obsidian