Git против SVN Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[Litkevich Yuriy]

Тут можно потрепаться на эту тему.
Хотя впрочем преимущества Git'а для меня, УЖЕ, стали очевидны. Помимо самой, нормальной, идеи веток и меток. Обнаружил ещё одно существенное преимущество Git'а - компактность хранилища.

Есть у меня зеркало проекта AOS, весьма не рационально ребята там структуру организовали, в том числе и бинари там держат.

SVN-Зеркало весит = 544 649 КиБ
Его Git-клон весит = 144 680 КиБ
т.е. более чем в 3,5 раза меньше.

[Litkevich Yuriy]

в git'e это удобно сделано?

по сравнению с Git'ом в SVN'е это вообще никак не сделано.

на мой нынешний взгляд, SVN у Git' пока выигрывает за счёт интуитивного GUI, Git-gui и Git-tk довольно кривые и неуклюжие

а в чём особое удобство ветвлений в git?

попробую рассказать на примере.
Ветки существуют двух типов:
1) Ветка сопровождения
2) Функциональная ветка
Первая нужна для сопровождения минорных версий программы
Вторая - для эксперементов и т.д.

Теперь рабочий цикл по первому типу веток - Ветка сопровождения:
1) Принимается решение о выпуске новой версии программы, допустим v1.1.0
SVN:
a) trunk копируется в branches с новым именем v1.1.x - это ветка сопровождения;
b ) вновь созданный каталог branches/v1.1.x копируется в tags с именем v1.1.0 - это метка
c) фиксируются изменения в хранилище.
Итого имеем два дубля trunk'а (ну что-то там с экономится сожмётся..., это и так понятно)

GIT:
a) на текущем состоянии ветки master (аналог trunk) делается новая ветка (по сути получается пометка) именем v1.1.x - это ветка сопровождения;
b ) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.0 - это метка (в git'е, метка - просто именованное состояние)
Итого, ничего не фиксируется, только на каждое из перечисленных двух действий создаются служебные записи в хранилище (в Git'е оно локальное)

Идём дальше, исправление ошибок

Работаем над основной веткой (trunk/master).
Предположим, что приняли сообщение об ошибке в выпуске v1.1.0, от пользователя.
Нашли ошибку в ветке сопровождения, исправили. Далее:
SVN:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x)
2) копируем branches/v1.1.x в tags с именем v1.1.1 - это новая метка (предположим, что сразу выпускаем заплату не накапливая)
3) фиксируем изменения
4) сливаем текущее состояние ветки branches/v1.1.x в trunk (чтобы в главной ветке тоже было исправлено)

GIT:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x), с этого момента в хранилище появляется фактическая ветка которая содержит diff относительно точки ветвления
2) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.1 (это по прежнему просто именованное состояние)
3) ---
4) сливаем текущее состояние ветки branches/v1.1.x в master (чтобы в главной ветке тоже было исправлено)

Итого ручной работы минимум, дубликатов минимум, а слияние в Git'е более наглядное/интуитивное.
Плюс Git отслеживает не только перемещения файлов по каталогам, но и функций из одного файла в другой (когда такое обнаруживается можно увидеть соответствующую пометку вместо полного diff'а)

Теперь рабочий цикл по второму типу веток - Функциональная ветка:
Необходимо провести эксперимент, нужно создать ветку от главной
SVN:
1) trunk копируется в branches с новым именем foo - это функциональная ветка;
2 ) рабочая копия переключается на эту ветку (опционально, зависит от стратегии работы с рабочей копией)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, осуществляется слияние
5) фиксируются изменения
6) функциональная ветка удаляется за не надобностью
7) фиксируются изменения
Итого имеем уже не нужную ветку в истории хранилища (оно пухнет)

GIT:
1) на текущем состоянии ветки master (аналог trunk) делается новая ветка именем foo - это функциональная ветка;
2 ) рабочий каталог переключается на эту ветку (обязательно)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, переключают рабочий каталог на master
5) осуществляется слияние выбранной ветви (из списка ветвей) с master'ом (история правок самой функциональной ветви копируется при слиянии)
6) функциональная ветка удаляется за не надобностью
7) запускам сборщик мусора git gc, после этого удалённые ветви не востановить, т.к. они полностью удаляются из хранилища (опционально)
Итого, функциональные ветви, как коротко живущие можно полностью удалять из хранилища. А так как фнкциональные ветки явление частое и, можно сказать, основное, то они вносят наибольший вклад в вес.
Сверх того, отсутствие или перебои связи на твою работу вообще никак не влияют.