как синхронизировать репозитории git-svn - PullRequest
4 голосов
/ 15 марта 2011

Я использую git-svn в течение последних трех недель.

В настоящее время мой рабочий процесс выглядит следующим образом.

  1. ssh в моей разработкеbox,
  2. создавать / редактировать / удалять файлы там (git svn rebase, git checkout -b ветка темы)
  3. проверять, нормально ли работает веб-приложение.
  4. коммит вsvn. (мастер git rebase, мастер git checkout, ветка git merge, git svn dcommit)

Проблемы

  1. этот рабочий процесс очень простдля быстрого редактирования на панели разработчика (ssh).Но так как удаленное редактирование со временем замедляется, оно становится трудным.
  2. Примечание: я не могу установить точную копию моего веб-приложения на локальном компьютере (так как он извлекает данные из различных источников и множество другихконфигурации)

Я хочу, чтобы редактировать файлы локально, перемещать файлы на сервер, тестировать, фиксировать.

Чтоможет быть хорошим рабочим процессом для этого?

Мои предыдущие попытки включают

  1. локальное редактирование файлов, scp-файлы, test, dcommit
  2. локально редактировать файлы, rsync с dev box, test, dcommit
  3. редактировать файлы локально, git push to dev box, test, dcommit (git pull из локального ящика в dev dev не возможен, потому что локальный ящик находится за маршрутизатором)

Я не пробовал последний шаг, так как git-svn упоминает, что вставлять / извлекать / объединять из другого репозитория git опасно, если вы используете git-svn.

Можете ли вы предложить эффективный рабочий процесс с примерами команд?

Спасибо

Ответы [ 2 ]

3 голосов
/ 15 марта 2011

Возможно, я что-то упустил, но я думаю, что предупреждения в документации git svn не относятся к рабочему процессу, который я предлагаю ниже. (Я предполагаю, что вы счастливы только git svn dcommit из коробки разработчика, кстати.)

  1. Клонируйте репозиторий из своего окна разработки на локальный компьютер. Предположим, что вы создаете новую ветку темы локально с именем excellent. Вы работаете над этой новой веткой.

  2. Теперь вы хотите протестировать его на устройстве разработки, но чтобы избежать проблем с загрузкой в ​​не-пустое хранилище, вы можете использовать методику , предложенную в git FAQ , где вы нажимаете напрямую до ссылки под refs/remotes/. Например, вы можете сделать:

    git push origin excellent:refs/remotes/from-desktop/excellent
    
  3. Теперь вы должны войти в окно разработчика. Затем вы можете создать новую ветку на основе ссылки, которую вы только что нажали с git checkout -b excellent from-desktop/excellent

  4. Вы можете работать с этой веткой так же, как и с веткой темы в своем примере, и, если вы довольны ею, убедитесь, что вы все еще делаете ту же последовательность, прежде чем выполнять git svn dcommit, т.е. git rebase master, git checkout master, git merge excellent, git svn dcommit

Я не понимаю, почему этот рабочий процесс создает проблемы с git svn, так как вы стараетесь перебазировать свою работу и объединить ее с master перед выполнением git svn dcommit.

1 голос
/ 15 марта 2011

Я использую рабочий процесс, который инвертирован из вашего, и он работает хорошо.

Под инвертированием я подразумеваю, что мое репозиторий git-svn находится на моем локальном боксе, и я нажимаю на блок разработчика.

Существует три репо:

  1. Репозиторий git-svn на локальном боксе.
  2. Я создаю голое репо на блоке dev, затем нажимаю на git-репозиторий svn в этот.
  3. На коробке разработчика я клонирую голое репо в рабочий каталог, который я использую для тестирования.После первоначального создания репо я вытащил из простого репо, описанного в # 2 выше.

Я редко делаю изменения в тестовом репо (# 3).Если я делаю тривиальное редактирование, я часто просто вручную делаю то же самое редактирование в репо # 1 на локальном боксе.Иногда я помещал коммиты из тестового репо (# 3) обратно в голое репо (# 2), а затем перетаскивал их в репозиторий git-svn (# 1) из локальной коробки.Чаще всего случается так, что я выслеживаю трудно обнаруживаемую ошибку и делаю кучу небольших изменений непосредственно в тестовом репозитории (# 3), а когда я нахожу ошибку, я просто выбрасываю все эти отладочные изменения иИсправьте ошибку прямо в репозитории git-svn (# 1), затем перейдите к # 2, подтянитесь к # 3 и протестируйте.

Рабочий процесс:

  1. [local] git co -b myfeature
  2. [local] hack hack hack
  3. [local] git commit -m'did stuff '-a
  4. [local] git push devbox myfeature
  5. [dev] cd myapp;мерзавец;git co origin / myfeature
  6. [dev] тестовый тестовый тест
  7. повтор 2-6
  8. [local] git co master
  9. [local] git svnrebase
  10. [local] git co myfeature
  11. [local] git rebase master
  12. [local] git co master
  13. [local] git merge -ff-only myfeature
  14. [local] git svn dcommit
  15. [local] git br -d myfeature

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

...