git-svn：有没有好的分支和合并模式？

Question

我正在我的机器上运行 git-svn 客户端。我想要一个类似于标准 git 分支和合并模式的模式，其中您有一个从主干分支的开发分支，并且您有几个从开发分支扩展的功能或错误修复分支。

我遇到的问题是我不知道如何使这一切都与 git-svn 一起工作。我知道合并对于 vanilla subversion 来说很痛苦，而 vanilla git 很好，但是 git-svn 也很痛苦。

那么....什么是最佳实践？如何使用 git-svn 自信而轻松地进行分支和合并？它的开发实践是什么？

我想遵循这个模式：

* Master
|\
| * Development
| |\
| | * Feature
| | |
| | * a commit to feature
| |\|
| | * merge Development into Feature
| | |
| |/|
| * | merge Feature into Development
 ... etc

任何帮助将不胜感激！

编辑

澄清一下——每个 git 分支都应该对应一个 svn 分支。这是一个团队工作流程，团队成员应该能够处理功能和错误修复分支。

Answer 1

简而言之：

• 分支服务器端
• 同步合并单方向（从主干到分支/功能）
• 一次性合并（重新集成）（这将关闭分支）

这是我目前推荐的基于一些注释的 svn 工作流程。 之间的单词是占位符。

提示：

T1：使用符号“^/”来引用您的基础存储库。 您可以从项目中的任何位置列出存储库：

svn list ^/<repo_path>

T2：到现在为止，您目前在哪个分支上工作使用

svn info | grep URL

建议：

R1：不签出顶级项目目录（包含主干/分支/和标签/的目录），而是主干目录本身，即：

不要这样做：

svn checkout <BASE_URL>/svn/<proj>

但是做：

svn checkout <BASE_URL>/svn/<proj>/trunk workdir

并使用开关。

R2- 分支时，总是在服务器端进行以避免复制。

不要做：

svn cp workdir/trunk workdir/branches/feature

做：

svn cp ^/trunk ^/branches/feature

接着是：

cd <workdir_path>
svn sw ^/branches/feature

R3：仅从主干合并（同步）到您的分支。

cd <workdir_path>
svn merge ^/trunk

R4：在另一个方向合并（从分支到主干）使用重新整合合并。

svn up
svn switch ^/trunk
svn merge --reintegrate ^/branches/<feature>
(resolve conflicts and ...)
svn ci

例外：如果您需要对主干进行挑选更改，您可能更愿意使用 --ignore-ancestry 来完成（以避免与历史记录复杂化）