我一直在使用Git作为Subversion回购的胖客户端，这非常棒。我应该遵循one-commit-per-Trac-ticket方法，但我更喜欢为自己的利益拥有丰富的原子提交历史，所以我已经养成了以下习惯：
git rebase -i将所有工作捆绑到一个提交中（保持主题分支不变）git svn dcommit提交SVN master，然后从trunk合并到master（第二步通常是无操作，因为主干和功能分支应匹配）这可以让master和trunk很好地保持同步，同时保留我想要的所有历史记录。唯一的麻烦是Git认为master永远远远超过trunk，因为据我所知，我从来没有真正提交过主题分支或master回trunk 1}} - 步骤＃3失去了变化的祖先，所以所有Git看到的都是trunk单独哼唱，master合并来自它和主题分支：
Switched to branch 'master'
Your branch and 'trunk' have diverged,
and have 232 and 1 different commit(s) each, respectively.
现在，我实际上知道这是一个问题。我主要是唯一一个在这个SVN回购中工作的人，所以这并不像是有一些棘手的合并可能会让人感到困惑。但它原则上让我感到困扰（我就是这样）。我希望trunk提交能够反映他们的“真实”祖先 - 每一个都是与前一个SVN修订版合并为一个父级，主题分支合并为另一个。
瞧，有.git/info/grafts，这似乎正是我想要的。我甚至可以将trunk合并为master 作为快进合并，这在道德上通常是绝对的。但结果可能很好，但似乎很糟糕，特别是因为它可能不是绝对必要的。
所以我想知道的是，这个想法有什么危险吗？如果我说，每次我做rebase / dcommit舞蹈时养成嫁接的习惯，我是否要求麻烦？我应该克服自己吗？ ： - ）
答案 0 :(得分：2)
老问题，我知道，但是：
我认为保持“主干”和“主人”之间的差异会让你的生活变得更加艰难。 “master”通常应指向svn树的顶部，或快速修复你即将发布的内容。但是，当你捆绑了一系列更改并提交时，我认为下一个合乎逻辑的步骤是设置一个移植，这样你提交的更改就是它的svn父级和你以前使用的主题分支的子级。写下票证的代码。换句话说，从git的角度来看，你提出的改变变成了svn树和你的主题分支的合并 - 它很多人都尊重它。根本没有必要创建主题分支的真正git合并。
答案 1 :(得分：0)
我建议你放弃svn，因为你是唯一一个使用它并且坚持使用git，但是假设你无论出于什么原因都不能这样做，那么我建议你不要再使用git-svn了通常意义上说。
考虑放弃您的本地历史，转而使用您发送给svn的“精美”历史记录。您的本地历史记录反映了您自己的工作，这是您尚未准备好向世界展示的工作 - 某些测试用例可能会失败，或者代码样式可能很难看，等等。进行本地提交，对其进行修改，对其进行测试，然后把它放到一个很好的小提交上传到svn服务器。
您仍然可以使用reflog一段时间进行本地更改。如果你真的想保留自己的本地黑客，那么考虑标记它们或其他东西，这样它们就不会使你的主分支混乱。