Два года изо дня в день или там раз в неделю-месяц? А книжек по нему сколько (и по скольку раз каждую) прочли? (если чё - я не считаю нормальной ситуацию что для изучения VCS надо читать книги, с всякими там SVN "прочитать по ней книгу" мне даже в голову не приходило).
Лично для меня GIT это тот же Vi - инструмент для тех кому "шашечки а не ехать" - т.е. я даже не представляю через какое время усилия потраченые на его изучение окупятся (если вообще окупятся когда-то).
простота GIT сродни простоте CSS - может она упрощает жизнь кому-то - но точно не тому человеку который этой технологией пользуется. Выпишите тупо в столбик те термины которые нужно знать чтобы пользоваться GIT-ом и сравните с той же SVN - получите раз в несколько более длинный столбик. Да, внутреннее устройство GIT просто и даже элегантно - вот только отдельно взятому пользователю от этого ничуть не радостно - ему вообще без разницы должно быть как оно внутри устроено.
Я работаю с git уже года два, до этого со всяким SVN столько же: об SVN вспоминаю с ненавистью и содраганием. В базовых вещах git очень прост, команд надо знать не больше 10, в небазовых - согласен "танцы с бубном", ну а так и нет универсальных альтернатив в нетривиальных случаях.
Я отлично два года юзаю только commit, push и pull, в меркуриале.
В svn десять лет юзаю up и commit, иногда diff (когда почему-то хочу его посмотреть не в системе для code review и не в IDE), изредка resolve и merge. Знаю, конечно, больше, но это случайность и специфика. Например, та же propset огромному количеству людей не нужна совершенно.
init - это один раз, да и часто это тупо делается скриптом развёртывания рабочего места разработчика, тебе ничего делать не надо. В крайнем случае скопипастишь строчку из документации по проекту.
Гитом всерьёз не пользовался, поэтому статистики нет. Но пацаны пугают rebase и прочими страшными словами.
> Я отлично два года юзаю только commit, push и pull, в меркуриале.
Так не бывает.
Без up у вас не получится пуллиться Без merge не получится пуллиться с конфликтами Без stat вы будете забывать делать hg add (который я даже забыл включить - ещё remove, forget, copy и move)
Теперь 28 комманд получается. Вместе с blame, которую я тоже забыл, 29.
init и clone - один раз
теги и бранчи не нужны в малых и неэкспериментальных проектах, а в больших ими может заниматься специально обученный человек, равно как и трансплантологией.
Но меньше, чем commit, revert, stat, add, move, remove, push, pull, up, merge - это вряд ли.
Ну, допустим, удаление и переименование файлов нужно редко, ревертируете вы, используя undo в редакторе, свои диффы перед коммитом не ревьювите, всегда включаете все измененные файлы в коммит, а о том, кто какие файлы сейчас правит, сообщаете голосом соседям по проекту, так что конфликтов не бывает.
Все равно даже в такой луддитской обстановке нужны commit, add, push, pull и up.
Без stat легко, add, move etc - не нужны, если файловые операции делаются через IDE (в svn я тоже не пользуюсь этими командами).
Конфликты бывают, но редко, в меркуриале у меня не было конфликтов ни разу, ибо фронт работ очень чётко поделён. В svn за десять лет конфликт при коммите (точнее, при svn up) я видел раз двадцать, вряд ли больше. Опять же - организация работ и проекта. При мерже конфликтов, конечно, больше, но этим занимается отдельный человек (иногда это я, поэтому и записал resolve и merge).
Окей, пять команд насчитали.
В svn будет три - commit, add, up.
В гите, я так понимаю, будет тоже пять.
Если честно, уже успел забыть, с чего всё началось и что мы друг другу доказываем :)
> В базовых вещах git очень прост, команд надо знать не больше 10
Я доказываю, что в mercurial базовых команд тоже надо знать порядка 10, а именно 8. Всё зависит от того, что считать базовыми юскейсами и какие операции выполняются через фронт-энды.
В принципе можно пользоваться tortoisehg или аналогичным плагином к ide - черепашка совмещает pull + up и pull + merge в одну кнопку.
Можно так же совместить commit и push, если отказаться от возможности делать commit без push, что является сутью DVCS. Тогда и в меркуриале получится те же три логических операции, что и в svn: commit+push, add и pull + up/merge.
> пацаны пугают rebase и прочими страшными словами
Потребности у всех разные, и если не предпринимать специальных мер, начинаются рассуждения о "нинужности". Надо use cases описывать и сравнивать, как с ними разные сорс контролы справляются. Без use cases ерунда получится.
Например, достаточно типичная ситуация в опенсорсе, когда вы патчите проект, а потом надо переналожить ваш патч на новую версию апстрима и отправить новый патч в апстрим.
В связи с тем, что у апстрима нет времени рассматривать гигантский мердж, вам надо пересадить ваши три маленьких уникальных коммита на новую голову и предложить апстриму именно их. В hg это делает transplant, а в git требует аналогичной еботни с rebase.
Ну а SVN и иже с ним вообще подходит только для карманных разработок для команды из 2-3 человек, которые ещё и постоянно мержатся друг с другом. С git сравнивать вообще бессмысленно.
Интерфейс у git-а конечно ужасен, особенно та часть, где происходит работа с ветками.
Но это безальтернативный вариант только из-за github.
Reply
Reply
А книжек по нему сколько (и по скольку раз каждую) прочли? (если чё - я не считаю нормальной ситуацию что для изучения VCS надо читать книги, с всякими там SVN "прочитать по ней книгу" мне даже в голову не приходило).
Лично для меня GIT это тот же Vi - инструмент для тех кому "шашечки а не ехать" - т.е. я даже не представляю через какое время усилия потраченые на его изучение окупятся (если вообще окупятся когда-то).
Reply
Базовые вещи просты, небазовые, наверное, в любой системе будут нетривиальны?
Reply
Reply
В базовых вещах git очень прост, команд надо знать не больше 10, в небазовых - согласен "танцы с бубном", ну а так и нет универсальных альтернатив в нетривиальных случаях.
Reply
А в svn надо знать две, и иметь минимальное представление ещё о трёх.
В mercurial я пока что обхожусь тремя командами (использую его около двух лет).
Reply
По меркуриалу я помню:
Начало работы
hg init
hg clone path/uri
Кодинг
hg ci
hg revert [--no-backup]
hg rollback
hg stat [-dram]
hg diff [{rev}]
hg log [-l {revision_count}] [--template={template}]
Синхронизация
hg push
hg pull
hg up [-C] [{rev}]
hg merge [--tool=vimdiff]
hg resolve [--mark|--unmark]
Теги
hg tags
hg tag [-f] {tag}
Бранчи
hg heads
hg branches
hg ident
hg branch {tag}
hg push --new-branch
hg merge {rev}
hg ci --close-branch
Хирургия
hg transplant
Итого 24 команды, из которых ежедневно нужны 8: ci revert stat diff push pull up merge.
Reply
В svn десять лет юзаю up и commit, иногда diff (когда почему-то хочу его посмотреть не в системе для code review и не в IDE), изредка resolve и merge. Знаю, конечно, больше, но это случайность и специфика. Например, та же propset огромному количеству людей не нужна совершенно.
init - это один раз, да и часто это тупо делается скриптом развёртывания рабочего места разработчика, тебе ничего делать не надо. В крайнем случае скопипастишь строчку из документации по проекту.
Гитом всерьёз не пользовался, поэтому статистики нет. Но пацаны пугают rebase и прочими страшными словами.
Reply
Так не бывает.
Без up у вас не получится пуллиться
Без merge не получится пуллиться с конфликтами
Без stat вы будете забывать делать hg add (который я даже забыл включить - ещё remove, forget, copy и move)
Теперь 28 комманд получается. Вместе с blame, которую я тоже забыл, 29.
init и clone - один раз
теги и бранчи не нужны в малых и неэкспериментальных проектах, а в больших ими может заниматься специально обученный человек, равно как и трансплантологией.
Но меньше, чем commit, revert, stat, add, move, remove, push, pull, up, merge - это вряд ли.
Ну, допустим, удаление и переименование файлов нужно редко, ревертируете вы, используя undo в редакторе, свои диффы перед коммитом не ревьювите, всегда включаете все измененные файлы в коммит, а о том, кто какие файлы сейчас правит, сообщаете голосом соседям по проекту, так что конфликтов не бывает.
Все равно даже в такой луддитской обстановке нужны commit, add, push, pull и up.
Reply
Конфликты бывают, но редко, в меркуриале у меня не было конфликтов ни разу, ибо фронт работ очень чётко поделён. В svn за десять лет конфликт при коммите (точнее, при svn up) я видел раз двадцать, вряд ли больше. Опять же - организация работ и проекта. При мерже конфликтов, конечно, больше, но этим занимается отдельный человек (иногда это я, поэтому и записал resolve и merge).
Окей, пять команд насчитали.
В svn будет три - commit, add, up.
В гите, я так понимаю, будет тоже пять.
Если честно, уже успел забыть, с чего всё началось и что мы друг другу доказываем :)
Reply
> В базовых вещах git очень прост, команд надо знать не больше 10
Я доказываю, что в mercurial базовых команд тоже надо знать порядка 10, а именно 8. Всё зависит от того, что считать базовыми юскейсами и какие операции выполняются через фронт-энды.
В принципе можно пользоваться tortoisehg или аналогичным плагином к ide - черепашка совмещает pull + up и pull + merge в одну кнопку.
Можно так же совместить commit и push, если отказаться от возможности делать commit без push, что является сутью DVCS. Тогда и в меркуриале получится те же три логических операции, что и в svn: commit+push, add и pull + up/merge.
Reply
Потребности у всех разные, и если не предпринимать специальных мер, начинаются рассуждения о "нинужности". Надо use cases описывать и сравнивать, как с ними разные сорс контролы справляются. Без use cases ерунда получится.
Например, достаточно типичная ситуация в опенсорсе, когда вы патчите проект, а потом надо переналожить ваш патч на новую версию апстрима и отправить новый патч в апстрим.
В связи с тем, что у апстрима нет времени рассматривать гигантский мердж, вам надо пересадить ваши три маленьких уникальных коммита на новую голову и предложить апстриму именно их. В hg это делает transplant, а в git требует аналогичной еботни с rebase.
Reply
С git сравнивать вообще бессмысленно.
Reply
Reply
Reply
Leave a comment