Jump to content
Korean Random
ShuraBB

Исходники модов от ShuraBB

Recommended Posts

bitbucket

Замечания, пожелания и предложения разумеется принимаются :-)

  • Upvote 16
  • Downvote 1

Share this post


Link to post

Short link
Share on other sites

@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 ветку. Ну максимум придется разрулить конфликты.

Ну а так вполне годный репо, и моды достаточно простые у тебя... Для новичков самое оно.

  • Upvote 4

Share this post


Link to post

Short link
Share on other sites

Ага, спасибо за советы, но:

- Мой репозиторий и правила для него мои ;-)

- Если ты Гит используешь только как средство работы с исходниками, то я, Bitbucket как средство работы с проектом в целом (и даже в большей степени как средство хранения с контролем изменений) и мне удобно чтобы там было все что мне нужно.

- readme.md давно нужно, да руки все никак не доходят...

Edited by ShuraBB
  • Downvote 3

Share this post


Link to post

Short link
Share on other sites
11 minutes ago, ShuraBB said:

Мой репозиторий и правила для него мои ;-)

Просил конструктивной критики - получите, распишитесь, мне не жалко :)

12 minutes ago, ShuraBB said:

Если ты Гит используешь только как средство работы с исходниками, то я, Bitbucket как средство работы с проектом в целом (и даже в большей степени как средство хранения с контролем изменений) и мне удобно чтобы там было все что мне нужно.

Для бекапа можно использовать куда более простые вещи, тот же Dropbox к примеру. Git же изначально разрабатывался как средство контроля изменений в проекте, кто, когда, что и по какой причине изменил. Также одна из основных идей системы версионного контроля - это возможность параллельной работы над проектом, т.е. обеспечение возможности слияния изменений. Соответственно, хранение всякого хлама в репозитории создает проблемы с анализом этих самых изменений, если таковой потребуется, проблемы со слиянием изменений, ребейзом и т.д. В особенности с тем, что Git при чекаутах будет трогать эти файлы тоже (он будет изменять все файлы, затронутые коммиттами, в пределах которых ты пытаешься прыгать).

Фишка гита в том, что ты можешь спокойно в фоне мутить новую фичу, потом быстро и резко переключиться на основную ветку, накатить коммит или несколько коммитов, для совместимости с новой версией клиента игры после очередного говнопатча от картохи, к примеру, сделать билд и зарелизить (и поставить штамп "обновлено"), потом и далее спокойно переключиться обратно на ветку разработки, и сделать ребейз (а иначе ты не сможешь тестить свой DEV на новом клиенте), и все, что ты запатчил в основной ветке, затянется в твою ветку разработки. По окончании разработки ты просто делаешь мерж, или ребейз+фаст-форвард-мерж, и твой DEV выкатывается в релиз. Красота и симметрия, не нужно руками как мудак копировать правки из одной папки в другую. Для микромодов, конечно, пофигу, но для относительно крупных вещей это нехило упрощает жизнь, ибо большую половину всего этого геморроя с копипастом за тебя делает Git.

  • Upvote 2

Share this post


Link to post

Short link
Share on other sites
3 минуты назад, GPCracker сказал:

Просил конструктивной критики - получите, распишитесь, мне не жалко :)

Ну так это национальная традиция - выслушать совет умного человека но все равно сделать по своему ;-)

 

8 минут назад, GPCracker сказал:

Соответственно, хранение всякого хлама в репозитории создает проблемы с анализом этих самых изменений

Проект это не только исходники...

  • Downvote 2

Share this post


Link to post

Short link
Share on other sites
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 by GPCracker
  • Upvote 2

Share this post


Link to post

Short link
Share on other sites
16 минут назад, GPCracker сказал:

В репозитории все серьезные организации и проекты держат только файлы 1 категории.

Не-а ;-)

Простейший пример:

Над проектом работают два человека, 1 - пишет код и компилит его, 2й занимается ловлей блох в скомпилированном (он возможно даже знает как компилить, но это не его задача).

  • Upvote 1
  • Downvote 2

Share this post


Link to post

Short link
Share on other sites
6 minutes ago, ShuraBB said:

Над проектом работают два человека, 1 - пишет код и компилит его, 2й занимается ловлей блох в скомпилированном (он возможно даже знает как компилить, но это не его задача).

Простейший пример. 1й человек пишет код, выкладывает его в репозиторий, для остальных, кто тоже пишет код, потом кто-то (ответственный за сборку проекта) собирает его и выкладывает бинарники в раздел релизов, 2й человек качает готовый бинарник и занимается ловлей блох. Если он в теме, как фиксить блоху - он ее фиксит, заливает в свой репо фикс, делает пулл-реквест в основной репозиторий. Если он не в теме, как фиксить - он скидывает репорт тому, кто в теме, тот фиксит, ответственный за сборку собирает... в общем по второму кругу. Сборкой вообще может машина заниматься, как, например, у XVM реализовано, найтлики, т.н.

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

Edited by GPCracker
  • Upvote 2

Share this post


Link to post

Short link
Share on other sites

ацки плюсую за установщик :no1:

 

но как сделать вот это IKFn9yE.png

т.е. переместить и зафиксировать превьюшку на новое место, чтобы за мышкой не бегала...

 

 

Share this post


Link to post

Short link
Share on other sites
1 час назад, tunut сказал:

т.е. переместить и зафиксировать превьюшку на новое место, чтобы за мышкой не бегала...

Скрипт отображения превьюшки переписать надо. Но мне пока не досуг этим заниматься - показывает и хорошо :-)

 

2 часа назад, GPCracker сказал:

Почему бы не хранить их в удобной для обоих групп манере - раздельно.

Основное правило нормального проекта - весь проект должен быть в ОДНОМ месте!

 

P.S. Давай закроем эту тему. :blinky:

Edited by ShuraBB
  • Upvote 2
  • Downvote 1

Share this post


Link to post

Short link
Share on other sites
13 minutes ago, ShuraBB said:

Основное правило нормального проекта - весь проект должен быть в ОДНОМ месте!

Раздельно - не значит в разных местах, как и в одном месте не означает вперемешку :) Но в одном ты прав - что-то мы сильно увлеклись. В любом случае, если на большинстве серьезных проектов чего-то принципиально принято не делать, скорее всего это результат либо личного опыта, либо опыта других серьезных проектов... :) Отсюда и понятия "bad-practice" и "best-practice".

Edited by GPCracker

Share this post


Link to post

Short link
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...