Как перестать терять проекты: умная организация рабочего пространства

Ситуация знакомая: у вас 47 репозиториев разбросаны по разным папкам. Часть в /home/dev/projects, часть в /home/dev/work, остальное где-то ещё. В shell-скриптах полно алиасов. И каждый раз, когда нужно вернуться к старому side-проекту, вы тратите время на поиски.

Можно иначе.

Почему классические подходы не работают

Разработчики обычно выбирают один из двух путей.

Первый — глубокая вложенность. Папки внутри папок: ~/projects/web/apps/active/2024/my-app. Пути становятся длинными, перемещать проекты неудобно.

Второй — хаотичное хранение. Каждый репозиторий остаётся там, где его склонили. Работает, пока вы один в этой системе. Но объяснить кому-то другому, где что лежит, почти невозможно.

Главная проблема обоих подходов в том, что они смешивают место проекта и его статус. Проект не переезжает из «активных» в «архив», он просто меняет состояние. Структура папок не должна этому мешать.

Proj: один каталог и теги

Инструмент Proj решает задачу по-другому. Все проекты лежат в одной плоской директории — /home/dev/projects/, и каждый подкаталог это отдельный проект. Никакой вложенности.

Вместо папок статус проекта хранится в YAML-файле через теги. Можно использовать готовые (stable, archived, experiment) или создать свои: client-work, learning, prototype.

Два способа навигации

Интерактивный поиск

$ proj

Открывается fuzzy finder на базе fzf. Можно фильтровать по тегам, искать по имени, и после Enter вы сразу попадаете в нужную директорию.

Прямой доступ

$ proj stable/my-web-app

Если знаете, куда идёте — используйте синтаксис в стиле pass. Удобно для скриптов и автоматизации.

Почему это работает

• Один каталог и один YAML-файл. Ничего лишнего.
• Смена статуса — это просто правка тега. Проект не перемещается, скрипты не ломаются.
• Если поменяются требования к организации — достаточно отредактировать YAML, а не перестраивать файловую структуру.
• Инструмент заточен под то, как думают разработчики: плоская структура, быстрый поиск, минимум ручного ввода путей.

Взгляд NameOcean

В NameOcean мы внимательно относимся к тому, как разработчики работают с инфраструктурой — от регистрации доменов до настройки VPS. Proj — хороший пример «vibe coding»: инструмент, который не отвлекает от задачи.

Никаких сложных настроек, плагинов и лишних абстракций. Просто решает одну проблему и делает это чисто.

Такой же принцип стоит применять ко всей цепочке: организация кода, управление DNS-записями, деплой на хостинг. Лучшие инструменты — те, которые просто работают.

Как начать

Если ваши проекты уже превратились в кашу, стоит попробовать:

1. Клонируйте репозиторий: git clone https://github.com/whizhuii/proj.git
2. Создайте плоскую директорию для проектов
3. Инициализируйте YAML-каталог с существующими проектами
4. Добавьте интеграцию в .bashrc или .zshrc
5. Начните пользоваться

И больше не придётся вручную набирать cd для каждого проекта.

Главное

Proj — пример небольшого, но точного инструмента. Он не претендует на звание системы управления проектами и не конкурирует с IDE. Он просто помогает организовать локальные репозитории так, чтобы это имело смысл.

В мире, где софт часто перегружен функциями, такая ясность цели особенно ценна.

Как вы сейчас организуете проекты? Всё ещё копаетесь в вложенных папках или нашли свой способ? Разработчики NameOcean будут рады услышать ваши подходы.

И пока вы наводите порядок в коде, не забывайте про основы: качественные домены, надёжные DNS-записи и стабильный хостинг. Планируйте осознанно, структурируйте чётко, деплоите уверенно.