> То есть схема работы была следующая: такой-то функционал решено разрабатывать в
>отдельной ветке, создаётся бранч, ведётся разработка, затем 1м (!) коммитом вливается
>с меткой "мерджед бранч такая-то". Лично я чаще всего при
>этом вообще не использовал merge - делал дифф и накладывал на
>транк, с "ручным" добавлением новых файлов. Это похоже на последовательную разработку с "всегда стабильным стволом". Есть ещё параллельная разработка, в которой ветки могут развиваться одновременно. Ну и вливаться раньше или позже. Соответственно, оставшиеся ветки нужно приводить к стволовой ветке.
> То есть постоянного мерджа из ветки -> в транк -> в ветку -> в транк я ни разу и не видел. В данном случае одновременной модификации одного и того же кода действительно необходимо какой-то сценарий слияния, но это немного другая идеология разработки, вы не находите?
Да, многое зависит от идеологии и правил разработки. Иногда можно (и нужно) обойтись svn, иногда использование git предпочтительнее. Не буду спорить о вкусе устриц, но, думаю, есть ситуации, когда и mercurial предпочтительнее.
> И я правильно понял, что git rebase - это те же
>самые решения конфликтов, только в профиль?
Не только. Это довольно мощная операция. Она позволяет менять родительскую ветку (или стартовый коммит), позволяет менять коммиты в ветке.
http://www.kernel.org/pub/software/scm/git/docs/user-manual....
По ссылке рассказывается и показывается в псевдографике, что происходит при смене стартового коммита.
>насчёт:
>>Перестраиваем коммиты, ибо было туча промежуточных с отладкой (чтобы другие девелоперы ознакомились с мыслями и догадками)
> так ведь остались коммиты в бранче, зачем дублировать в транк? Лучше
>одним коммитом заливать, чтобы не было "я обновился когда ты не
>всё залил".
В гите операция слияния веток очень быстра и практически атомарна. Все операции с коммитами происходят локально у разработчика. Потом на сервер отсылается результат действий. Получается, что туча изменений происходит медленно у разработчика (подготовка изменений) и как бы моментально на сервере (применение изменений).
