Исправление cherry_boy, (текущая версия) :
Спасибо, я в курсе методики принятия решений во многих конторах: ставится дедлайн «до конца недели», после дедлайна проходит два месяца - твоим решением до сих пор никто не пользуется. Вы ярмо себе повесили на годы, а всё потому, что кому-то показалось хорошей идеей за два дня принять решение при помощи людей, которые кроме Git и SVN ничего не знают.
Не драмазитируй, не в театре.
На Mercurial смотрели, но, так сказать, при прочих равных... С SVN переехали, т.к. там стали очевидными некоторые недостатки, которые для нас были критичными (в частности svn externals), а если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.
Да, я страдал из-за сложностей с поддержкой локальных правок в SVN. Но рак с переписыванием истории родом исключительно из Git - его нет больше нигде. Если так работать с Mercurial, то рано или поздно ты получишь вот это:
Тебе не приходило в голову, что проблемы, которых ты опасаешься, возникают не из-за Git, а из-за особенностей Mercurial и того, что вы эти особенности переносите на другие VCS?
Смотри: https://ibb.co/mB8wTFR. Утрированный пример на коленке, но примерно так и обстоят дела - по крайней мере с теми ветками, которые имеют историческое значение.
Законченные промежуточные этапы я коммичу локально.
Красавчик. У тебя посыпался винт, сгорел БП, уборщица унесла на закорках системник - твои правки недоступны. Сдохший диск, кстати - это из собственного печального опыта.
Хочу напомнить, что основная задача VCS - это хранение нескольких версий. В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано. Я просто срезаю путь, и не пользуюсь Git в данном сценарии с самого начала, начиная пользоваться им там, где мне действительно нужны версии. Одной фразой мой процесс можно описать как «я просто пишу код».
Каким образом он их теряет-то?
Rebase просто закидывает твои правки на самый верх, объединяя их с правками других разработчиков. Ну, допустим, смержишь ты их без него - конечный результат тот же, только правки не наверху, а разбросаны по времени.
Допустим, мержишь ты без squash - конечный результат тот же, но правки опять же размазаны по дереву.
Если принципиально хочется сохранить оригинальный стейт, то заведи еще одну локальную ветку до rebase, хотя единственный смысл, который я вижу в подобном действии - это «в моей ветке все работает, в мастере нет, вы виноваты сами», «смотри, я закоммитил у себя раньше, поэтому исправлять должен ты» или «работали вместе, коммитил он, пусть он и отвечает». Пардон, но в нормальном, адекватном коллективе такого говна быть не должно.
В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений, потому интернет в один голос советует делать «git stash; git stash apply; git checkout». Что снова возвращает нас к убогости Git для простых задач.
Еще раз: команда git checkout не сработает только тогда, когда версия какого-то из «грязных» файлов в текущей точке отличается от его версии в той точке, куда ты переключаешься. Причем она не потрет твои данные, не отформатирует жесткий диск, а напишет черным по белому или белым по черному, с какими конкретно файлами проблемы. Такое чувство, будто ты сейчас пересказываешь байки в духе «один мой товарищ слышал такую историю, дело, значит, было так...» Я даже начинаю сомневаться, что ты всерьез использовал Git, а не начитался страшилок в Интернете.
Поведение, кстати, вполне адекватное, я уже упомянул возможную ситуацию: предположим, я сделал правки в каком-то файле, а потом переключаюсь в старую ветку, где этот файл еще не создан. Ну и что делать с моими правками? Правильный ответ: лучше не держать их в воздухе, а коммитить, а то имея - не ценим, потерявши - плачем.
Незаконченная работа может растягиваться на месяца, и не ясно, куда она отправится - может быть вообще в мусорную корзину. Принцип Git: закоммить - потом все равно коммит будешь удалять. Принцип Perforce/Mercurial/SVN: коммить, когда этот коммит ты будешь использовать - то ли для локальной экспериментальной версии, то ли для создания ограниченной ветки для пары разрабов, то ли для общего релиза.
Если ты пишешь код, то он нужен как минимум тебе, прямо здесь и прямо сейчас, поэтому лучше коммитить. Окажется бесполезным - удалишь ветку или откатишь коммит, не окажется - закинешь в релиз. Если же ты работаешь с мыслью, что весь твой код потенциально бесполезен, то ты либо работаешь не там, либо не тем, кем следовало бы.
Я бы сказал, что разницы нет, если бы Git не оставлял разницы. Однако, Git не дает простых путей работаты с грязной репой, и, самое главное, Git дает шанс сломать репу неаккуратными действиями в процессе перекраивания бесполезных коммитов, поскольку в категорию бесполезных могут попасть полезные - помните, мы же превратили репозиторий в мусорник.
Да они не бесполезные, просто время их полезности ограничено. Вот строишь ты дом - нужны тебе строительные леса, построил дом - убрал их к чертовой матери.
История ревизий - не место для описания особенностей функционирования кода. Потому что человек, который позже будет работать с кодом, увидит код, а не будет листать историю ревизий по каждой строчке. По этой причине в описании ревизии должно быть только краткое описание изменений - только для того, чтобы просматривающий историю человек мог понять, какую ревизию он хочет выбрать.
Категорически не согласен. Если у коммита информативное описание, то есть высокая вероятность, что я еще на стадии его чтения пойму, заглядывать мне в этот коммит (т.е. разбираться в коде) или нет.
Исходная версия cherry_boy, :
Спасибо, я в курсе методики принятия решений во многих конторах: ставится дедлайн «до конца недели», после дедлайна проходит два месяца - твоим решением до сих пор никто не пользуется. Вы ярмо себе повесили на годы, а всё потому, что кому-то показалось хорошей идеей за два дня принять решение при помощи людей, которые кроме Git и SVN ничего не знают.
Не драмазитируй, не в театре.
На Mercurial смотрели, но, так сказать, при прочих равных... С SVN переехали, т.к. там стали очевидными некоторые недостатки, которые для нас были критичными (в частности svn externals), а если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.
Да, я страдал из-за сложностей с поддержкой локальных правок в SVN. Но рак с переписыванием истории родом исключительно из Git - его нет больше нигде. Если так работать с Mercurial, то рано или поздно ты получишь вот это:
Тебе не приходило в голову, что проблемы, которых ты опасаешься, возникают не из-за Git, а из-за особенностей Mercurial и того, что вы эти особенности переносите на другие VCS?
Смотри: https://ibb.co/mB8wTFR. Утрированный пример на коленке, но примерно так и обстоят дела - по крайней мере с теми ветками, которые имеют историческое значение.
Законченные промежуточные этапы я коммичу локально.
Красавчик. У тебя посыпался винт, сгорел БП, уборщица унесла на закорках системник - твои правки недоступны. Сдохший диск, кстати - это из собственного печального опыта.
Хочу напомнить, что основная задача VCS - это хранение нескольких версий. В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано. Я просто срезаю путь, и не пользуюсь Git в данном сценарии с самого начала, начиная пользоваться им там, где мне действительно нужны версии. Одной фразой мой процесс можно описать как «я просто пишу код».
Каким образом он их теряет-то?
Rebase просто закидывает твои правки на самый верх, объединяя их с правками других разработчиков. Ну, допустим, смержишь ты их без него - конечный результат тот же, только правки не наверху, а разбросаны по времени.
Допустим, мержишь ты без squash - конечный результат тот же, но правки опять же размазаны по дереву.
Если принципиально хочется сохранить оригинальный стейт, то заведи еще одну локальную ветку до rebase, хотя единственный смысл, который я вижу в подобном действии - это «в моей ветке все работает, в мастере нет, вы виноваты сами», «смотри, я закоммитил у себя раньше, поэтому исправлять должен ты» или «работали вместе, коммитил он, пусть он и отвечает». Пардон, но в нормальном, адекватном коллективе такого говна быть не должно.
В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений, потому интернет в один голос советует делать «git stash; git stash apply; git checkout». Что снова возвращает нас к убогости Git для простых задач.
Еще раз: команда git checkout не сработает только тогда, когда версия какого-то из «грязных» файлов в текущей точке отличается от его версии в той точке, куда ты переключаешься. Причем она не потрет твои данные, не отформатирует жесткий диск, а напишет черным по белому или белым по черному, с какими конкретно файлами проблемы. Такое чувство, будто ты сейчас пересказываешь байки в духе «один мой товарищ слышал такую историю, дело, значит, было так...» Я даже начинаю сомневаться, что ты всерьез использовал Git, а не начитался страшилок в Интернете.
Поведение, кстати, вполне адекватное, я уже упомянул возможную ситуацию: предположим, я сделал правки в каком-то файле, а потом переключаюсь в старую ветку, где этот файл еще не создан. Ну и что делать с моими правками? Правильный ответ: лучше не держать их в воздухе, а коммитить, а то имея - не ценим, потерявши - плачем.
Незаконченная работа может растягиваться на месяца, и не ясно, куда она отправится - может быть вообще в мусорную корзину. Принцип Git: закоммить - потом все равно коммит будешь удалять. Принцип Perforce/Mercurial/SVN: коммить, когда этот коммит ты будешь использовать - то ли для локальной экспериментальной версии, то ли для создания ограниченной ветки для пары разрабов, то ли для общего релиза.
Если ты пишешь код, то он нужен как минимум тебе, прямо здесь и прямо сейчас, поэтому лучше коммитить. Окажется бесполезным - удалишь ветку или откатишь коммит, не окажется - закинешь в релиз. Если же ты работаешь с мыслью, что весь твой код потенциально бесполезен, то ты либо работаешь не там, либо не тем, кем следовало бы.
Я бы сказал, что разницы нет, если бы Git не оставлял разницы. Однако, Git не дает простых путей работаты с грязной репой, и, самое главное, Git дает шанс сломать репу неаккуратными действиями в процессе перекраивания бесполезных коммитов, поскольку в категорию бесполезных могут попасть полезные - помните, мы же превратили репозиторий в мусорник.
Да они не бесполезные, просто время их полезности ограниченно. Вот строишь ты дом - нужны тебе строительные леса, построил дом - убрал их к чертовой матери.
История ревизий - не место для описания особенностей функционирования кода. Потому что человек, который позже будет работать с кодом, увидит код, а не будет листать историю ревизий по каждой строчке. По этой причине в описании ревизии должно быть только краткое описание изменений - только для того, чтобы просматривающий историю человек мог понять, какую ревизию он хочет выбрать.
Категорически не согласен. Если у коммита информативное описание, то есть высокая вероятность, что я еще на стадии его чтения пойму, заглядывать мне в этот коммит (т.е. разбираться в коде) или нет.