Про аджайл я слышал, но не работал по нему, однако если мне не изменяет память, то есть ежедневные митинги, на которых каждый рассказывает, чем занимается сегодня.
Если все друг друга слушают, то выявить конфликт задач не составляет труда и поговорить до того как лок файла понадобится как инструмент разруливания конфликта.
И почему вы считаете, что человек с этой задачей справится лучше программы?
Если мы говорим о распределении задач, то для этого и существуют менеджеры разных звеньев со своей областью ответственности. Когда программы будут заниматься менеджментом лучше людей профессия исчезнет сама собой.
Мне кажется, что менеджмент ресурсов и задач — не та задача, которая решается системой контроля версий по определению. Поэтому вменять гиту, что в нем нету локов на файлы потому что менеджер не проследил за ситуацией или менеджера нет вообще — несколько странно.
Ставлю минус в комментарий за первый пункт.
Такие вопросы должны решаться тем, кто распределяет задачи по конкретным исполнителям а не системой контроля версий.
Чем должен заниматься человек, если он получил (или дошел) до задачи, требующей редактирования какой-нибудь конкретной модели, а файл залочен?
Второй пункт всегда в силе ибо время, деньги first to market.
1. Действительно ли нужно, чтобы несколько человек редактировали одну текстуру или модель одновременно? Чем это обусловлено?
2. Можно ли разбить текстуру или модель на логические куски и в случае модели иметь один файл, который бы через ссылки собирал все воедино?
С моей точки зрения, фичеветка должна быть влита в мастер с --no-ff — так получится, что в мастере будет один коммит приносящий фичу, а история сохранится для потомков.
Если одну и ту же текстуру или модель редактируют 2 и более человека одновременно, то это неправильная организация рабочего процесса или неправильное разделение на файлы.
Вопрос именно в этом проценте строк, которые поменялись. Если это 80% файла (например от старого остался только копирайт, а не поменяли уровни отступов), то уже не важно что было в прошлом — важно зачем это поменяли, что должно быть написано в самом коммите.
Начет криптолокеров: в случае с Git все нужно провернуть на абсолютно всех без исключения копиях репозитория и сервере через который происходит синхронизация. Только в этом случае будет потеряно все, включая историю изменений.
В случае с SVN — чтобы убить историю достаточно просто зашифровать сервер.
Довелось работать с SourceTree — в итоге использовал для запуска консоли.
Source Tree — относительно универсальная среда и поэтому не всегда пользуется терминологией гита, что при знании консольных комманд заставляет каждый раз задумываться, что происходит под капотом.
Мое личное мнение — для гита нужно использовать либо консоль, либо GUI написанный специально для него, чтобы «секретарши» говорили на одном языке с теми, кто GUI не пользуется.
Вероятно, я неверно выразился.
Скажем, компилятор проверяет можно ли «выбросить» переменную (в предположенни что она используется в данной области видимости, но не изменяется). Если переменную определить без «const» то придется просмотреть всю область видимости чтобы убедиться в возможности такого действия, в противном случае просматривать область видимости не придется (хотя это еще вопрос — надо же определить, что переменная не подвергается модификации).
Если все друг друга слушают, то выявить конфликт задач не составляет труда и поговорить до того как лок файла понадобится как инструмент разруливания конфликта.
Если мы говорим о распределении задач, то для этого и существуют менеджеры разных звеньев со своей областью ответственности. Когда программы будут заниматься менеджментом лучше людей профессия исчезнет сама собой.
Мне кажется, что менеджмент ресурсов и задач — не та задача, которая решается системой контроля версий по определению. Поэтому вменять гиту, что в нем нету локов на файлы потому что менеджер не проследил за ситуацией или менеджера нет вообще — несколько странно.
В моем текущем проекте меня больше волнует есть ли конкретный коммит в мастере, или его там нет.
Такие вопросы должны решаться тем, кто распределяет задачи по конкретным исполнителям а не системой контроля версий.
Чем должен заниматься человек, если он получил (или дошел) до задачи, требующей редактирования какой-нибудь конкретной модели, а файл залочен?
Второй пункт всегда в силе ибо время, деньги first to market.
Кодинг конвенции же существуют.
2. Можно ли разбить текстуру или модель на логические куски и в случае модели иметь один файл, который бы через ссылки собирал все воедино?
В случае с SVN — чтобы убить историю достаточно просто зашифровать сервер.
Source Tree — относительно универсальная среда и поэтому не всегда пользуется терминологией гита, что при знании консольных комманд заставляет каждый раз задумываться, что происходит под капотом.
Мое личное мнение — для гита нужно использовать либо консоль, либо GUI написанный специально для него, чтобы «секретарши» говорили на одном языке с теми, кто GUI не пользуется.
Скажем, компилятор проверяет можно ли «выбросить» переменную (в предположенни что она используется в данной области видимости, но не изменяется). Если переменную определить без «const» то придется просмотреть всю область видимости чтобы убедиться в возможности такого действия, в противном случае просматривать область видимости не придется (хотя это еще вопрос — надо же определить, что переменная не подвергается модификации).