Question

我正在开发一个目前在svn中跟踪的网站项目，但是一旦其他人有时间设置新的服务器和东西，它将转移到git。这是一个很长的故事，但与此同时，我已经从我的一些代码中创建了自己的git存储库，并对它进行了相当多的工作。我没有使用git svn clone，因为我在海外，我的互联网连接很奇怪，需要HTTP代理，而且似乎没有让git svn通过。在任何情况下，我一直在我自己的git存储库中开发，但最终一旦项目实际上正确导入，我将需要将我的工作重新定义为git-svn克隆的东西。 git rebase能否正常使用？

一个复杂的问题是我实际上是在虚拟机中工作，对于很多提交，我没有意识到我没有设置user.name和user.email配置条目，所以提交来自vm的本地用户，这有点奇怪。将所有更改收集到diff文件中，然后在创建新分支后将它们应用到新分支上会不会更好？

另一个复杂因素是之前使用的SVN有点半心半意，因此生产服务器上实际上没有提交我未提及的更改。实际上，我首先对代码进行了较旧的修订，甚至不是SVN头，所以我遗漏了一些东西。最好的方法是什么？

最后一个问题是，如果我通过git svn导入SVN存储库（我刚检查过，它现在似乎正在运行）但是我没有添加作者文件，我以后能够使用authors-file将我的更改重新绑定到正确导入的分支上？

哦，一个新的并发症。我使用git svn自己导入了SVN存储库，这是一个艰苦的过程，在这个缓慢的连接上花费了两天的大部分时间。然而，在最终完成克隆之后，我意识到在SVN存储库中代码都在子目录中，但在我的git存储库中，存储库的根也是目录的根。如果这有点令人困惑，它基本上就像这样

SVN：

\dir\codez

GIT中：

\codez

如何组合这两个存储库？我希望我仍然可以使用rebase，但这似乎是一个非常奇怪的情况。这听起来与子模块相似，但我认为这不是我需要的。

Answer 1

我没有使用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分支详细解答：在将结果合并到master之前，您需要首先重新绑定到您的分支。见this answer。
这是首选的工作流程，因为它允许您在合并之前解决分支中的任何冲突（或者，如果您想保留历史记录，则将其重新定位）分支到主分支上。
实际上，您将在下面看到创建一个特殊的“合并”分支实际上是一个更好的主意。

没有意识到我没有设置user.name和user.email配置条目

由于您尚未发布，可以使用filter-branch修改提交并更改用户名和电子邮件

一个小脚本可以帮助

#!/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头，所以我遗漏了一些东西。最好的方法是什么？

此实例中的基本工作流程是从当前工作分支创建一个新的“合并”分支，以隔离rebase工作（并解决所有冲突）
在这种delta非常重要的合并中，您必须保持工作分支的清洁，使其不再需要进行所有更改，以便包括：

来自SVN的代码
您未直接从SVN存储库获取的代码。

我以后能否将我的更改重新绑定到带有authors文件的正确导入的分支上吗？

我不确定，但我确实这么认为。如果没有，只要您还没有发布任何内容，您可能希望再次使用filter-branch重命名脚本...

Answer 2

git-rebase取决于在历史记录中的某个位置进行常见提交。它也发生在一个存储库中。听起来你最终会遇到这样一种情况，即（a）新的git-svn导入的repo与你的仓库分开，并且（b）两者之间不会有共同的提交。你可能最终需要通过补丁来做到这一点，但是git可以帮助你解决这个问题。查看git-format-patch和git-am的联机帮助页。第一个可以从一系列提交中生成一系列补丁，第二个可以使用这一系列补丁并应用它们 - 所有提交消息等都将被保留。

这将为您提供修复user.name/email问题的机会 - 您只需在修补程序的标题中修改它们，并确保在应用修补程序之前在新导入的repo中正确设置它们！

处理你过时的起点（“旧版本......甚至不是SVN负责人”）的最佳方法可能是：

将SVN repo置于良好状态，并提交所有更改
使用git-svn
在
应用您的补丁系列
将此分支合并为master，对应于当前的SVN head

对我来说幸运的是，对你来说不那么好，我从来不需要使用git-svn，所以我无法肯定地回答你的作者文件问题。但是，如果我理解正确，作者文件将SVN作者转换为git作者。如果作者在git提交上更改，则哈希将更改。因此，重要的是不要弄乱这个翻译表，并在第一次就把它弄好。

这里有很多问题，所以如果我错过了什么，请随时发表评论并要求更多。

Answer 3

您可以使用低级工具创建新的未出生的分支：

$ git symbolic-ref HEAD refs/heads/new_branch

使用现代git，您可以使用“git rebase”的--root选项来修改整个分支。

这可能会或可能不会对您的情况有所帮助。 YMMV。

Git重新定位到稍后将创建的分支上

3 个答案: