Какой лучший способ передать ветку функций GIT -SVN debug-> в trunk?

У меня есть настройка соединительной линии, где идет весь мой производственный код.

Тогда у меня есть ветвь debug (parent is trunk), в которую я добавляю код отладки, такой как ведение журнала, варпапы и т.д.... это никогда не должно быть в производстве. Эта ветка редко изменяется.

Наконец, у меня есть ветвь feature (parent is debug), где я делаю все свое кодирование с преимуществами отладки. Постоянная фиксация этой ветки.

Я просто хочу знать, есть ли более простой способ переместить мой код feature в trunk. Это то, что я сейчас делаю:

  • Зафиксировать все изменения в моей ветке feature
  • Переключитесь на master и git svn rebase на изменения других разработчиков.
  • rebase Моя ветвь feature на ветку master (git rebase --onto master debug feature)
  • merge для master
  • git svn dcommit изменения для других разработчиков
  • rebase debug to master (git rebase master debug)
  • удалить feature ветвь
  • создайте новый feature из ветки debug.

Ответы

Ответ 1

Я бы сказал, что ваш рабочий поток довольно оптимален. Я бы подумал, что вишневый сбор будет излишним (но это зависит от количества коммитов).

Что вы можете сделать, это сквош всех коммитов в один и вишневый выбор/переустановка именно этого.

И кстати, почему просто не пишите простой script, если это то, что вы делаете все время? Git - инструмент немного низкого уровня, поэтому писать дополнительные скрипты, чтобы помочь с повторяющимися задачами, является очень хорошей идеей.

Ответ 2

Хорошо, я скажу ересь, и все будут голосовать, но отпустите. Если вы использовали svn напрямую, ваш рабочий процесс был бы намного проще.

С - реинтегрировать функцию подрывной деятельности, легко поддерживать синхронизацию вашей внешней линии и отладки. Чтобы объединить ветвь вашей функции, вы должны объединить все модификации ветки функции в соединительной линии. Команды будут выглядеть примерно так:

Чтобы объединить соединительную линию для отладки:

cd debug_branch_workcopy
svn merge --reintegrate http://server/project/trunk .
svn commit

Чтобы объединить ветвь функции в магистраль:

svn log --stop-on-copy http://server/project/branches/feature123 #see the last revision listed
cd trunk_workcopy
svn merge -r{revision_above}:HEAD http://server/project/branches/feature123 .
svn commit

Вы можете запустить последнюю команду слияния несколько раз, если вы измените ветвь после слияния. Subversion запомнит уже объединенные версии и не будет пытаться делать их дважды. Если вы находитесь в Windows, бесплатный TortoiseSVN даст вам хороший интерфейс слияния.

Кстати, я бы попробовал не иметь отдельную ветвь только с функциями отладки. Слишком легко сделать ручную ошибку и отправить код отладки в свою производственную магистраль. Я бы использовал что-то более динамичное, чтобы не запускать код отладки во время производства.

Ответ 3

Если я правильно вас понимаю, вы хотели бы иметь свои функции отладки только в своей (довольно статической) ветке отладки, но не в вашей основной ветке. Попробуйте следующее:

Сделайте "поддельное слияние" отладки в master

git checkout master
git merge --no-commit debug
git checkout master .        # undo all changes, get the files from master again
git add .                    # stage all files
git commit

Таким образом, отладка будет объединена с мастером, но ни один из ваших файлов в главном не изменится.

Теперь вы можете просто создать свои ветки функций поверх отладки и объединить их в master, когда закончите. Git теперь знает, что функции отладки удалены из master:

git checkout debug
git checkout -b new_feature  # create a new feature branch
# hack, hack, hack
git commit
git checkout master          # All works fine...
git merge new_feature        # ...so merge into master. Debug code will be stripped here

Вы можете переадресовать ветку отладки на new_feature и после этого удалить ветвь new_feature.

Обратите внимание, что всякий раз, когда вы меняете ветвь отладки, вы должны повторить процедуру поддельного слияния.

Ответ 4

У нас есть отдельная ветка для каждой функции или исправления ошибок, которые мы делаем. Затем они могут быть объединены обратно в багажник, если они были достаточно проверены.

Филиалы могут обновляться, если они становятся немного старыми.

Мы склонны выделять незначительные изменения непосредственно в trunk, но для более значительных изменений мы собираем их в ветки кандидат-релиз, в которую мы объединяем все соответствующие ветки, содержащие изменения, чтобы перейти в live. Эта новая ветка может быть развернута и протестирована, чтобы увидеть, что комбинация изменений нарушает что-либо, прежде чем она окончательно слилась с багажником и переходит в производство.

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

Надеюсь, что поможет

Ответ 5

Я думаю, что вы ищете git -cherry-pick. Это позволяет применять коммиты от функции на мастере без использования танца перебазы, который вы описываете.

Так как вы собираетесь удалить ветвь функции, вам не нужно видеть явное слияние, которое я предполагаю.

Ответ 6

Ваш рабочий процесс сложный, потому что то, что вы пытаетесь сделать, сложно. Никакой VCS, который я знаю, позволяет вам легко поддерживать некоторые изменения, которые никогда не должны сливаться. В нем много говорится о мощности git, что ваш рабочий процесс не сложнее, чем он.

Я предполагаю, что ваш язык имеет какой-то механизм условной компиляции (директивы препроцессора #IFDEF и т.д.). Если вы обернете свой код отладки, вместо этого вы столкнетесь с гораздо меньшим трением.