Git ребазинг на ветку, которая будет создана позже - PullRequest
Новая
       17

Git ребазинг на ветку, которая будет создана позже

2 голосов
/ 31 июля 2009

Я работаю над проектом веб-сайта, который в настоящее время отслеживается в svn, но собирается перейти на git, как только у кого-то появится время для установки нового сервера и прочего. Это длинная история, но в то же время я сделал свой собственный git-репозиторий из своего кода и довольно много работал над ним. Я не использовал git svn clone, потому что я за границей, и мое интернет-соединение странное и требует прокси-сервер для HTTP, и, похоже, оно не пропускает git svn. В любом случае, я разрабатывал в своем собственном git-репозитории, но в конце концов, как только проект действительно будет импортирован должным образом, мне нужно будет переназначить свою работу на клонированный git-svn материал. Будет ли git rebase нормально работать для этого?

Одна сложность заключается в том, что я фактически работал на виртуальной машине, и для многих коммитов я не осознавал, что не установил записи конфигурации user.name и user.email, чтобы коммиты были от локального пользователя vm, что-то странно Было бы лучше просто собрать все мои изменения в файлы diff и затем применить их поверх новой ветви после ее создания?

Еще одним осложнением является то, что использование SVN раньше было нерешительным, поэтому на рабочем сервере произошли фактически незавершенные изменения, которых у меня не было. Вообще-то, у меня изначально была более старая версия кода, которая даже не была заголовком SVN, поэтому мне не хватало чего-то еще. Как лучше поступить?

Последний вопрос: если я импортирую SVN-репозиторий через git svn (я только что проверил, и теперь он работает), но я не добавляю файл авторов, смогу ли я потом перебазировать свой переходит на правильно импортированную ветку с файлом авторов?

О, новое осложнение. Я импортировал SVN-репозиторий, используя git svn, изнурительный процесс, который занимал большую часть двух дней в этом медленном соединении. Однако после окончательного завершения клонирования я понял, что в репозитории SVN весь код находится в подкаталоге, но в моем репозитории git корень репозитория также был корнем каталога. Если это немного сбивает с толку, это в основном так:

SVN:

\dir\codez

мерзавец:

\codez

Как я могу объединить два репозитория? Я надеюсь, что я все еще могу использовать rebase, но это кажется очень странной ситуацией. Похоже на подмодули, но я не думаю, что это именно то, что мне нужно.

Ответы [ 3 ]

5 голосов
/ 31 июля 2009

Я не использовал git svn clone, потому что я за границей, и мое интернет-соединение странное и требует прокси для HTTP

Должно работать, если вы установите 

http_proxy=http://username:passwword@pprroxyHost:proxyPort

или вы можете попробовать 

http_proxyUser=username
http_proxyPassword=password
http_proxyHost=aProxyHost
http_proxyPort=aProxyPort

Будет ли для этого корректно работать git rebase?

Общий ответ: да, потому что вы еще не опубликовали свою ветку Git.
Подробный ответ: вам нужно сначала сделать ребаз в свою ветку, прежде чем объединять результат с мастером. См. этот ответ .
Это предпочтительный рабочий процесс, поскольку он позволяет вам разрешить любой конфликт в вашей ветви перед объединением (или перебазированием, если вы хотите сохранить свою историю) своей ветви с главной. На самом деле, вы увидите ниже, что создание специальной ветви "слияния" на самом деле является лучшей идеей.

не понял, что я не установил записи конфигурации user.name и user.email

Поскольку вы еще не опубликовали, вы можете использовать filter-branch, чтобы изменить свои коммиты и изменить имя пользователя и адрес электронной почты

Небольшой скрипт sh может помочь 

#!/bin/sh

git filter-branch --env-filter '

n=$GIT_AUTHOR_NAME
m=$GIT_AUTHOR_EMAIL

case ${GIT_AUTHOR_NAME} in
        aSystemUserName) n="TheActual Name" ; m="TheActual@mailAddress" ;;
esac

export GIT_AUTHOR_NAME="$n"
export GIT_AUTHOR_EMAIL="$m"
export GIT_COMMITTER_NAME="$n"
export GIT_COMMITTER_EMAIL="$m"
'

вызовите этот скрипт из вашего репо, и все готово.

Во-первых, у меня была более старая редакция кода, которая даже не была заголовком SVN, поэтому мне не хватало чего-то еще. Как лучше поступить?

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

  • код из SVN
  • код, который вы не получили напрямую из репозитория SVN.

Позже я смогу перенести мои изменения в правильно импортированную ветку с файлом авторов?

Я не уверен, но я так думаю. Если нет, то пока вы еще ничего не опубликовали, вы можете снова использовать скрипт filter-branch rename ...

1 голос
/ 31 июля 2009

git-rebase зависит от наличия общего коммита где-нибудь в истории. Это также происходит в одном хранилище. Похоже, вы окажетесь в ситуации, когда (а) новое импортированное репозиторий git-svn отделено от вашего, и (б) между ними не будет общих коммитов. Возможно, вам придется делать это с помощью патчей, но git может помочь вам в этом. Проверьте справочные страницы для git-format-patch и git-am. Первый может сгенерировать серию патчей из ряда коммитов, а второй может взять эту серию патчей и применить их - и все сообщения фиксации и тому подобное будут сохранены.

Это даст вам возможность исправить проблему user.name/email - вы можете просто изменить их в заголовках патчей и убедиться, что они установлены правильно в новом импортированном репо, прежде чем применять ваши патчи!

Вероятно, лучший способ справиться с вашим устаревшим стартовым местом («более старая версия ... это даже не было SVN-головой»):

  • привести репозиторий SVN в исправное состояние со всеми зафиксированными изменениями
  • импортировать его с помощью git-svn
  • создать и проверить ветку на старом коммите, где вы начали работать с
  • примените серию патчей
  • объединить эту ветку в master, соответствующую текущей голове SVN

К счастью для меня, но в меньшей степени для вас, мне никогда не приходилось использовать git-svn, поэтому я не могу ответить на ваш вопрос о файле авторов окончательно. Однако, если я правильно понимаю, авторский файл переводит авторов SVN в авторов git. Если автор изменяет коммит git, хэш изменится. Поэтому было бы важно не связываться с этой таблицей перевода и правильно ее понять с первого раза.

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

0 голосов
/ 31 июля 2009

Вы можете создать новую нерождённую ветку с помощью инструментов низкого уровня: 

$ git symbolic-ref HEAD refs/heads/new_branch

С современным git вы можете перебазировать всю ветку с помощью опции --root «git rebase».

Это может или не может помочь в вашей ситуации. YMMV.

...