Останні кілька місяців я все частіше ловлю себе на тому, що працюю з речами, які раніше впевнено жили “на боці розробки”.
Не тому, що я раптом вирішив стати frontend-розробником. Ні. Я все ще дизайнер. Але дизайн дедалі рідше закінчується у Figma.
Коли ти працюєш із дизайн-системами в коді, Storybook, Claude Code, реальними компонентами, AI-прототипами та design-to-code процесами, дуже швидко стає очевидною одна незручна річ:
AI може написати інтерфейс, але хтось усе одно має розуміти, куди потрапили ці зміни, як їх зберегти, як показати команді й як не зламати все навколо.
І ось тут з’являється Git.
Для багатьох дизайнерів Git довгий час здавався чимось з інженерного підвалу. Гілки, коміти, pull request, merge conflict, термінал, білий текст на чорному фоні. Не зовсім те місце, де дизайнер хоче провести свій день.
Максимум: відкрити посилання на GitHub, подивитися README, ввічливо кивнути й закрити вкладку.
Але ситуація змінилася.
AI-інструменти тепер дозволяють дизайнерам робити значно більше, ніж просто описувати інтерфейс. Можна попросити Claude поправити layout, додати empty state, зібрати екран із компонентів дизайн-системи, адаптувати мобільну версію або підготувати інтерактивний прототип, який набагато ближчий до реального продукту.
Звучить чудово.
До моменту, коли ти розумієш, що результат роботи AI — це не магія, яка десь літає в повітрі. Це реальні зміни в реальних файлах. Ці зміни потрібно зберігати. Порівнювати. Перевіряти. Іноді відкочувати назад. Іноді пояснювати розробникам.
І якщо раніше дизайнер міг сказати: “Git — це не моя зона”, то зараз така позиція починає заважати.
Не тому, що кожен дизайнер має стати інженером.
А тому, що дизайнер, який працює з AI та кодовими прототипами, має розуміти базову механіку змін.
Git — це не про те, щоб писати складну backend-логіку або сперечатися про ідеальну архітектуру React-застосунку.
Для дизайнерів Git — це про значно простіше:
Як безпечно спробувати ідею, зберегти результат, показати його команді й не зруйнувати основний продукт?
Саме про це ця стаття.
Це не повний курс Git для розробників.
Не “50 команд, які ви забудете через 20 хвилин”.
Це практичне пояснення Git для дизайнерів: що таке репозиторій, гілка, коміт, pull request і чому все це важливо, коли AI уже пише код поруч із вами.
Git — це історія змін
Якщо дуже просто, Git — це система контролю версій.
Для дизайнерів найближча аналогія — Version History у Figma.
Ви вносите зміни у файл. Зберігаєте версії. Можете подивитися назад і відновити попередній стан, якщо потрібно. Git робить схожу річ, але для коду й файлів проєкту.
Тільки Git значно потужніший.
Він допомагає:
- бачити, які файли змінилися;
- зберігати осмислені версії проєкту;
- порівнювати одну версію з іншою;
- працювати над різними ідеями паралельно;
- повертатися назад, якщо експеримент не вдався;
- відправляти зміни команді;
- обговорювати зміни до того, як вони стануть частиною продукту.
Тобто Git — це не просто “інструмент для розробників”.
Він відповідає на дуже продуктові питання: Що змінилося, хто це змінив, навіщо це було змінено і чи можемо ми безпечно додати це в продукт?
Якщо ви працюєте тільки у Figma, це може здаватися зайвим. Але щойно ви починаєте торкатися коду — напряму або через AI — Git стає вашою страховкою.
Без Git AI-експерименти дуже швидко стають хаотичними.
Учора Claude щось змінив. Сьогодні прототип наче працює. Потім ви просите його “трохи покращити layout”, і раптом половина інтерфейсу виглядає інакше. Через годину вже ніхто не розуміє, яка версія була хорошою, яка зламана, що саме змінилося і як повернутися назад.
Git вирішує саме цю проблему. Він не робить AI розумнішим. Він робить роботу з AI контрольованішою.
Чому це важливо саме зараз
Традиційний дизайн-процес часто виглядав приблизно так:
Figma → handoff → developer → implementation → review → changes
Дизайнер створював макет. Розробник його інтерпретував. Потім починалися звичні питання: який компонент використовувати, які стани існують, як це має поводитися в реальному продукті, що буде на мобільній версії, як обробляти помилки, що показувати, коли немає даних.
Зараз дедалі частіше з’являється інший сценарій:
Figma / Design System → AI prototype → branch → review → implementation
Дизайнер може створити не просто статичну картинку. Іноді це живий прототип. Іноді він використовує реальні компоненти. Іноді він працює в середовищі, яке вже схоже на справжній продукт. Іноді AI пише або змінює код.
Це не означає, що дизайнер замінює frontend-розробника.
Це означає, що межа між дизайном і реалізацією стає тоншою.
І чим ближче дизайнер підходить до коду, тим важливіше розуміти базову інфраструктуру навколо коду.
Git — одна з найважливіших частин цієї інфраструктури.
Основні поняття Git людською мовою
Давайте без академічних визначень і інженерного героїзму.
Дизайнерам не потрібно вивчати весь Git на старті. Не потрібно запам’ятовувати десятки команд. Не потрібно розуміти всі внутрішні механізми Git.
Спочатку достатньо розібратися з кількома поняттями:
- repository;
- commit;
- branch;
- status;
- add;
- push;
- pull;
- pull request;
- merge conflict;
- .gitignore.
Цього вже достатньо, щоб не панікувати, коли ви відкриваєте проєкт, створений розробником або AI-інструментом.
Repository: проєкт із пам’яттю
Репозиторій — це папка проєкту, у якій Git відстежує зміни. Але простіше думати про це так: Репозиторій — це проєкт із пам’яттю.
У звичайній папці лежать файли. У Git-репозиторії лежать файли плюс історія: що змінилося, коли, ким і навіщо.
Репозиторієм може бути:
- frontend-застосунок;
- дизайн-система в коді;
- Storybook-проєкт;
- сайт;
- документація;
- AI-прототип;
- дизайнерський sandbox;
- бібліотека компонентів;
- сайт-портфоліо.
Коли ви завантажуєте проєкт із GitHub, GitLab або Bitbucket, ви зазвичай завантажуєте не тільки поточні файли, а й історію проєкту.
Для цього використовується команда:
git clone https://github.com/example/project.git
clone означає: скопіювати віддалений репозиторій на свій комп’ютер.
Дизайнерською мовою: “Завантаж цей проєкт локально, щоб я міг з ним працювати.”
Commit: осмислена точка збереження
Коміт — це збережений стан проєкту.
Але це не просто Cmd + S.
Коміт — це радше осмислена точка в історії проєкту. Ви маєте вміти пояснити, що саме змінилося.
Наприклад, ви оновили empty state у таблиці документів. Додали зрозуміліший текст, primary action і поправили spacing.
Це можна зберегти як коміт:
git commit -m "Update empty state for documents table"
Текст після -m — це commit message. Він коротко пояснює, що змінилося.
Поганий commit message:
git commit -m "fix"
Трохи краще:
git commit -m "Fix layout"
Ще краще:
git commit -m "Fix mobile layout for onboarding stepper"
Добре:
git commit -m "Improve mobile onboarding stepper spacing"
Для дизайнерів це важливо, бо коміти можуть показувати дизайн-мислення за змінами.
Наприклад:
git commit -m "Add loading state for client list"
git commit -m "Update billing card hierarchy"
git commit -m "Replace deprecated button component"
git commit -m "Add empty state copy for documents table"
git commit -m "Refine sidebar navigation spacing"
Це вже не тільки технічна історія. Це також історія інтерфейсних рішень.
Status: перевірити, що відбувається
Одна з найкорисніших Git-команд:
git status
Вона показує поточний стан проєкту.
Наприклад:
- які файли змінилися;
- які файли нові;
- які зміни готові до коміту;
- які зміни ще не підготовлені;
- у якій гілці ви зараз перебуваєте.
Для дизайнерів ця команда означає: “Покажи, що я змінив.”
Хороша новина: git status нічого не ламає. Її можна запускати скільки завгодно разів.
Перед будь-якою важливою дією можна написати:
git status
Це як перевірити шари у Figma перед тим, як рухати щось важливе.
Add: підготувати зміни до коміту
Перед тим як створити коміт, потрібно сказати Git, які зміни ви хочете включити.
Для цього використовується команда:
git add .
Крапка означає “додати всі поточні зміни в цьому проєкті”.
Це зручно, але іноді ризиковано. Можна випадково додати тимчасові нотатки, локальні налаштування, згенеровані файли або щось, що не має бути частиною репозиторію.
Акуратніший варіант — додати конкретний файл:
git add src/components/EmptyState.tsx
Людською мовою: “Підготуй цей файл до наступного коміту.”
Важлива різниця:
- git add не зберігає зміни в історію;
- git add тільки готує їх;
- реальна точка збереження створюється через git commit.
Типовий міні-процес виглядає так:
git status
git add .
git commit -m "Update empty state layout"
Спочатку ви перевіряєте, що змінилося. Потім готуєте зміни. Потім зберігаєте їх в історію.
Branch: безпечний простір для експериментів
Гілка — одне з найважливіших понять Git для дизайнерів.
Branch — це окрема лінія роботи.
У більшості проєктів є головна гілка. Сьогодні її зазвичай називають main. У старіших проєктах вона може називатися master.
У головній гілці зазвичай лежить стабільна версія проєкту. Версія, яку вже прийняли, перевірили і яка може бути пов’язана з продуктом.
Але якщо ви хочете спробувати нову ідею, не варто робити це прямо в main.
Краще створити окрему гілку:
git checkout -b redesign-empty-state
Або через новіший синтаксис:
git switch -c redesign-empty-state
Це означає: “Створи нову гілку й перемкни мене в неї.”
Для дизайнерів гілка — це як окремий exploration file у Figma.
Ви можете спробувати нову навігацію, зібрати AI-прототип, змінити layout, протестувати компонент, і все це не зламає основну версію проєкту.
Приклади назв гілок:
git checkout -b ai-dashboard-prototype
git checkout -b improve-billing-flow
git checkout -b update-mobile-navigation
git checkout -b test-new-empty-state-pattern
Хороша назва гілки допомагає команді зрозуміти, що відбувається.
Погані назви:
- test
- new
- fix
- nick-branch
Кращі назви:
- improve-client-list-empty-state
- update-settings-layout
- prototype-ai-generated-dashboard
- fix-mobile-table-toolbar
Pull: забрати останні зміни команди
Коли ви працюєте з проєктом, ви не самі. Розробники, інші дизайнери, AI-агенти та інші члени команди також можуть щось змінювати.
Перед початком роботи корисно оновити локальний проєкт:
git pull
Це означає: “Забери останні зміни з віддаленого репозиторію.”
Чому це важливо? Бо якщо ви працюєте зі старою версією проєкту, AI теж працюватиме зі старим контекстом. Він може використати застарілий компонент, стару структуру файлів, видалений API або deprecated pattern.
Хороша звичка:
git pull
git status
Спочатку оновити проєкт. Потім перевірити поточний стан.
Push: відправити свої зміни команді
Коли ви створили коміт, він усе ще живе тільки на вашому комп’ютері.
Щоб команда побачила вашу гілку й ваші зміни, потрібно відправити їх у віддалений репозиторій:
git push
Іноді потрібно явно вказати гілку:
git push origin improve-client-list-empty-state
Людською мовою: “Відправ мою гілку в хмару, щоб команда могла її переглянути.”
Після цього зазвичай можна створити pull request.
Pull Request: місце, де зміни стають розмовою
Pull request, або PR, — це запит на додавання ваших змін у головну гілку.
Для розробників PR — звичайна частина робочого процесу.
Для дизайнерів це може звучати занадто технічно.
Але насправді PR — це дуже дизайнерський артефакт.
Хороший PR відповідає на такі питання:
- що змінилося;
- чому це змінилося;
- яку проблему це вирішує;
- які компоненти були використані;
- які стани потрібно перевірити;
- що ще відкрите;
- де є ризики.
Наприклад, опис PR від дизайнера може виглядати так:
## What changed
Updated the empty state for the Documents table.
## Why
The previous state did not explain what users should do next when no documents were available.
## Design notes
- Added clearer title and helper text
- Added primary CTA
- Used existing EmptyState component
- Kept layout aligned with the current table pattern
## Needs review
- Copy
- Spacing
- Mobile behavior
- Component usage
Це вже не просто “я змінив якийсь код”.
Це зрозуміле пояснення дизайн-рішення.
PR — це місце, де дизайнер може пояснити свою логіку розробникам, продактам, QA та іншим дизайнерам.
Це не тільки технічний gate. Це точка командного review.
Merge: додати зміни в головну гілку
Коли зміни перевірили й прийняли, гілку можна об’єднати з головною гілкою. Це називається merge.
Людською мовою: “Додати зміни з моєї гілки в основну версію проєкту.”
У реальних продуктових командах дизайнерам часто не потрібно робити merge самостійно. Зазвичай це роблять розробники або власники репозиторію.
Але дизайнерам важливо розуміти сам процес:
branch → pull request → review → merge
Спочатку ви працюєте окремо.
Потім показуєте зміни.
Потім команда їх перевіряє.
Потім зміни стають частиною головної гілки.
Це безпечний шлях.
Merge Conflict: коли Git не знає, яку версію вибрати
Іноді дві людини змінюють одну й ту саму частину одного файлу. Або ви змінюєте файл, який паралельно змінив хтось інший.
Git намагається об’єднати зміни автоматично. Але іноді не може.
Тоді виникає merge conflict.
Для дизайнерів просте пояснення таке: Git бачить дві різні версії одного й того самого місця й питає: “Яку залишити?”
Наприклад, одна людина змінила текст кнопки на:
Create document
Інша людина змінила той самий текст на:
Add new document
Git не завжди може вирішити, який варіант правильний. Бо це не тільки технічне рішення. Це продуктове й UX-рішення.
У коді conflict може виглядати страшно:
<<<<<<< HEAD
Create document
=======
Add new document
>>>>>>> update-empty-state-copy
Але сенс простий:
- одна версія зверху;
- інша версія знизу;
- потрібно вибрати правильний фінальний варіант;
- службові маркери потрібно видалити;
- фінальний файл потрібно зберегти.
У великих проєктах conflicts можуть бути складними. Дизайнерам не потрібно вирішувати їх наодинці.
Але корисно розуміти, що саме відбувається.
Merge conflict — це не катастрофа. Це просто Git чесно каже: “Я не впевнений, яка версія правильна.”
.gitignore: список того, що Git має ігнорувати
Не кожен файл потрібно зберігати в Git.
Наприклад:
- тимчасові файли;
- системні файли;
- локальні налаштування;
- згенеровані папки;
- залежності;
- особисті нотатки;
- файли, створені редактором.
Для цього існує .gitignore.
Він каже Git: “Не відстежуй ці файли й папки.”
Приклад:
node_modules/
dist/
.DS_Store
.env
my-notes.txt
Для дизайнерів це важливо, тому що AI-інструменти та локальні проєкти можуть створювати зайві файли. Не все потрібно комітити.
Особливо обережно треба ставитися до .env файлів. У них можуть бути ключі, токени, паролі та локальні налаштування середовища. Їх майже ніколи не потрібно відправляти в публічний або спільний репозиторій.
Мінімальний набір Git-команд для дизайнерів
Дизайнерам на старті не потрібен весь Git.
Цього невеликого набору достатньо, щоб розуміти більшість щоденних ситуацій.
Завантажити проєкт
git clone https://github.com/example/project.git
Перевірити поточний стан
git status
Забрати останні зміни
git pull
Створити нову гілку
git checkout -b my-design-change
або:
git switch -c my-design-change
Підготувати зміни
git add .
або акуратніше:
git add path/to/file
Створити коміт
git commit -m "Describe design change"
Відправити зміни
git push
Подивитися історію комітів
git log
Побачити різницю
git diff
Якщо зробити ще коротше, базовий workflow виглядає так:
git pull
git checkout -b improve-empty-state
git status
git add .
git commit -m "Improve empty state for documents table"
git push
Людською мовою:
Оновити проєкт.
Створити окрему гілку.
Перевірити, що змінилося.
Підготувати зміни.
Зберегти їх із зрозумілим описом.
Відправити гілку команді.
Реалістичний сценарій для дизайнера
Уявімо ситуацію.
У вас є таблиця документів. Коли документів немає, інтерфейс показує сухе повідомлення:
No data
Як дизайнер, ви розумієте, що це слабкий empty state. Користувач не розуміє, що сталося і що робити далі.
Ви хочете його покращити:
- зрозуміліший заголовок;
- корисний допоміжний текст;
- primary action;
- краща ієрархія;
- відповідність патерну дизайн-системи.
У старому workflow ви, ймовірно, створили б макет у Figma і передали його розробнику.
Тепер можливий інший workflow.
Ви відкриваєте проєкт і створюєте гілку:
git checkout -b improve-documents-empty-state
Просите Claude Code:
Update the Documents table empty state using the existing EmptyState component.
Add a clear title, helper text, and primary CTA.
Keep spacing consistent with the table pattern.
AI змінює файли. Ви перевіряєте, що змінилося:
git status
git diff
Якщо все виглядає розумно, готуєте зміни:
git add .
Створюєте коміт:
git commit -m "Improve documents empty state"
Відправляєте гілку:
git push
Потім створюєте pull request і пояснюєте дизайн-логіку:
## What changed
Updated the empty state for the Documents table.
## Why
The previous state did not guide users toward the next action.
## Design notes
- Used existing EmptyState component
- Added primary CTA
- Updated hierarchy and spacing
- Kept behavior aligned with the table empty state pattern
## Needs review
- Copy
- Component usage
- Mobile behavior
Це і є design-to-code workflow. Ви не стали розробником. Ви не забрали на себе production engineering. Ви просто наблизили дизайн-рішення до реальності й зробили його видимим для команди.
Типові Git-помилки дизайнерів
- Працювати прямо в main
Якщо ви новачок у Git, не експериментуйте в головній гілці.
Погана ідея:
main → AI changes → commit → push
Краща ідея:
main → new branch → AI changes → PR → review
Гілка — це ваш безпечний playground.
- Комітити все наосліп
AI може створити або змінити багато файлів. Не всі вони потрібні.
Перед комітом перевірте:
git status
git diff
Запитайте себе: Я розумію, що саме зараз збираюся відправити?
Якщо відповідь “не зовсім”, краще зупинитися й попросити розробника переглянути зміни.
- Писати беззмістовні commit messages
Погані commit messages:
- fix
- update
- changes
- new version
- final
- final final
Так, дизайнери теж так називають файли. Усі ми там були.
Кращі commit messages:
- Update onboarding stepper spacing
- Add empty state for documents table
- Refine billing summary card layout
- Fix mobile navigation overflow
- Replace deprecated icon component
Commit message має бути коротким, але зрозумілим.
- Не робити pull перед початком роботи
Якщо ви давно не оновлювали проєкт, ви можете працювати зі старою версією.
Перед стартом:
git pull
Ця проста звичка може зекономити багато нервів.
- Сліпо довіряти AI
AI може написати код, який виглядає впевнено, але він може:
- використати неправильний компонент;
- зламати існуючий pattern;
- продублювати логіку, яка вже існує;
- додати зайві кастомні стилі;
- проігнорувати accessibility;
- забути про mobile behavior;
- створити новий елемент замість використання дизайн-системи.
Git не оцінить якість дизайну за вас. Але він допоможе побачити, що саме AI змінив.
Саме тому важливо перевіряти diff:
- git diff
Це одна з найкорисніших звичок в AI-assisted design роботі.
Git Diff: суперсила для дизайнерів
git diff показує різницю між тим, що було, і тим, що є зараз.
Для розробників це базовий інструмент.
Для дизайнерів він також може бути неймовірно корисним, особливо під час роботи з AI.
Коли Claude або Cursor змінює файли, ви можете не розуміти кожен рядок коду. Але часто можете помітити важливі речі:
- чи змінено правильний компонент;
- чи не зачеплено забагато файлів;
- чи не видалено важливий текст;
- чи не додано дивні кастомні стилі;
- чи не змінилася структура занадто широко;
- чи не замінив AI системний компонент на кастомний.
Приклад:
git diff
Якщо ви попросили AI поправити empty state, а він змінив 18 файлів, routing, package-lock і половину layout-системи, це сигнал зупинитися.
AI любить допомагати. Іноді занадто сильно. git diff допомагає тримати його під контролем.
GitHub, GitLab і Bitbucket — це не Git
Ще одне важливе уточнення.
Git — це сама система контролю версій.
GitHub, GitLab і Bitbucket — це платформи, де Git-репозиторії зберігаються онлайн.
Дуже грубо:
Git = технологія
GitHub / GitLab / Bitbucket = платформи навколо Git
Для дизайнерів це схоже на різницю між:
дизайн-файл → Figma як платформа
Git може працювати локально на вашому комп’ютері. Але в команді репозиторій майже завжди живе на віддаленій платформі, наприклад GitHub, GitLab або Bitbucket.
Саме там створюються pull requests, відбувається review, запускаються автоматичні перевірки й зберігаються обговорення.
Чи можуть дизайнери використовувати Git без терміналу?
Так.
Не обов’язково з першого дня жити в терміналі.
Є візуальні Git-інструменти:
- GitHub Desktop;
- Sourcetree;
- Fork;
- GitKraken;
- вбудовані Git-інструменти у VS Code;
- вебінтерфейси GitHub і GitLab.
Для дизайнерів візуальний клієнт може бути чудовим стартом. Там видно:
- які файли змінилися;
- що було додано;
- що було видалено;
- які існують гілки;
- які коміти створені.
Але базові команди все одно корисно розуміти.
Не тому, що термінал робить вас “справжнім інженером”.
А тому, що AI-інструменти, документація й розробники часто говорять мовою Git-команд.
Якщо ви розумієте git status, git pull, git checkout -b, git commit і git push, ви вже не губитеся повністю.
Git і дизайн-системи
Git особливо важливий для дизайн-систем.
Сучасна дизайн-система не живе тільки у Figma.
Вона може включати:
- Figma components;
- design tokens;
- React components;
- Storybook;
- документацію;
- usage guidelines;
- accessibility rules;
- visual regression tests;
- component APIs;
- changelog;
- Code Connect mappings;
- AI-readable documentation.
Усе це потрібно якось координувати.
Якщо дизайнер змінює компонент у Figma, це одна зміна.
Якщо команда змінює компонент у коді, це інша зміна.
Якщо AI генерує новий інтерфейс на базі компонентів, це третя зміна.
Git допомагає зрозуміти, що відбувається на кодовому боці системи.
Наприклад:
- коли змінився компонент;
- які props були додані;
- який variant було видалено;
- чому змінилася поведінка;
- хто зробив зміну;
- у якому pull request це обговорювали.
Для дизайнера дизайн-систем це особливо важливо.
Дизайн-система — це не просто бібліотека красивих компонентів.
Це домовленість між дизайном і реалізацією.
Git зберігає історію цієї домовленості на боці коду.
Git і AI: чому контроль має значення
AI створює ілюзію простоти.
Ви пишете:
Build a dashboard using our design system components.
AI повертає код. Інтерфейс з’являється. Це майже магія.
Але проблема в тому, що AI не завжди розуміє системні обмеження.
Він може:
- створити новий Button замість використання системного Button;
- написати локальні стилі замість токенів;
- проігнорувати існуючий layout pattern;
- вигадати новий empty state;
- змішати старі й нові компоненти;
- додати непотрібну залежність;
- змінити поведінку, яку ви не просили чіпати.
Якщо ви не використовуєте Git, дуже швидко стає незрозуміло, що насправді сталося.
Git перетворює AI-експеримент на контрольований workflow:
idea → branch → AI changes → diff → commit → PR → review
Це ключова зв’язка.
AI генерує.
Дизайнер спрямовує.
Git фіксує.
Команда перевіряє.
Хороший AI + Git workflow для дизайнерів
Безпечніший процес може виглядати так.
- Оновити проєкт git pull
- Створити гілку git checkout -b prototype-new-client-dashboard
- Попросити AI внести зміну
Наприклад:
Create a prototype of the new client dashboard using existing design system components.
Do not create new components unless necessary.
Use existing spacing tokens and table patterns.
- Перевірити, що змінилося git status git diff
- Протестувати локально
Наприклад, запустити проєкт або Storybook. Конкретна команда залежить від проєкту:
npm run dev
або:
npm run storybook
- Створити коміт
git add .
git commit -m "Prototype new client dashboard layout"
- Відправити гілку
git push
- Створити PR і пояснити дизайн-логіку
Не просто “updated dashboard”, а щось на кшталт:
## What changed
Created a prototype for the new client dashboard layout.
## Why
We need to test whether the new structure improves visibility of key client metrics.
## Design notes
- Used existing Card, Table, Badge, and EmptyState components
- Followed the current dashboard layout pattern
- Avoided new custom components
- Mobile behavior needs additional review
## Open questions
- Should the activity feed be visible by default?
- Do we need a compact state for smaller accounts?
Це зріла дизайнерська робота з AI та кодом.
Чи потрібно дизайнерам знати термінал?
В ідеалі — так, хоча б на базовому рівні.
Вам не потрібно ставати terminal ninja.
Але корисно не боятися відкрити термінал і виконати кілька команд.
Мінімум:
git status
git pull
git checkout -b branch-name
git add .
git commit -m "Message"
git push
Цього вже достатньо, щоб почуватися впевненіше. Суть не в кількості команд, які ви знаєте. Суть у розумінні процесу.
Чи потрібно дизайнерам вирішувати conflicts?
Не завжди.
Якщо ви працюєте в реальному продуктовому репозиторії, особливо у великій frontend-кодовій базі, складні conflicts зазвичай краще вирішувати разом із розробником.
Але дизайнерам корисно розуміти:
- чому виник conflict;
- які файли були зачеплені;
- яка частина зміни стосується дизайну;
- яку версію інтерфейсу потрібно залишити;
- де потрібне продуктове рішення, а не тільки технічне.
Іноді conflict насправді не про код. Іноді він про дизайн-рішення. Наприклад, дві людини змінили один і той самий текст, layout, компонент або pattern. У такій ситуації дизайнер може бути саме тією людиною, яка пояснить, яка версія правильна з точки зору UX.
Що дизайнерам не потрібно робити
Важливо також не перегнути.
Дизайнерам не потрібно:
- глибоко розуміти внутрішню будову Git;
- лагодити складну історію комітів;
- переписувати shared branches;
- використовувати force push;
- самостійно вирішувати складні production conflicts;
- розуміти всю frontend-архітектуру;
- брати на себе відповідальність за production-код без review.
Базовий Git для дизайнерів — це не про героїзм.
Це про грамотність.
Так само як дизайнерам довелося розібратися з accessibility, responsive behavior, design tokens і component states, зараз стає корисно розуміти branches, commits і pull requests.
Найкоротша шпаргалка
Якщо хочеться запам’ятати тільки найважливіше:
git status
Показує, що відбувається.
git pull
Забирає останні зміни.
git checkout -b my-branch
Створює нову гілку.
git add .
Готує зміни до коміту.
git commit -m "My message"
Зберігає зміни в історію.
git push
Відправляє зміни у віддалений репозиторій.
git diff
Показує, що саме змінилося.
Якщо ви розумієте ці сім команд, ви вже не “дизайнер, який випадково загубився в Git”. Ви дизайнер, який розуміє базову механіку сучасної продуктової роботи.
Git не замінює дизайн-мислення. Git не зробить поганий інтерфейс хорошим.
Він не напише за вас логіку empty state.
Не вирішить, який CTA правильний.
Не зрозуміє, коли потрібен progressive disclosure.
Не пояснить, чому користувачі бояться натискати destructive action.
Не побудує за вас інформаційну архітектуру.
Але Git допоможе безпечно зберегти, перевірити, показати й обговорити результат.
У цьому його цінність для дизайнерів.
Особливо зараз, коли AI може генерувати код швидше, ніж команди встигають домовитися про правила.
Фінальна думка
Дизайнерська професія знову розширюється.
Колись дизайнери могли зосереджуватися переважно на візуальній частині. Потім роль виросла й почала включати UX, research, продуктове мислення, метрики, accessibility, дизайн-системи, контент, аналітику та ближчу співпрацю з розробкою.
Тепер додається ще один шар: AI-assisted production thinking.
Це не означає, що дизайнери мають стати full-stack розробниками.
Але це означає, що дизайнерам дедалі частіше потрібно розуміти, як їхні рішення проходять шлях від ідеї до реалізації.
Git — одна з базових частин цього шляху.
Бо у світі, де AI пише код, питання вже не тільки в тому, хто може згенерувати інтерфейс.
Важливіше питання інше:
Хто розуміє, що змінилося, чому це змінилося, де це збережено, як це перевірити і чи можна це безпечно зробити частиною продукту?
Ось чому дизайнерам час розібратися з Git.
Топ коментарі (0)