Нормален ли такой подход для работы с git'ом(хранение дизайн+код)?

Question

[littleguga]

Можно ли для удобства организовать репозиторий так:

MyRepo
     /design/
          тут файлы нужный для дизайна(шрифты, psd, импортированные из psd картинки и т.д)
     /www/
          тут уже сам код сайта

1. Здрава ли данная идея?
2. Как удобно обмениваться дизайном дизайнеру и верстальщику и кодеру.
3. Есть мысль для дизайнера добавить .gitignore, в котором добавить сам файл gitignore и папку www/

Кто что посоветует?

Заранее благодарен за информативный и полезный ответ!

Answer 1

[bromzh]

Сетевой диск/гуглодрайв/дропбокс. Ещё можно прикреплять файлы к задачам в такс-менеджере, тогда сразу видно что к чему.
Незачем хранить дизайн в гите.

Answer 2

[d'Ivan]

Git хорош лишь для отслеживания изменений программного кода или простых текстовых/небинарных файлов,
а для хранения мультимедиа и других бинарных файлов лучше пользоваться совместными хранилищами типа Dropbox, Google Drive, Yandex Disk, ownCLoud и т.д.

Answer 3

[Андрей Хохлов]

Был у нас заказчик, хранивший psd в репозитории.
Ладно я, верстаю с этого макета. Но зачем back-end разработчику каждый раз тянуть 100 метров макета сливая изменения (кнопочку дорисовали!), да и вообще хранить это у себя?

В общем профита никакого, лишний дискомфорт.
Гораздо удобнее облачные хранилища. Версионность макетов обеспечит тот же Дропбокс.

Comments

[Виталий Хоменко]

Полностью поддерживаю.

Answer 4

[⚡ Kotobotov ⚡]

гит не рекомендуется использовать для хранения крупных файлов (типа больших макетов в псд формате).
могу посоветовать всё же подключить что-нибудь типа гугл диска, и там расшарить для нужных людей доступ.

Comments

[littleguga]

>Не рекомендуется
Кем? Почему?

[⚡ Kotobotov ⚡]

littleguga: ну потому что гит совсем для других целей, там графовая структура данных, и она оптимальна для например текстов, передавая лишь незначительные изменения в самом тексте, фотоже особенно большого размера, будет всегда полностью добавляться, постоянно добавляя полностью новые копии файла, что само по себе очень расточительно, быстро квоту исчерпаете, + долго будет заливаться, вобщем гит совсем не для хранения фсд макетов.

[⚡ Kotobotov ⚡]

littleguga: кем не рекомендуется? -> всеми, почитайте рекомендации у любого гит сервиса.
https://help.github.com/articles/what-is-my-disk-quota/
там кстати написано что больше 100 мегабайт файл не залить, я часто встречался с макетами и больше 200-300 мегабайт.

Answer 5

[Алексей Скобкин]

Возможно, через какое-то время вы придёте к таким вещам как Continuous Delivery и Continuous Integration. Вы хотите, чтобы проект собирался каждый раз, когда дизайнеры обновили PSD?
Кстати, зачем дизайнерам разбираться с Git? Чтобы иметь возможность случайно сломать репозиторий разработчикам?
Если есть такое желание положить всё в Git, то лучше использовать два репозитория. Но вообще, лучше обмениваться материалами по дизайну в облачных сервисах. Для безопасности можно поднять свой Owncloud, если будет желание.
Ну а вообще в Git лучше не хранить большие файлы (а у дизайнеров макеты больше гигабайта - не редкость).

Comments

[littleguga]

> макеты больше гигабайта
К счастью с таким еще не встречался.
>Continuous Integration
Уже близок к этому.

>Вы хотите, чтобы проект собирался каждый раз, когда дизайнеры обновили PSD
Отчасти. Есть много картинок, которые являются элементами интерфейса, иногда их дизайнеры перерисовывают, добавляют новые - удобно, когда gulp поднимается на директорию выше, переходит в папку с дизайном, берет нужные картинки, сжимает их и кладет в нужное место.
Также удобнее хранить в одном месте из-за быстроты разворачивания проекта. Доступ к git - и готово, а так доступ к облаку+гит. А в команде есть не очень расторопные люди, которые еще любят погундеть, что облако, обменивайтесь напрямую и т.д.

[Алексей Скобкин]

К счастью с таким еще не встречался.

Я работал в компании, которая занималась разработкой сайтов. Поверьте, это не редкость.

Уже близок к этому.

Правильно, это улучшает рабочий процесс.

Отчасти. Есть много картинок, которые являются элементами интерфейса, иногда их дизайнеры перерисовывают, добавляют новые - удобно, когда gulp поднимается на директорию выше, переходит в папку с дизайном, берет нужные картинки, сжимает их и кладет в нужное место.

Для этого PSD в репозитории не нужны. gulp должен работать с уже готовыми изображениями.

Также удобнее хранить в одном месте из-за быстроты разворачивания проекта. Доступ к git - и готово, а так доступ к облаку+гит.

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

А в команде есть не очень расторопные люди, которые еще любят погундеть, что облако, обменивайтесь напрямую и т.д.

Ну это уже не в кассу. Люди могут не хотеть пользоваться Git или вообще отказаться писать код. Это проблема другого уровня и решается по-другому.
А по воводу прямого обмена - многие клиенты облачных хостингов умеют синхронизироваться через локальную сеть для ускорения.

[littleguga]

Алексей Скобкин: так я и не только про psd говорил, в вопросе: импортированные из psd картинки и т.д)

[littleguga]

Алексей Скобкин:

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

Дизайнер сделал изменения в psd макете, импортировал оттуда нужные картинки(в Png/jpg), gulp их подобрал, сжал и положил в папку с самим проектом(уже сжатые), тоже самое про шрифты.

[Алексей Скобкин]

littleguga: Вам нужно понять, как делить файлы. Есть исходный код сайта, который выполняется интерпретатором при генерации страниц. Есть ресурсы, которые используются в шаблоне и подгружаются браузером. А есть файлы, которые к работе сайта отношения не имеют - вот им в репозитории не место. А всякие ресурсы типа favicon и прочей статики можно спокойно хранить в репозитории.

[littleguga]

Алексей Скобкин: собственно я и задал вопрос, для того чтобы выяснить, как правильнее и лучше. И в принципе ничего не мешает сделать синхронизацию облака на папку /design/, которая будет лежать по соседству от /www/.

[Алексей Скобкин]

Дизайнер сделал изменения в psd макете, импортировал оттуда нужные картинки(в Png/jpg), gulp их подобрал, сжал и положил в папку с самим проектом(уже сжатые), тоже самое про шрифты.

Тогда у вас для Gulp сорцем будет являтся экспортированное из Photoshop изображение. То есть, вы храните в репозитории это уже отрендеренное изображение, а Gulp делает из него пожатые ресурсы для сайта, которые уже не хранятся в репозитории.

Answer 6

[Думай Головой]

Мы юзаем облачные хранилища

Answer 7

[Павел Радьков]

Нет, неудобно.
Версии у дизайна и кода меняются несинхронно. В общем случае, сначала обновляется версия дизайна, потом дизайн согласуют. Потом верстают согласованную версию, и, когда готово, меняют версию у кода.
До согласования у дизайна может смениться несколько версий, на верстку попадет одна. И у кода может смениться несколько версий без изменения дизайна.
Нет смысла синхронизировать дизайн и код, и хранить их в одном репозитории.

Попробуйте https://www.pixelapse.com/ — система контроля версий для дизайнеров.
Или www.invisionapp.com — там тоже есть версионность исходников, можно «форкать» проекты (но «мерджить» нельзя)

Answer 8

[Curly Brace]

а еще есть возможность добавления репозитория в репозиторий как подпапки

Comments

[littleguga]

Вот это очень интересно, можно поподробнее?

[Curly Brace]

littleguga: https://git-scm.com/book/en/v2/Git-Tools-Submodules

[Curly Brace]

или можно юзать sourcetree и делать все мышкой без заморочек)

[Алексей Скобкин]

littleguga: Это сабмодули. Лучше этого избегать - лишний геморрой.