Исходное сообщение
"спасибо за ответ" Отправлено Вова, 30-Сен-09 15:37
Возможно мне везло с проджект-менеджерами, но на двух моих местах работы в качестве разработчика в команде, практически единственным местом, где возможны были конфликты транка и бранча были различные словари - хедеры с энумами, константами и тп; в затрагиваемых веткой исходниках  изменения были всегда несущественны, решать конфликты было более чем просто. То есть схема работы была следующая: такой-то функционал решено разрабатывать в отдельной ветке, создаётся бранч, ведётся разработка, затем 1м (!) коммитом вливается с меткой "мерджед бранч такая-то". Лично я  чаще всего при этом вообще не использовал merge - делал дифф и накладывал на транк, с "ручным" добавлением новых файлов.       То есть постоянного мерджа из ветки -> в транк -> в ветку -> в транк  я ни разу и не видел.  В данном случае одновременной модификации одного и того же кода действительно необходимо какой-то сценарий слияния, но это немного другая идеология разработки, вы не находите? И я правильно понял, что git rebase - это те же самые решения конфликтов, только в профиль? >svn merge r???:??? (тут игра в сапёра. Во-первых, не ошибиться бы с >номерами коммитов. Во-вторых, коммиты в ветке окажутся позади отмерженного) Действительно, надо знать номера ревизий, определять их по stop-on-copy опции. насчёт: >Перестраиваем коммиты, ибо было туча промежуточных с отладкой (чтобы другие девелоперы ознакомились с мыслями и догадками) так ведь остались коммиты в бранче, зачем дублировать в транк? Лучше одним коммитом заливать, чтобы не было "я обновился когда ты не всё залил".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: