Здравствуйте, Константин, Вы писали:

К>Здравствуйте, dmitry_npi, Вы писали:

_>>Сразу скажу — хотелось бы обойтись без священных войн.


К>Думаю, что проблема в том, что вы перешли на Git не потому, что почувствовали внутреннюю необходимость, а потому, что это "модно". И коллега вас, видимо "кинул". Раз он инициатор перехода, то и отвечать, и помогать остальным нужно ему.

К>Попробую описать несколько сценариев, когда git удобен. Если никогда не было внутренней потребности в сценариях такого типа, то git, bla-bla-bla ... вам не нужен

К>1. Я делаю изменение, которое естественно дробится на несколько логических частей
К>- Во время работы делается несколько локальных коммитов
К>- Пока не сделан push, я царь и бог: эти коммиты можно поменять (и даже удалить, поменять местами слить вместе, раздробить), если локальное тестирование нашло ошибку
К>- Перед push'ем ещё раз просматриваю коммиты, причёсываю (текст, мелочи) и делаю push

К>2. Я работаю над несколькими небольшими фичами / небольшими экспериментами / hotfix'ами в одной рабочей копии
К>- Делаю checkout фиче-ветки. Для небольших фич это почти мгновенно. Поработал, закоммитил. Отложил на время, или за-push'ил, если всё ok
К>- Переключился на основную ветку (или другую фиче-ветку)

К>Это 2 сценария, под которые git заточен блестяще. Основные идеи простые, и становятся понятными после прочтения вменяемого tutorial/книги.
К>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.

Здравствуйте, Константин, Вы писали:

К>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.