Линус Торвальдс рассказывает про GIT

[yigal_s]

"Why did Hitler hate jews? Rabbi Yosef Tzvi ben Porat Explains How Hitler Was Right!" (Watch on YouTube)

Моё знакомство с SCM протекало странным путём через SourceSafe, ClearCase, ClearCase UCM, Perforce, Subversion. Последний (Subversion) освоил весьма поверхностно, зато именно на нём-то и почувствовал, как ужасно НЕПРАВИЛЬНО работал до этого. Апдейт рабочего пространства на ходу (с автоматическим, обычно незаметным мерджем файлов в "чекауте" по ходу дела), вообще отсутствие в SVN "чекаута", когда менять можно вообще любой файл - хоть и анархичный и опасный, но неожиданно весьма приятный мод работы. Не выяснял, можно ли достигнуть подобного быстрого апдейта в Perforce, во всяком случае, по умолчанию он работает иначе, превращая любой апдейт рабочего пространства в маленькое, но приключение, но по крайней мере, даже и в худшем случае можно то же самое сделать через простенький скрипт. В ClearCase, мне кажется, подобные апдейты файлов в чекауте вообще не поддерживаются - ибо концепт совершенно другой.

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

В чем я немедленно солидарен с Линусом (собтсвенно, об этом я уже года три назад писал) - что вся система организации Branches на CVS/SVN/Perforce абсолютно ужасна. В этом плане ClearCase для меня остается если не идеалом, то приятным воспоминанием, ну а что до GIT, то это, очевидно, совершенно неизвестный мне мир (я раньше почему-то думал, что он где-то концептуально является расширением SVN).

И еще в чем Линус очень прав - знакомство с подобными системами, постоянная работа с ними- определенным образом формирует восприятие вещей так, что никаких особых существенных альтернатив тому, с чем знаком, уже и не видишь. А они, оказывается, есть. )

Comments

[yatur.livejournal.com]

Кроме ГИТа есть еще меркуирал и еще парочка таких же децентрализованных, да. Плюс, по сравнению с SVN - он очень умный в плане мерджей. В SVN чуть изменишь структуру каталогов - и все, "tree conflict". А GIT сам разбирается что куда ушло.

Минус - слишком легко уйти "в отрыв" от остальной команды. Типа, сидишь в своем мире со своей локальной копией и полируешь ее, делая по 10 чек-инов в день. А потом опаньки: народ ушел вперед. С SVN так не получится - каждый чек-ин сразу идет на главный сервер.

[yigal_s]

Линус, кстати, эти системы тоже перечисляет и хвалит в своей презентации.

А что значит "легко уйти в отрыв"? Я могу и на своей ветке центрального сервера SVN ровно так же работать, а народ за это время проапдейтит главную ветку, почему нет? Принципиально в этом плане всё то же (если не вдаваться в свободы, связанные с децентрализацией)

Но если вы скажете, что просто разные стили работы и разные культуры, то я пойму )))

[yatur.livejournal.com]

Уйти в отрыв - значит долго работать в изоляции, не замечая, что твои изменения ломают чьи-то или наоборот.

В SVN чтобы уйти в отрыв, надо специально и сознательно создать branch, тем самым оформив "отрыв" документально. По умолчанию достаточно сделать чек-ин, чтобы "влиться" в общее русло. Даже если ты сам не сделал update, это за тебя сделает continuous integration server.

В GIT-е же ты по умолчанию сидишь в своей собственной "ветке". Чтобы твои изменения стали видны другим людям, надо делать двойное усилие - обычный чек-ин и потом "push" на корабль-матку. Это хорошо для больших проектов типа Линукса, но не очень хорошо для маленьких сплоченных команд. Если раньше достаточно было убедить каждого разработчика делать чек-ин хотя бы каждый день, то теперь их надо убедить не только делать чек-ин, но и пуш. Что в два раза сложнее.

Так что, разные культуры, да

[kot-begemot.livejournal.com]

Именно так. Плюс та необыкновенная лёгкость с которой в git делаются ребейзы приводит к тому, что некоторые особо одарённые идиоты только тем и занимаются, что правят историю.

[spamsink.livejournal.com]

Я не понимаю, с какой целью в git-е так лелеется разница между merge и rebase, ведь конечный результат один и тот же, а отличия лишь на графе версий.

[yigal_s]

а, ну действительно же, branching по умолчанию - довольно сурово.

Мы на ClearCase послали индивидуальный branching нафиг, например. Т.е. если кто-то хотел, он бы мог работать на branch, но по умолчанию человек десять работали на одной девелоперской ветке.