Comments 41
1. > git checkout -b dovgBranch dovgBranch
не правильнее ли делать git checkout -b dovgBranch dovgBranch_branch? Тогда можно к remote branch обращаться через dovgBranch, а к локальной через dovgBranch_branch
2. --no-ff разве не надо добавлять всегда?
3. Пару раз сталкивался с проблемой, если не укажешь no-ff — он делает fast forward, а как откатить это непонятно. Ветка начинает смотреть в trunk или что-то типа этого. git svn info показывает в ветке trunk. Есть простой способ бороться с этими последствиями? Приходилось удалять — создавать ветку снова
не правильнее ли делать git checkout -b dovgBranch dovgBranch_branch? Тогда можно к remote branch обращаться через dovgBranch, а к локальной через dovgBranch_branch
2. --no-ff разве не надо добавлять всегда?
3. Пару раз сталкивался с проблемой, если не укажешь no-ff — он делает fast forward, а как откатить это непонятно. Ветка начинает смотреть в trunk или что-то типа этого. git svn info показывает в ветке trunk. Есть простой способ бороться с этими последствиями? Приходилось удалять — создавать ветку снова
А тебе часто приходится обращаться к удаленной ветке напрямую? :)
Про --no-ff согласен. Без него лучше ничего не делать, особенно когда дело касается git-svn. Сам пару раз так вляпывался. Решения, кстати, тоже не знаю.
Про --no-ff согласен. Без него лучше ничего не делать, особенно когда дело касается git-svn. Сам пару раз так вляпывался. Решения, кстати, тоже не знаю.
1. Согласен с коллегой. ИМХО обращаться к удаленной (remote) ветке нужно только при pull/push (dcommit), причем указывать ее явно. Это защитит от «коммитов не туда».
2. --no-ff нужно добавлять всегда, когда мержишь в master и работаешь с git-svn. При мерже из мастера в бранч он не нужен.
Про саму идею fast-forward вон здесь хорошо написано. habrahabr.ru/post/136847/
2. --no-ff нужно добавлять всегда, когда мержишь в master и работаешь с git-svn. При мерже из мастера в бранч он не нужен.
Про саму идею fast-forward вон здесь хорошо написано. habrahabr.ru/post/136847/
> А тебе часто приходится обращаться к удаленной ветке напрямую?
Часто. Например чтобы понять что реально уйдет в svn после мержа при dcommit. В принципе можно через remotes попробовать обратиться, но у меня почему-то remotes/trunk только по git branch -a видно, и autocomplete не срабатывает, надо видимо как-то колдовать.
Имхо иметь две ветки с одним названием не очень хорошо, разве там git не будет с ума сходить если к этим веткам надо как-то обратиться?
Часто. Например чтобы понять что реально уйдет в svn после мержа при dcommit. В принципе можно через remotes попробовать обратиться, но у меня почему-то remotes/trunk только по git branch -a видно, и autocomplete не срабатывает, надо видимо как-то колдовать.
Имхо иметь две ветки с одним названием не очень хорошо, разве там git не будет с ума сходить если к этим веткам надо как-то обратиться?
> разве там git не будет с ума сходить если к этим веткам надо как-то обратиться?
ИМХО если origin у вас один, то ничего страшного в одинаковом названии нет, т.к. нет конфликта.
Если originов несколько, то надо давать префиксы, чтобы понять с какого именно origin был снят local branch.
Это ИМХО, скорее вопрос религии как и codingStyle.
ИМХО если origin у вас один, то ничего страшного в одинаковом названии нет, т.к. нет конфликта.
Если originов несколько, то надо давать префиксы, чтобы понять с какого именно origin был снят local branch.
Это ИМХО, скорее вопрос религии как и codingStyle.
3 — вроде как git svn rebase это исправляет
*тут был вот этот комментарий*
Год просидел работая с git-svn. Потом все-таки замахался и перевели проект на git.
Выдержали ровно месяц на git svn, после чего волевым решением перевели небольшой (не ваши объемы, конечно) проект на гит. Очень уж много гемороя с этим свном и соединением его с гитом. :( Хотя, 158 проектов в одном репозитории — это круто. :)
Топик что надо. Как раз склоняю команду к переходу на git. Руководство не видит плюсов и не чешется… Я пообещал что после нового года начну работать через git-svn, и пусть они мне завидуют.
Имейте ввиду, что когда часть команды работает в svn, а часть через git-svn, то мержить должен кто-то один.
Если вы сделаете мерж из master в бранч средствами svn, а через некоторое время средствами git-svn, то почти гарантированно получите пачку странных конфликтов.
Удачи в переходе ;)
Если вы сделаете мерж из master в бранч средствами svn, а через некоторое время средствами git-svn, то почти гарантированно получите пачку странных конфликтов.
Удачи в переходе ;)
Да я в курсе, уже читал материалы на эту тему. Если меня память не изменяет то в случае когда в git репе делается новая ветка, а затем rebase и commit в git-svn то проблем быть не должно. Поправьте если я ошибаюсь.
Надеюсь что команда оценит удобство git и мы полностью на него перейдем. Правда это тоже не просто — у нас в репозитории всего 2 проекта, но уже ~ 15000 ревизий и пара тысяч тасков в redmine и jira.
Надеюсь что команда оценит удобство git и мы полностью на него перейдем. Правда это тоже не просто — у нас в репозитории всего 2 проекта, но уже ~ 15000 ревизий и пара тысяч тасков в redmine и jira.
А я вот при наличии времени хочу попробовать следующий трюк — завести git-репозиторий, куда будут дублироваться коммиты из svn, а push'ы будут уходить в svn. И можно будет наконец-то насладиться нормальной работой =)
Я в своё время (пока не перешли на git со StarTeam) делал так:
1. git репозиторий, дублирующий StarTeam
2 рабочие git репозиторий/репозитории
3. интеграционный git репозиторий (bare repository).
Делать push можно только в bare репозиторий, для этого нужен 3 (он как-бы имитирует общий git репозиторий, и рабочие репозитории живут в блаженном неведении об истинной системе контроля версий).
Не скажу, что это очень удобно, но всё равно на порядок лучше чем StarTeam
1. git репозиторий, дублирующий StarTeam
2 рабочие git репозиторий/репозитории
3. интеграционный git репозиторий (bare repository).
Делать push можно только в bare репозиторий, для этого нужен 3 (он как-бы имитирует общий git репозиторий, и рабочие репозитории живут в блаженном неведении об истинной системе контроля версий).
Не скажу, что это очень удобно, но всё равно на порядок лучше чем StarTeam
Спасибо, интересно было почитать. Давно подумываем о переходе на git, но коллега, который пробовал работать через git-svn пару лет назад, говорил, что он просто не смог осилить наш репозиторий. Возможно, что-то изменилось к лучшему.
Я правильно понял, что он выкачивает все содержимое проекта (trunk, ветки и теги)? Не знаю как у вас, а у нас за 10 лет жизни проекта их набралось такое количество, что, боюсь, он может и не осилить.
Я правильно понял, что он выкачивает все содержимое проекта (trunk, ветки и теги)? Не знаю как у вас, а у нас за 10 лет жизни проекта их набралось такое количество, что, боюсь, он может и не осилить.
Да, он выкачивает все, но только один раз. Потом обновляет только инкремент, если может понять ветвления.
По поводу объема:
Ревизий почти 90 000.
Главное дождаться первого fetch, потом всё будет быстро.
По поводу объема:
du -ch plus1 | tail -1
1,1G итого
git branch -a | wc -l
1395
Ревизий почти 90 000.
Главное дождаться первого fetch, потом всё будет быстро.
Можно ограничить число выкачиваемых ревизий специальным ключом.
Можете попробовать SubGit, это такая альтернатива git-svn. Работает на сервере, автоматически синхронизирует SVN и Git репозитории с помощью hook'ов, которые вызываются на каждый commit и push. Поскольку синхронизация происходит на сервере, то пользователи могут использовать любой SVN или Git клиент.
Сразу скажу, что SubGit — это коммерческий продукт, и я один из его разработчиков. Если интересно, могу написать отдельный пост по этой теме.
Сразу скажу, что SubGit — это коммерческий продукт, и я один из его разработчиков. Если интересно, могу написать отдельный пост по этой теме.
Я с ужасом вспоминаю времена, когда наша команда использовала git-svn.
У нас расклад был такой: над продуктом работало две команды. Одна команда работала с SVN, а наша команда работала в git. Для этого мы себе склонировали репозиторий, положили его в gitorious и каждый пушил в него. Периодически кто-нибудь из команды эти репозитории синхронизировал с помощью git svn dcommit.
Из-за того, что Git и SVN концeптуально разные, мы наступили на грабли:
Грабли №1
Все коммиты из Git репозитория уходят в SVN репозиторий от имени того, кто запусткает git svn dcommit. После этой операции git-svn пересоздает локальный master бранч и забирает туда коммиты из SVN. В результате все авторы коммитов заменяются одним.
Гарбли №2
Мержи в SVN и в Git реализованы по-разному. По-этому git-svn перед тем как коммитить в SVN, «распрямляет» мержи с помощью rebase. В результате все мержи идут лесом, и приходится руками резовить конфликты.
В результате оказалось, что единственная работоспособная схема — это когда каждый клонирует себе SVN репозиторий и не использует мержи.
Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
У нас расклад был такой: над продуктом работало две команды. Одна команда работала с SVN, а наша команда работала в git. Для этого мы себе склонировали репозиторий, положили его в gitorious и каждый пушил в него. Периодически кто-нибудь из команды эти репозитории синхронизировал с помощью git svn dcommit.
Из-за того, что Git и SVN концeптуально разные, мы наступили на грабли:
Грабли №1
Все коммиты из Git репозитория уходят в SVN репозиторий от имени того, кто запусткает git svn dcommit. После этой операции git-svn пересоздает локальный master бранч и забирает туда коммиты из SVN. В результате все авторы коммитов заменяются одним.
Гарбли №2
Мержи в SVN и в Git реализованы по-разному. По-этому git-svn перед тем как коммитить в SVN, «распрямляет» мержи с помощью rebase. В результате все мержи идут лесом, и приходится руками резовить конфликты.
В результате оказалось, что единственная работоспособная схема — это когда каждый клонирует себе SVN репозиторий и не использует мержи.
Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
>Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
У нас одна команда разработки, т.е. описанные проблемы нас не коснулись.
Единственное о чем я писал выше — мержить должен кто-то один. Или средствами svn или средствами git. В нашей уютненькой компании — это совершенно не проблема.
Нашего опыта явно недостаточно чтобы подтвердить наличие проблем. При этом я нисколько не сомневаюсь, что они есть и при использовании инструмент следует их учитывать.
У нас одна команда разработки, т.е. описанные проблемы нас не коснулись.
Единственное о чем я писал выше — мержить должен кто-то один. Или средствами svn или средствами git. В нашей уютненькой компании — это совершенно не проблема.
Нашего опыта явно недостаточно чтобы подтвердить наличие проблем. При этом я нисколько не сомневаюсь, что они есть и при использовании инструмент следует их учитывать.
Если честно, я в принципе не понимаю как вы делаете мержи. У нас это делать не получалось. Git-svn из них делал одну ветку с помощью ребейза. Более того, ман git-svn(1) явно говорит:
it cannot yet represent merge history that happened inside git back upstream to SVN users. Therefore it is advised that users keep history as linear as possible inside git to ease compatibility with SVN
Running git merge or git pull is NOT recommended on a branch you plan to dcommit from because Subversion users cannot see any merges you’ve made.
Если в двух словах, то так:
Обратно — аналогично.
svn такие мержи не понимает, это да. Поэтому я и говорю, что мержить должен кто-то один. Если начали мержить гитом, то до вливания в master (trunk) нужно продолжать мержить им же.
git co -b branchName branchName && git svn rebase && git merge --log --no-ff master && git svn dcommit
Обратно — аналогично.
svn такие мержи не понимает, это да. Поэтому я и говорю, что мержить должен кто-то один. Если начали мержить гитом, то до вливания в master (trunk) нужно продолжать мержить им же.
Почему-то уже на «Плюс в том, что централизация дает возможность, например, нумеровать коммиты, т.к. их порядок известен» возникают вопросы :) А в чем плюс нумерованных коммитов? Что мешает завести в git bare репозиторий который будет «центральным»?
Если бы мы выбирали сейчас, то точно выбрали бы git.
git-svn — это решение, которое позволяет ничего не менять для тех, кто менять ничего не хочет, но при этом использовать плюсы git тем, кто в них нуждается.
git-svn — это решение, которое позволяет ничего не менять для тех, кто менять ничего не хочет, но при этом использовать плюсы git тем, кто в них нуждается.
> А в чем плюс нумерованных коммитов?
Версию файла можно указать в нем самом (может полезно при сравнении разных файлов) + номер коммита удобно использовать в качестве номера build-а. Хотя, возможно, и в git-е есть что-то подобное svn:keywords?
Версию файла можно указать в нем самом (может полезно при сравнении разных файлов) + номер коммита удобно использовать в качестве номера build-а. Хотя, возможно, и в git-е есть что-то подобное svn:keywords?
номер коммита удобно использовать в качестве номера build-а
Не очень удобно, особенно когда в одном репозитории живет много проектов. Продвинутые системы сборки (ex: jenkins) умеют сами нумеровать билды.
В гите есть теги
Если не зацикливаться на том, что версия — это обязательно номер и достаточно регулярно ставить теги, то git describe --tags выдаёт разумный вывод.
di = diff --colorнаверное лучше так:
[color]
ui = true
Имхо, лучше 1 раз грохнуть всю историю (и копаться в архивах когда надо), чем терпеть это всё
Чтобы не было адских мерджей в SVN дробите задачи на более мелкие чтоб быстрее их коммитить. В идеале надо стремиться к работе без длинных бранчей. К сожалению не всегда это возможно, в принципе, но максимально уменьшить количество длинных веток как правило можно.
Мой workflow
Беру из svn:
> git co master
> git svn rebase
> git co my
> git rebase master
Коммичу в svn:
> git co master
> git rebase my
> git svn dcommit
> git co my
> git rebase master
> git co master
> git svn rebase
> git co my
> git rebase master
Коммичу в svn:
> git co master
> git rebase my
> git svn dcommit
> git co my
> git rebase master
Много букв, но суть проста:
* все изменения в my,
* master всегда на git-svn,
* и постоянные rebase'ы.
Единственная проблема, с которой столкнулся — при выполнении git svn dcommit нужно на всякий случай иметь два HEAD'а, указывающие на рабочую ветку, потому что если dcommit обломится (например, на залоченном файле), то текущая ветка будет испорчена. Поэтому я при коммите делаю rebase master'а на my, и коммичу master. Если master испортится, делаю reset на my.
Выбор между svn и git, в основном, основывается на том, надо ли централизованный и децентрализованный репозиторий. Если комманды сидят постоянно в офисе, все разработки ведутся относительно централизовано — то лучше и репозиторий выбирать централизованный (svn). Если разработчики вынуждены работать децентрализовано (например путешествуют), то лучше выбирать гит. По опыту (и комментариям выше) гибридные svn<->git работают глючно на реальных, больших и сложных проектах.
Sign up to leave a comment.
how to: Как и зачем работать с svn через git