Комментарии 10
Спасибо за полезную информацию. Никогда толком не мог понять, какой именно коммит принимается за Base, а информация на эту тему достаточно расплывчата.
+2
Не знал, что git делался как фреймворк. Это многое объясняет :) Мне кажется, что git цепляет людей именно своей гибкостью и низкоуровневостью. Мне иногда сложно объяснить людям почему стоит использовать git а не svn к примеру, но чисто субъективно после длительной работы с git-ом, все остальное кажется крайне неудобным, хотя вроде бы позволяет настроить вполне нормальный workflow, но чего-то всегда не хватает.
+6
НЛО прилетело и опубликовало эту надпись здесь
Не знал, что git делался как фреймворк.
Аналогично. После этих слов в статье даже зазудило где-то внутри: «ты должен создать свой, самый правильный VCS на основе этого фреймворка». К счастью, от этого зуда удалось избавиться.
0
А все же чем вас git-svn не устроил? Он ведь поддерживает ветвление. Да и работает достаточно шустро даже для больших svn-репозиториев. Я им конвертировал репозиторий с двенадцатилетней историей и все замечательно отработало.
0
Я пришел на работу, когда от git svn уже почти ничего не осталось, но я постараюсь вам ответить то, что знаю :). Основная проблема с git-svn в том, что он является прослойкой между git и SVN, по сути являясь переносчиком коммитов между системами контроля версий. Вы должны иметь 2 системы контроля версий и понимать, что вы делаете, причём SVN является явно лишней и менее гибкой. Поскольку для поддержки ветвления всё равно нужно переписывать всю систему выкладки, мы переписали её, избавившись от SVN совсем (и от его «наследия» в виде отсутствия возможности ветвления). По сути, с новой системой необходимость в SVN полностью отпала, поэтому git-svn тоже был выпилен.
+3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внутреннее устройство Git: хранение данных и merge