Исходное сообщение
"Язык программирования Go переходит с Mercurial на Git и GitH..." Отправлено Аноним, 15-Ноя-14 14:43
> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из > базовой функциональности git (см. комменты выше). А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж правильно и ничего при этом не сломать. Хоть там в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали иные люди. Которые понимают что это такое и как работает. И вполне можно сделать так что индивиду не придется ничего мержить пока он пилит свою фичу. А если индивид окажется не тyпым в техническом плане - можно обучить его основам и поднять эффективность взаимодействия с оным, aka получив возможность совместно работать над одними и теми же файлами. Но это катит только для текстовых файлов (как вы себе представляете мерж картинки со стороны VCS?) и не со 100% индивидов. > Какое может быть "позвать специалиста", Если человек не может делать мержи - его налет на нужду это делать должен стало быть исключением а не правилом. Это несколько лимитирует возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и может сделать взаимодействие менее приятным чем могло бы быть. > если синхронизировать с github'овским мастером нужно раз в день-два, > а разрабатывать свою ветку до pull-request'а неделю? :-) Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо часто синхриться и тем более что-то мержить. Они по идее вообще ни с кем конфликтовать не должны и если это случается - где-то в воркфлоу порылся нехилый косяк.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из >> базовой функциональности git (см. комменты выше). > А мне кажется наивным уповать на то что дизайнер или техпис может > сделать мерж правильно и ничего при этом не сломать. Хоть там > в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали > иные люди. Которые понимают что это такое и как работает. И > вполне можно сделать так что индивиду не придется ничего мержить пока > он пилит свою фичу. А если индивид окажется не тyпым в > техническом плане - можно обучить его основам и поднять эффективность взаимодействия > с оным, aka получив возможность совместно работать над одними и теми > же файлами. Но это катит только для текстовых файлов (как вы > себе представляете мерж картинки со стороны VCS?) и не со 100% > индивидов. >> Какое может быть "позвать специалиста", > Если человек не может делать мержи - его налет на нужду это > делать должен стало быть исключением а не правилом. Это несколько лимитирует > возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и > может сделать взаимодействие менее приятным чем могло бы быть. >> если синхронизировать с github'овским мастером нужно раз в день-два, >> а разрабатывать свою ветку до pull-request'а неделю? :-) > Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо > часто синхриться и тем более что-то мержить. Они по идее вообще > ни с кем конфликтовать не должны и если это случается - > где-то в воркфлоу порылся нехилый косяк.
	Введите код, изображенный на картинке: