Пессимистичный по сравнению с оптимистичным параллелизмом (Блокирующий по сравнению с обратной связью)
Если говорить очень широко, в большинстве случаев для больших проектов IDE идея * заключается в том, чтобы не создавать сгенерированные файлы версий , поскольку они имеют тенденцию часто меняться, если не все время, и объединять / рассеивать их обычно не имеет смысла.
Вы версии ваш исходный код , и вы строите из него, генерируя любые артефакты, необходимые для запуска вашего приложения, вне контроля источника.
Файлы Unity, похоже, попадают в эту категорию. Вы можете найти источники в Интернете, есть разные руководства по эффективному использованию git в проектах Unity. Это один , недавно обновленный. И поиск здесь по SO по соответствующим тегам весьма плодотворен . Не стесняйтесь сравнивать различные настройки, чтобы выбрать то, что лучше всего подходит для вашего конкретного контекста.
Кроме того, на GitHub у вас есть это (спасибо derHugo за ссылку):
https://github.com/github/gitignore/blob/master/Unity.gitignore
Также полезно, добавлено после комментариев:
.gitignore официальный документ (вся страница полезна для чтения, но обратите особое внимание на " «форматы шаблонов» для настройки ваших собственных шаблонов)
полезный инструмент для проверки ваших шаблонов: git check-ignore
* (игра слов не предназначена)
3 ответа
Кажется, что Вы говорите о пессимистическом управлении оптимистичным параллелизмом стихов.
Оба широко используются, лично я нахожу оптимистичный параллелизм легче иметь дело с, но он будет зависеть от Ваших собственных требований и использования. Если редактирования (и потенциальные конфликты) распространены затем, пессимистическое управление совместным выполнением может быть соответствующим, в противном случае затем, оптимистичный параллелизм будет быстрее и более простым работать с.
Сообщите мне, хотите ли Вы видеть, что примеры кода используют тип данных RowVersion в SQL Server (это - то, что я в настоящее время использую), это довольно просто хотя:
- Все таблицы включают столбец RowVersion
- Все Запросы Select включают этот столбец (для данных, которые могут быть изменены),
- Все Запросы на обновление или Запросы на удаление включают ГДЕ RowVersion = @RowVersion. Это - оптимистическая часть, если 0 строк возвратились затем, кто-то еще коснулся строки, никакое обновление не происходит, поэтому скажите пользователю об этом.Примечание: Если бы строка была обновлена затем, то новое значение для RowVersion должно также быть возвращено. Это также относится к Запросам на вставку, во многом как Вы возвратил бы идентификатор столбца идентификационных данных после вставки.
Не уверенный, как описать форму простыми словами, но не общественная страница, это - одна вещь времени. Гипотетически, скажем, пользователь должен был соответствовать имени John, которого Делают DOEE одному из следующего John Doe Jon, После того как оно работало, редактирование завершено. В нашем случае нам не было бы нужно к простому
Полагая, что комментарий, я пошел бы с опцией 1. При полагании, что эти изменения являются изменениями времени, нет никакого преимущества для разрешения нескольким людям работать над тем же изменением. Вы только тратите впустую время 2-го человека.
Я лично пошел бы с опцией 2 - плюс, если там применимый (например, те редактирования находятся на более длинном тексте) делают обязанностью Пользователя B объединить редактирования. Дайте B инструмент, чтобы сделать так.