ShuraBB 1,151 Posted October 20, 2017 bitbucket Замечания, пожелания и предложения разумеется принимаются :-) 16 1 Quote Share this post Link to post Short link Share on other sites
GPCracker 2,088 #410142 Posted November 3, 2017 @ShuraBB, во-первых, для выделения релизных состояний существуют теги. Не нужно создавать копии файлов в репозитории. При необходимости собрать старую версию существует checkout. При этом все отслеживаемые файлы в репозитории откатываются на состояние нужного коммита. Можно даже прописать checkout -b <branch> <target>, это создает и переходит на новую ветку, указывающую на target. Насчет того, что твои текущие изменения убьются при checkout - есть git stash - прячет все незакоммиченнные изменения, потом можно вернуться и достать их обратно. Во-вторых, упакованных *.zip, *.pyc, etc. файлов в репозитории быть не должно, только исходники. Для собранных бинарников на GitHub есть releases, аналог на Bitbucket подсказать, к сожалению, не могу, давно не сидел там, для публичных репозиториев GitHub ИМХО лучше. Тем более, что у тебя для этого есть свой сайт. В-третьих, добавить readme.md хоть самый простенький, потом допишешь, если будет необходимость. В-четвертых, не использовать транслит, использовать или правильный English, или правильный Русский. Англоговорящая аудитория его принципиально не поймет, и переводчиком воспользоваться не сможет. В-пятых, все временные файлы, и вообще файлы, которые никому кроме тебя не нужны, в репозиторий коммиттить смысла нет. В-шестых, для DEV версий нужно создавать не папку, а ветку. Работаешь и коммиттишь туда, когда будет готово - делаешь merge. Если в процессе картошка чего-то наваяла - есть rebase, все изменения из master автоматом подтянутся под DEV ветку. Ну максимум придется разрулить конфликты. Ну а так вполне годный репо, и моды достаточно простые у тебя... Для новичков самое оно. 4 Quote Share this post Link to post Short link Share on other sites
ShuraBB 1,151 #410196 Posted November 3, 2017 (edited) Ага, спасибо за советы, но: - Мой репозиторий и правила для него мои ;-) - Если ты Гит используешь только как средство работы с исходниками, то я, Bitbucket как средство работы с проектом в целом (и даже в большей степени как средство хранения с контролем изменений) и мне удобно чтобы там было все что мне нужно. - readme.md давно нужно, да руки все никак не доходят... Edited November 3, 2017 by ShuraBB 3 Quote Share this post Link to post Short link Share on other sites
GPCracker 2,088 #410200 Posted November 3, 2017 11 minutes ago, ShuraBB said: Мой репозиторий и правила для него мои ;-) Просил конструктивной критики - получите, распишитесь, мне не жалко :) 12 minutes ago, ShuraBB said: Если ты Гит используешь только как средство работы с исходниками, то я, Bitbucket как средство работы с проектом в целом (и даже в большей степени как средство хранения с контролем изменений) и мне удобно чтобы там было все что мне нужно. Для бекапа можно использовать куда более простые вещи, тот же Dropbox к примеру. Git же изначально разрабатывался как средство контроля изменений в проекте, кто, когда, что и по какой причине изменил. Также одна из основных идей системы версионного контроля - это возможность параллельной работы над проектом, т.е. обеспечение возможности слияния изменений. Соответственно, хранение всякого хлама в репозитории создает проблемы с анализом этих самых изменений, если таковой потребуется, проблемы со слиянием изменений, ребейзом и т.д. В особенности с тем, что Git при чекаутах будет трогать эти файлы тоже (он будет изменять все файлы, затронутые коммиттами, в пределах которых ты пытаешься прыгать). Фишка гита в том, что ты можешь спокойно в фоне мутить новую фичу, потом быстро и резко переключиться на основную ветку, накатить коммит или несколько коммитов, для совместимости с новой версией клиента игры после очередного говнопатча от картохи, к примеру, сделать билд и зарелизить (и поставить штамп "обновлено"), потом и далее спокойно переключиться обратно на ветку разработки, и сделать ребейз (а иначе ты не сможешь тестить свой DEV на новом клиенте), и все, что ты запатчил в основной ветке, затянется в твою ветку разработки. По окончании разработки ты просто делаешь мерж, или ребейз+фаст-форвард-мерж, и твой DEV выкатывается в релиз. Красота и симметрия, не нужно руками как мудак копировать правки из одной папки в другую. Для микромодов, конечно, пофигу, но для относительно крупных вещей это нехило упрощает жизнь, ибо большую половину всего этого геморроя с копипастом за тебя делает Git. 2 Quote Share this post Link to post Short link Share on other sites
ShuraBB 1,151 #410201 Posted November 3, 2017 3 минуты назад, GPCracker сказал: Просил конструктивной критики - получите, распишитесь, мне не жалко :) Ну так это национальная традиция - выслушать совет умного человека но все равно сделать по своему ;-) 8 минут назад, GPCracker сказал: Соответственно, хранение всякого хлама в репозитории создает проблемы с анализом этих самых изменений Проект это не только исходники... 2 Quote Share this post Link to post Short link Share on other sites
GPCracker 2,088 #410209 Posted November 3, 2017 (edited) 22 minutes ago, ShuraBB said: Проект это не только исходники... Файлы в проекте делятся на 3 типа. 1. Файлы-исходники, которые сгенерированы автором проекта РУЧКАМИ в редакторе (не обязательно это текстовые файлы, могут быть и картинки, важен источник их появления). 2. Файлы-бинарники (хотя могут быть и текстовыми), которые сгенерированы системой сборки проекта (компилятором), или откуда-то взятые, в общем, файлы, которые непосредственно автор руками в редакторе не создает. 3. Файлы, которые в проекте чисто временные/персональные, и какой-либо ценности для проекта с точки зрения других людей не имеют. Правило простое. Точнее их три. A. Если файл ни для кого больше, кроме тебя, в репо не нужен, и для сборки проекта не используется - в gitignore его. B. Если файл генерируется в процессе сборки и его отсутствие не мешает собрать проект с нуля - отправляй его туда же - в gitignore. C. Если файл берется из выхлопа другого проекта - этот момент прописывается в readme и файл отправляется по известному маршруту - в gitignore. В репозитории все серьезные организации и проекты держат только файлы 1 категории. В случае "A" - файл очевидно в репозитории не нужен. В случае "B" он будет сгенерирован автоматически при сборке, и поэтому в репозитории не нужен. В случае "C" его можно взять известно где, и поэтому в репозитории он не нужен. К примеру, элемент атласа - это "исходник" (1), сам атлас - "бинарник" (2). SWC - библиотеки картофана - 2 категория, и вообще это касается любых исходных файлов из клиента игры, которые планируется патчить. В репозитории остается только патч, и инструкция по его применению, или готовый скрипт, применяющий патч на подкинутый файл. Edited November 3, 2017 by GPCracker 2 Quote Share this post Link to post Short link Share on other sites
ShuraBB 1,151 #410214 Posted November 3, 2017 16 минут назад, GPCracker сказал: В репозитории все серьезные организации и проекты держат только файлы 1 категории. Не-а ;-) Простейший пример: Над проектом работают два человека, 1 - пишет код и компилит его, 2й занимается ловлей блох в скомпилированном (он возможно даже знает как компилить, но это не его задача). 1 2 Quote Share this post Link to post Short link Share on other sites
GPCracker 2,088 #410215 Posted November 3, 2017 (edited) 6 minutes ago, ShuraBB said: Над проектом работают два человека, 1 - пишет код и компилит его, 2й занимается ловлей блох в скомпилированном (он возможно даже знает как компилить, но это не его задача). Простейший пример. 1й человек пишет код, выкладывает его в репозиторий, для остальных, кто тоже пишет код, потом кто-то (ответственный за сборку проекта) собирает его и выкладывает бинарники в раздел релизов, 2й человек качает готовый бинарник и занимается ловлей блох. Если он в теме, как фиксить блоху - он ее фиксит, заливает в свой репо фикс, делает пулл-реквест в основной репозиторий. Если он не в теме, как фиксить - он скидывает репорт тому, кто в теме, тот фиксит, ответственный за сборку собирает... в общем по второму кругу. Сборкой вообще может машина заниматься, как, например, у XVM реализовано, найтлики, т.н. В переводе на русский. Бинарники - мусор для разработчика. Исходники - ненужные файлы для пользователей и тестировщиков. Почему бы не хранить их в удобной для обоих групп манере - раздельно. Исходники в репозитории, с контролем изменений, бинарники - в файловом хранилище, с подписанными версиями, патчноутами и т.д.? Edited November 3, 2017 by GPCracker 2 Quote Share this post Link to post Short link Share on other sites
tunut 203 #410226 Posted November 3, 2017 ацки плюсую за установщик но как сделать вот это т.е. переместить и зафиксировать превьюшку на новое место, чтобы за мышкой не бегала... Quote Share this post Link to post Short link Share on other sites
ShuraBB 1,151 #410239 Posted November 3, 2017 (edited) 1 час назад, tunut сказал: т.е. переместить и зафиксировать превьюшку на новое место, чтобы за мышкой не бегала... Скрипт отображения превьюшки переписать надо. Но мне пока не досуг этим заниматься - показывает и хорошо :-) 2 часа назад, GPCracker сказал: Почему бы не хранить их в удобной для обоих групп манере - раздельно. Основное правило нормального проекта - весь проект должен быть в ОДНОМ месте! P.S. Давай закроем эту тему. Edited November 3, 2017 by ShuraBB 2 1 Quote Share this post Link to post Short link Share on other sites
GPCracker 2,088 #410241 Posted November 3, 2017 (edited) 13 minutes ago, ShuraBB said: Основное правило нормального проекта - весь проект должен быть в ОДНОМ месте! Раздельно - не значит в разных местах, как и в одном месте не означает вперемешку :) Но в одном ты прав - что-то мы сильно увлеклись. В любом случае, если на большинстве серьезных проектов чего-то принципиально принято не делать, скорее всего это результат либо личного опыта, либо опыта других серьезных проектов... :) Отсюда и понятия "bad-practice" и "best-practice". Edited November 3, 2017 by GPCracker Quote Share this post Link to post Short link Share on other sites
ShuraBB 1,151 #410243 Posted November 3, 2017 Quote Share this post Link to post Short link Share on other sites