Используйте локальный репозиторий Мерзавца с основным репозиторием Подрывной деятельности
Решение является неправильным. В JavaScript,
null == undefined
возвратит true, потому что они оба являются "литыми" к булевской переменной и являются ложью. Корректный путь состоял бы в том, чтобы проверить
if (something === undefined)
, который является оператором идентификационных данных...
4 ответа
Вы можете использовать что-то вроде этого руководства в качестве отправной точки. Я также прочитал это руководство .
В этом режиме работы есть несколько подводных камней. Самым важным является то, что вы не можете использовать svn версии 1.5 mergeinfo и ожидать, что это сохранится через git. Это серьезный недостаток, если вы используете (возможно, довольно приличную) функциональность слияния svn 1.5.
На странице руководства для git-svn также есть некоторые примечания под «предостережениями» в том разделе, который вы должен понимать. Как только я понял все предостережения, я понял, что преимущества использования этой установки будут меньше, чем фактическая стоимость для моего конкретного случая.
Одно из решений, которое я бы попробовал:
- Оформить заказ из центрального репо с использованием SVN
- git init для создания локального репо
- добавить .svn в .gitignore
- git add *, чтобы добавить все файлы в локальное репо
- Выполняйте все ваши промежуточные ветки / коммиты / откаты в git.
- Когда вы закончите, выполните фиксацию обратно в центральное репо, используя SVN.
Я думаю, что лучший вариант использования git-svn - это если вы вынуждены работать с центральным репозиторием svn, но хотели бы лично работать с git. Или, возможно, большинство людей в команде сейчас чувствуют себя более комфортно, работая с svn. Используя git-svn, вы не потеряете историю коммитов, сделанных в локальном репозитории git.
Если вы настраиваете новый репозиторий с нуля и / или имеете свободу выбора, я бы выбрал один или другой. git-svn работает хорошо, но вы всегда будете бороться с «несоответствием импеданса» между двумя системами.
Если вы хотите реализовать просто централизованную модель, то в качестве центрального репозитория можно использовать общедоступный репозиторий git. . См. Раздел в руководстве пользователя Git о настройке общего репозитория .
Предположим, ваше репо SVN находится на svn + ssh: // username @ svn _server / svn / your_repo
и ваш репозиторий SVN имеет "правильный" макет (ствол, ветки, теги)
Вот рабочий процесс, который я использую уже несколько месяцев:
1. ' mkdir your_repo '
2. ' cd your_repo '
3. ' git svn clone -s svn + ssh: // username @ svn _server / svn / your_repo. ' (обратите внимание на точку)
4. [подождите, в зависимости от размера вашего репозитория :)]
теперь ваш «мастер» GIT отслеживает магистраль SVN
вы также можете создать ветку отслеживания, как обычно делаете с git, если вы работаете над какой-либо веткой
5. традиционный hack hack
6. обновите свой клон с помощью ' git svn fetch && git svn rebase '
7. «протолкните» свои изменения в svn с помощью ' git svn dcommit '
Другие полезные вещи
Определите следующие удобные псевдонимы в вашем .gitconfig:
1. Псевдоним ' spull ', который означает svn-pull, например: ' spull =! Git svn fetch && git svn rebase '
2. Псевдоним « spush », который означает svn-push, например: « spush =! Git svn dcommit »
Эти псевдонимы делают рабочий процесс более эффективным:
clone / hack hack / spull / spush -> profit
svn: externals
I couldn ' Я не нашел для этого хорошего решения в Интернете, поэтому сделал его сам :)
http://github.com/sushdm/git_svn_externals он еще не идеален, но определенно должен сделать жизнь намного проще.
У меня работает отлично, надеюсь, вам поможет.