git-svn:有一个很好的分支和合并模式吗？

Question

我正在我的机器上运行git-svn客户端.我希望有一个类似于标准git分支和合并模式的模式,其中你有一个从trunk分支的开发分支,你有几个功能或bug修复分支从开发分支扩展.

我遇到的问题是我无法弄清楚如何使用git-svn完成所有工作.我知道合并是一个痛苦的香草颠覆,它与香草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：不要签出顶级项目目录（包含 trunk/branches/ 和 tag/ 的目录），而是签出 trunk 目录本身，即：

不要这样做：

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 来执行此操作（以避免历史记录复杂化）