Исправление cherry_boy, (текущая версия) :
Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.
Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать.
В Mercurial точно так же можно тереть ветки и перебазировать изменения, просто тогда рабочий цикл по сложности приближается к Git, с шансом накосячить и потом сидеть перекраивать репу.
Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?
Есть куча автоматических форм резервирования, которые позволяют обезопасить данные, не трогая программиста: RAID-массив, автоматические проги создания удаленной резервной копии. Лично у меня два раза умирал винт, и ни разу я не терял больше дня работы. Подбор уборщиц в айтишные конторы — это весьма больная тема, некоторые вообще предпочитают уборщиц не пускать, а как в армии — заниматься уборкой самостоятельно.
Замечательно. У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду.
По-моему, это у тебя нет нормального понимания, зачем тебе нужна VCS, раз ты выдумываешь костыли на рабочем месте, решая проблему, которая уже решена. Да и зачем тебе RAID? Вдруг написанный тобой код окажется бесполезным - сразу в топку его, сэкономишь итерации.
Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.
Собственно, для того же, для чего и тебе.
Вот буквально месяц назад у нас была трудноуловимая бага, которую можно было поймать на последнем релизе, но нельзя было вопроизвести три релиза назад. Я посмотрел разницу между двумя релизами, на что-то обратил внимание сразу (спасибо информативным описаниям коммитов), потом еще погонял бисект, нашел еще связанную проблему, исправил. Все то же самое.
Сейчас я наконец убедил команду развернуть Дженкинс и смогу в таком случае вообще использовать daily builds, т.к. , буду знать, откуда они собраны. А все почему? Потому что история в релизных ветках и вообще ветках, которые будут использоваться для сборок (e.g. master), история никогда не переписывается, и никто в здравом уме ее переписывать не станет.
Я вживую Mercurial не использовал, поэтому не в курсе, как там точно все устроено, но у меня есть подозрение, что твои переживания вызваны его особенностями и что там от rebase в сторонней ветке действительно вся репа поедет по одному месту. Тем не менее, это нюансы Mercurial, Git тут не при чем, повторюсь.
git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.
Во-первых, это кейс, отличный от того, который мы обсуждали (уточнял в самом начале). Я понимаю, что ты все-таки решился прочитать документацию, но переобуваться не комильфо.
Во-вторых, нет, не revert. Эта команда приводит файл к состоянию на указанной ревизии, и только если ревизия не указана, то используется текущий HEAD. Довольно удобная вещь, кстати.
В-третьих, она делает ровно то, что написано в документации. Если в другой системе версий такая команда работает тоже по-другому, то это в общем-то ничего не значит, если только мы не начинаем рассматривать «в Mercurial иначе, а потому Git плохой» как аргумент. Но мы не станем.
И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.
Без понятия, кем ты работаешь - может, и дворником, но ощущение, будто Git использовал постольку-поскольку и гуглишь сейчас статьи «git vs hg» или «why git is so bad». Знаешь,я могу еще аргументов подкинуть: ну, например, в Git-сообществе merge requests принято называть pull requests - вот ведь сволочи, делают все, чтобы запутать честного человека.
Исходная версия cherry_boy, :
Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.
Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать.
В Mercurial точно так же можно тереть ветки и перебазировать изменения, просто тогда рабочий цикл по сложности приближается к Git, с шансом накосячить и потом сидеть перекраивать репу.
Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?
Есть куча автоматических форм резервирования, которые позволяют обезопасить данные, не трогая программиста: RAID-массив, автоматические проги создания удаленной резервной копии. Лично у меня два раза умирал винт, и ни разу я не терял больше дня работы. Подбор уборщиц в айтишные конторы — это весьма больная тема, некоторые вообще предпочитают уборщиц не пускать, а как в армии — заниматься уборкой самостоятельно.
Замечательно. У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду.
По-моему, это у тебя нет нормального понимания, зачем тебе нужна VCS, раз ты выдумываешь костыли на рабочем месте, решая проблему, которая уже решена.
Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.
Собственно, для того же, для чего и тебе.
Вот буквально месяц назад у нас была трудноуловимая бага, которую можно было поймать на последнем релизе, но нельзя было вопроизвести три релиза назад. Я посмотрел разницу между двумя релизами, на что-то обратил внимание сразу (спасибо информативным описаниям коммитов), потом еще погонял бисект, нашел еще связанную проблему, исправил. Все то же самое.
Сейчас я наконец убедил команду развернуть Дженкинс и смогу в таком случае вообще использовать daily builds, т.к. , буду знать, откуда они собраны. А все почему? Потому что история в релизных ветках и вообще ветках, которые будут использоваться для сборок (e.g. master), история никогда не переписывается, и никто в здравом уме ее переписывать не станет.
Я вживую Mercurial не использовал, поэтому не в курсе, как там точно все устроено, но у меня есть подозрение, что твои переживания вызваны его особенностями и что там от rebase в сторонней ветке действительно вся репа поедет по одному месту. Тем не менее, это нюансы Mercurial, Git тут не при чем, повторюсь.
git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.
Во-первых, это кейс, отличный от того, который мы обсуждали (уточнял в самом начале). Я понимаю, что ты все-таки решился прочитать документацию, но переобуваться не комильфо.
Во-вторых, нет, не revert. Эта команда приводит файл к состоянию на указанной ревизии, и только если ревизия не указана, то используется текущий HEAD. Довольно удобная вещь, кстати.
В-третьих, она делает ровно то, что написано в документации. Если в другой системе версий такая команда работает тоже по-другому, то это в общем-то ничего не значит, если только мы не начинаем рассматривать «в Mercurial иначе, а потому Git плохой» как аргумент. Но мы не станем.
И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.
Без понятия, кем ты работаешь - может, и дворником, но ощущение, будто Git использовал постольку-поскольку и гуглишь сейчас статьи «git vs hg» или «why git is so bad». Знаешь,я могу еще аргументов подкинуть: ну, например, в Git-сообществе merge requests принято называть pull requests - вот ведь сволочи, делают все, чтобы запутать честного человека.