k001
k001
:...

April 2032
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

k001 [userpic]
git-svn

А ведь работал кто-то с git-svn?

Правда ли, что после каждого git-svn fetch надо делать git-svn rebase -l?

Update: вопрос снят. В моём случае надо просто делать git-svn rebase.

Tags: ,
Comments

Ну, я же не про тебя и не про себя говорю - нам может гит и подойдёт легко, но ты если обычному человеку объясняешь что такое контроль версий и о том что люди параллельно работают и что есть ветки и метки, у них уже крыша в снос уходит - заставить их пользовать SVN уже сила, а гит они вообще не поймут ибо параллельные репозитории для них уже совсем уже непостижимо.

Я пытаюсь понять как заставить всяких Open Source (и не очень) девелоперов легкого веса (типа PHP / CSS / JS разработчиков) пользовать контроль версий и при этом иметь возможность настоящего оперсорса через git (когда всем кодом владеет тот кто его создает ну и прочие прюсы гита).

Ну и проблемы с UI под Винды, это тоже остонавливает - люди любят Tortoise SVN ибо вообще не любят задумываться о версиях кода - для них просто есть локальная копия и серверная и максимум что они пользуют, это diff, а всё остальное для них, это шаманизм. Мне же просто необходимы деревья версий и прочая фигня и я уже хочу нормальный merge, но без этих архаровцев мой труд бесполезен.

Я недавно писал, что пользоваться git легко. Вообще я никакой тут разницы не вижу, git или svn — команды примерно одинаковые. http://lj.rossia.org/users/k001/665228.html

Хотя, конечно, я совсем не в курсе насчёт гуёв. Но поверхностное гугление по слову tortoisegit даёт нам вона што: http://code.google.com/p/tortoisegit/

Похоже пора делать презентацию "git для веб-девелоперов" ;)

Главное, про бранчи, мержи и репозитории ничего не говорить :) Тогда по сути единственное отличие — необходимость явно делать git push и git pull в «главный» репозиторий (то, что он вовсе не главный, тоже не говорить!)

А чем для юзера отличается git push/pull от git checkout/commit?

То-есть, зачем ему checkout/commit если этого всё равно никто не увидит пока он push/pull не сделает? (я-то понимаю, что в этом весь кайф что можно версионировать то что ещё не дотестировано и этим убрать нервность по поводу качества и увеличить кол-во и частоту коммитов)

В принципе, можно написать списочек разделяющий плюсы версионирования на "свои" и "общие" - может это и будет иметь смысл в глазах юзеров...

> То есть, зачем ему checkout/commit, если этого всё равно
> никто не увидит, пока он push/pull не сделает?

Ну, для простого юзера это можно объяснить (а) скоростью и (б) возможностью автономной работы. Хотя там есть ещё всякие преимущества, например, у каждого есть полный бекап репозитория, это хорошо; но это для юзеров уже не очень актуально.

Скорость — это очень хорошо, это кайф, не надо ждать всякий раз, когда ты коммитишь, да и вообще все операции локально присходят куда быстрее, чем по сети (сравнить хотя бы cvs/svn log и git log). git вообще чрезвычайно быстрый, но этого особенно не замечаешь, когда переходишь, скажем, с svn на git — а вот когда обратно переходишь и всё ужасно тупит, вот это уже замечаешь очень хорошо!

Автономная работа — это не только когда в самолёте на ноуте чего-то фигачишь, это ещё и если вдруг центральный сервер накрылся (а такое раз в пять лет да случается — у нас на CVS сервере как-то разобрался RAID, день все отдыхали). Ну и да, можно спокойно коммитить и откатывать обратно, пока не запушил.

В принципе звучит продаваемо.

Нужно подумать как это обернуть для веб-девелоперов.

Не забудьте Tortoise-Git.