Является ли git -svn dcommit после слияния в git опасным?

Ответ 1

На самом деле, я нашел еще лучший способ с опцией --no-ff в git merge. Вся эта техника сквоша, которую я использовал раньше, больше не требуется.

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

• У меня есть ветвь "master", которая является единственной ветвью, из которой я dcommit и клонирует репозиторий SVN (-s Предположим, у вас есть стандартный макет SVN в репозитории trunk/, branches/, и tags/):

  git svn clone [-s] <svn-url>
  

• Я работаю над локальной работой "работа" (-b создает ветку "работа" )

  git checkout -b work
  

• фиксировать локально в ветке "work" (-s, чтобы отменить ваше сообщение фиксации). В дальнейшем я предполагаю, что вы сделали 3 локальных фиксации

  ...
  (work)$> git commit -s -m "msg 1"
  ...
  (work)$> git commit -s -m "msg 2"
  ...
  (work)$> git commit -s -m "msg 3"
  

Теперь вы хотите зафиксировать на сервере SVN

• [В конце концов] запишите изменения, которые вы не хотите видеть на сервере SVN (часто вы комментировали некоторый код в основном файле только потому, что хотите ускорить компиляцию и сосредоточиться на заданной функции)

  (work)$> git stash
  

• rebase главная ветвь с репозиторием SVN (для обновления с сервера SVN)

  (work)$> git checkout master
  (master)$> git svn rebase
  

• вернитесь в рабочую ветку и переустановите с помощью мастера

  (master)$> git checkout work
  (work)$> git rebase master
  

• Убедитесь, что все в порядке, например:

  (work)$> git log --graph --oneline --decorate
  

• Теперь пришло время объединить все три коммиты из ветки "work" в "master", используя эту замечательную опцию --no-ff

  (work)$> git checkout master
  (master)$> git merge --no-ff work
  

• Вы можете заметить состояние журналов:

  (master)$> git log --graph --oneline --decorate
  * 56a779b (work, master) Merge branch 'work'
  |\  
  | * af6f7ae msg 3
  | * 8750643 msg 2
  | * 08464ae msg 1
  |/  
  * 21e20fa (git-svn) last svn commit
  

• Теперь вы, вероятно, захотите отредактировать (amend) последнюю фиксацию для ваших SVN-чуваков (в противном случае они будут видеть только одно сообщение с сообщением "Объединить работу ветки"

  (master)$> git commit --amend
  

• Наконец, фиксация на сервере SVN

  (master)$> git svn dcommit
  

• Вернитесь к работе и, в конечном итоге, восстановите сохраненные файлы:

  (master)$> git checkout work
  (work)$> git stash pop
  

Ответ 2

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

У меня есть ветвь "master", которую я использую для отслеживания svn-сервера. Это единственная ветка, из которой я выхожу. Если я выполняю какую-то работу, я создаю ветку тем и работаю над ней. Когда я хочу зафиксировать это, я делаю следующее:

• Закрепить все в ветке темы
• git svn rebase (разрешить любые конфликты между вашей работой и svn)
• git мастер проверки
• git svn rebase (это делает следующий шаг быстрым слиянием, см. ниже комментарии Aaron)
• git merge topic_branch
• разрешать любые конфликты слияния (на данный момент их не должно быть)
• git svn dcommit

У меня также есть другая ситуация, когда мне нужно поддерживать некоторые локальные изменения (для отладки), которые никогда не должны подталкиваться к svn. Для этого у меня есть вышеупомянутая главная ветвь, но также ветвь называется "работа", где я обычно работаю. Тематические ветки разветвлены. Когда я хочу выполнить работу там, я проверяю мастер и использую вишневый выбор, чтобы выбрать коммиты из рабочей ветки, которые я хочу зафиксировать на svn. Это потому, что я хочу избежать совершения трех локальных изменений. Затем, я dcommit из мастер-ветки и rebase все.

Стоит запустить git svn dcommit -n сначала, чтобы убедиться, что вы собираетесь совершить то, что вы намерены совершить. В отличие от git, переписать историю в svn сложно!

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

Ответ 3

Простое решение: удалите ветвь "work" после слияния

Короткий ответ: Вы можете использовать git, как вам нравится (см. ниже простой процесс), включая слияние. Просто убедитесь, что выполняете каждую git операцию слияния 'с помощью < git branch -d work ", чтобы удалить временную ветку работы.

Обоснование фона: Проблема слияния /dcommit заключается в том, что всякий раз, когда вы git svn dcommit 'ветвь, история слияния этой ветки "сплющена": git забывает обо всех слияниях, которые вошли в эту ветку: только содержимое файла сохраняется, но тот факт, что этот контент (частично) исходит из конкретной другой ветки, теряется. Смотрите: Почему git svn dcommit теряет историю коммитов для локальных ветвей?

(Примечание. Существует не так много git -svn: svn просто не понимает, что более мощный git объединяется. Таким образом, внутри репозитория svn эта информация объединения не может быть представлена ​​ни в одном способ.)

Но это вся проблема. Если вы удалите ветвь "work" после ее объединения в "главную ветку", то ваш репозиторий git будет на 100% чистым и будет выглядеть точно так же, как ваш репозиторий svn.

Мой рабочий процесс: Конечно, я сначала клонировал удаленный репозиторий svn в локальный репозиторий git (это может занять некоторое время):

$> git svn clone <svn-repository-url> <local-directory>

Вся работа затем происходит внутри "локального каталога". Всякий раз, когда мне нужно получать обновления с сервера (например, "svn update" ), я делаю:

$> git checkout master
$> git svn rebase

Я делаю всю свою работу по разработке в отдельной ветки "работа", которая создается следующим образом:

$> git checkout -b work

Конечно, вы можете создавать столько ветвей для своей работы, сколько хотите, и объединять и пересобирать между ними по своему усмотрению (просто удалите их, когда вы закончите с ними, как описано ниже). В моей обычной работе я делаю очень часто:

$> git commit -am '-- finished a little piece of work'

Следующий шаг (git rebase -i) необязателен --- он просто очищает историю до архивации ее на svn: как только я достиг стабильного километра, который я хочу поделиться с другими, я переписываю историю этой ветки "работы" и очистить сообщения фиксации (другим разработчикам не нужно видеть все небольшие шаги и ошибки, которые я сделал на пути, - только результат). Для этого я делаю

$> git log

и скопируйте хэш файл sha-1 последнего коммита, который находится в реальном времени в репозитории svn (как указано git -svn-id). Затем я вызываю

$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

Просто вставьте sha-1 хэш из нашего последнего svn commit вместо моего. Вы можете прочитать документацию с помощью "git help rebase" для получения подробной информации. Короче: эта команда сначала открывает редактор, представляющий ваши коммиты ---- просто измените 'pick' на 'squash' для всех тех коммитов, которые вы хотите сквозировать с предыдущими фиксациями. Конечно, первая строка должна оставаться "выборкой". Таким образом, вы можете сконденсировать свои маленькие мелкие фиксации в один или несколько значимых единиц. Сохраните и выйдите из редактора. Вы получите другой редактор с просьбой переписать сообщения журнала фиксации.

Вкратце: после того, как я закончил "взлом кода", я массирую свою ветку "работа", пока она не посмотрит, как я хочу представить ее другим программистам (или как я хочу видеть работу в течение нескольких недель, когда я просматривать историю).

Чтобы внести изменения в репозиторий svn, я:

$> git checkout master
$> git svn rebase

Теперь мы вернулись в ветвь старого мастера, обновленную со всеми изменениями, которые произошли в среднем в репозитории svn (ваши новые изменения скрыты в ветке "работа" ).

Если есть изменения, которые могут столкнуться с вашими новыми изменениями работы, вы должны разрешить их локально, прежде чем вы сможете нажать свою новую работу (подробнее см. ниже). Затем мы можем изменить наши изменения на svn:

$> git checkout master
$> git merge work        # (1) merge your 'work' into 'master'
$> git branch -d work    # (2) remove the work branch immediately after merging
$> git svn dcommit       # (3) push your changes to the svn repository

Примечание 1: Команда 'git branch -d work' весьма безопасна: она позволяет вам удалять только те ветки, которые вам больше не нужны (поскольку они уже объединены в вашу текущую ветку). Если вы выполните эту команду по ошибке, прежде чем объединить свою работу с ветвью "master", вы получите сообщение об ошибке.

Примечание 2: Обязательно удалите ветку с помощью git branch -d work 'между слиянием и dcommit: если вы попытаетесь удалить ветвь после dcommit, вы получите сообщение об ошибке: Когда вы выполните git svn dcommit ', git забывает, что ваша ветка была объединена с' master '. Вы должны удалить его с помощью "git branch -D work", который не выполняет проверку безопасности.

Теперь я немедленно создаю новую ветку "работа", чтобы избежать случайного взлома в ветке "master":

$> git checkout -b work
$> git branch            # show my branches:
  master
* work

Интеграция вашей работы с изменениями на svn: Вот что я делаю, когда "git svn rebase" показывает, что другие меняли репозиторий svn, когда я работал над моей ветвью "work" :

$> git checkout master
$> git svn rebase              # 'svn pull' changes
$> git checkout work           # go to my work
$> git checkout -b integration # make a copy of the branch
$> git merge master            # integrate my changes with theirs
$> ... check/fix/debug ...
$> ... rewrite history with rebase -i if needed

$> git checkout master         # try again to push my changes
$> git svn rebase              # hopefully no further changes to merge
$> git merge integration       # (1) merge your work with theirs
$> git branch -d work          # (2) remove branches that are merged
$> git branch -d integration   # (2) remove branches that are merged
$> git svn dcommit             # (3) push your changes to the svn repository

Существуют более мощные решения: Представленный рабочий процесс упрощен: он использует полномочия git только в каждом раунде "update/hack/dcommit" --- но оставляет долгосрочную историю проекта такой же линейной, как и репозиторий svn. Это нормально, если вы просто хотите начать использовать git слияния с небольшими первыми шагами в проекте svn с унаследованным.

Когда вы более знакомы с слиянием git, не стесняйтесь изучать другие рабочие процессы: если вы знаете, что делаете, вы можете смешивать git слияния с svn merges (Используя git -svn (или аналогичный), чтобы помочь с svn merge?)

Ответ 4

Ответ Грега Хьюджилла сверху небезопасен! Если какие-либо новые коммиты появились на соединительной линии между двумя "git svn rebase", слияние не будет ускоренной перемоткой вперед.

Это можно обеспечить, используя флаг "-ff-only" для git -merge, но я обычно не запускаю "git svn rebase" в ветке, только "git master-rebase" на нем (при условии, что это только локальная ветвь). Затем после этого "git merge thebranch" гарантированно будет быстро вперед.

Ответ 5

Безопасный способ объединения ветвей svn в git заключается в использовании git merge --squash. Это создаст единую фиксацию и остановку для вас, чтобы добавить сообщение.

Скажем, у вас есть ветка svn для темы, называемая svn-branch.

git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch

в этот момент у вас есть все изменения от svn-ветки, раздавленной в одну транзакцию, ожидающую в индексе

git commit

Ответ 6

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

git rebase master topic

который затем будет воспроизводить ваши фиксации по главному ветку, готовому для вас, dcommit