Ну у меня не персональное использование, и честно, лично я пользуюсь командной строкой даже в винде.
Черепах удобен виндузятникам просто потому, что они пересаживаются с TortoiseSVN, а потому им просто запомнить новые три буквы.
1) Плоская история. Отсутствуют merge коммиты вносящие какие-либо разрешения конфликтов.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.
При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.
Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
Основной плюс «массовых бранчей» — история мастера плоская, но при просмотре дерева истории сразу видно когда какой баг решался.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
У меня небогатый опыт работы с git, я встречал только ошибки двух типов — 1й «кто-то сделал фигню» и 2й «ты сам сделал фигню». В обоих случаях, проблема решалась через git reset --hard <коммит>.
Поэтому я не знаю, как надо восстанавливаться из ошибок :(
CVS сразу забыть как архивную, и сразу смотреть на SVN как хороший пример централизованной системы («старого типа» в моём понимании).
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
Чуть не забыл ответить на главное! «Особенно в контексте «зачем нужно руководству».»
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
К сожалению, в случае с SVN это не так. Для того, чтобы создать новую ветку, слить ветки, выгрузить версию, загрузить версию, на любой коммит — уходит время, причем довольно ощутимое даже в локальной сети — на каждый чих вычисляются диффы.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
Предполагается, что master ветку никогда не трогают с --force, причем это зарезано на уровне gitolite.
Инструкция, она для начинающих разработчиков, а не Tips & Tricks.
Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».
Я не знаю что делают вышеуказанные, из описаний выходит вот что они делают (пишу так, чтоб можно было в bash функцию положить):
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop
Черепах удобен виндузятникам просто потому, что они пересаживаются с TortoiseSVN, а потому им просто запомнить новые три буквы.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.
При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.
Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
После этого на SVN возвращаться не захочется.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
Поэтому я не знаю, как надо восстанавливаться из ошибок :(
При желании, можно добавить || случаи для «восстановление из ошибок».
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
Инструкция, она для начинающих разработчиков, а не Tips & Tricks.
Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop
таскать червя ради пары команд по очереди — бредятина.