Я с удовольствием буду иметь в наличии такую же инструкцию для Mercurial, если подготовите.
Ничего против hg не имею, кроме чуть меньшего удобства бранчей в нём.
Отчетность раз в год, через www.moedelo.org я его сдаю не отрывая Ж от рабочего места :)
Соцналоги перестают заботить начиная от ~45 в месяц — они упрятываются в 6% налогов.
В мастер слияние производит не автор кода, а ревьюер, который вычитывает и проверяет работоспособность кода. Если код основан не на последнем мастере, возможны конфликты которые надо будет решить в момент merge.
Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?
В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.
Например, мы делили апельсин поменяли все функции класса, добавив им в конце парметр (, Request=None).
Это изменение уже в мастере.
В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
Ну я проблему для себя решил — я вывожу на счет ИП. Если сумма выше килобакса суммарные потери (включая все траты на обналичку в рублях относительно ЦБРФ на день вывода) составляет чуть меньше 6.5%.
Ну у меня не персональное использование, и честно, лично я пользуюсь командной строкой даже в винде.
Черепах удобен виндузятникам просто потому, что они пересаживаются с 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.
Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».
Ничего против hg не имею, кроме чуть меньшего удобства бранчей в нём.
Соцналоги перестают заботить начиная от ~45 в месяц — они упрятываются в 6% налогов.
Как еще можно обновить код чтобы он соответствовал последнему мастеру, оставляя его в ветке, кроме «merge master» или «rebase master»?
В случае косички видно, что начинали делать относительно определённого кода, в момент слияния с мастером потребовались такие-то изменения.
В случае ребейза информация о том, что потребовался какой-то микрорефакторинг просто исчезает, так как она не является информативной.
Например, мы
делили апельсинпоменяли все функции класса, добавив им в конце парметр (, Request=None).Это изменение уже в мастере.
В ветке мы писали новый метод этого класса, причем начали писать до этого изменения.
Если мы мержим — у нас появляется доп коммит типа «add Request argument, as introduced in solution to bug #Y».
Если мы делаем rebase, мы напарываемся на конфликт в момент ребейза уже на самом первом коммите, добавляем прямо там этот аргумент, и делаем rebase continue.
На выходе — ветка, в которой этот аргумент _был изначально_. Тем самым, мы избавляемся от непонятного лишнего неинформативного коммита.
Черепах удобен виндузятникам просто потому, что они пересаживаются с TortoiseSVN, а потому им просто запомнить новые три буквы.
Это позволяет локализовать, отменять отдельные фичи и прочие вещи без создания дополнительных конфликтов.
2) Разрешение конфликтов самим разработчиком. Ты стартовал используя мастер от утра понедельника, сдаёшь в обед среды. За это время в мастере могло поменяться много чего. Ты сам производишь разрешение всех конфликтов в своём коде так, как будто ты только что в среду начал и сразу же сдал. Протестировав относительно самого последнего кода.
В целом, используя такой подход (сливать только чистые изменения), история проекта становится сухой и шелковистой.
При работе классическим образом, сливая просто ветки «как есть», процесс разрешения конфликтов либо падает на review'ера, либо история становится «косичкой» — сделали вилку из мастера в ветку A, потом слили в мастер ветку B, потом слили в A новый мастер, потом результат опять слили в мастер. Получается косичка, в которой не всегда ясно что откуда пришло и какое изменение создало проблемы.
Если история «плоская», всегда существует точка, которая вводит баг. И git bisect становится панацеей.
После этого на SVN возвращаться не захочется.
Основной плюс «пачки коммитов» — можно во-1х проследить логику разработчика (упрощает жизнь ревьюера), во-2х очень бегло смотреть на некоторые изменения типа «добавил в дерево готовый фреймворк», которые добавляют много файла, и мешают читать основной дифф.
Поэтому я не знаю, как надо восстанавливаться из ошибок :(
При желании, можно добавить || случаи для «восстановление из ошибок».
Git или Mercurial представители DVCS и по сути близки, о разнице между ними писали много в том числе на хабре.
Для себя я сделал выбор в сторону Git, но разницы с чем начинать жить нет никакой — изучение базовых команд занимает день, углубление в дебри идёт естественным путём в процессе по мере столкновения.
Руководству надо одно — чтобы процесс шел. Причем процесс шел лучше, чем был.
А инструкция — она для разработчиков, зачем это надо им.
В нашем случае, хранилище находится не в локальной сети на на серверах в Интернете (офисы децентрализованы и разбросаны по нескольким странам и городам), что добавляет еще бОльшие задержки.
Работая с DVCS этих задержек нет, любые изменения и телодвижения происходят без задержек.
Потери времени на переход на другую SCM были практически нулевыми — только на изучение инструкции, и сделать checkout нового репозитория в понедельник утром.
Разработчики они всё-таки умные люди, и потому сменить TortoiseSVN на TortoiseGIT не так сложно, а «лишние» телодвижение на создание ветки и ревью кода окупаются снижением ошибок в продакшене.
Инструкция, она для начинающих разработчиков, а не Tips & Tricks.
Исключительно из этих соображений я опустил моменты «выхода из самосозданной задницы».