与SVN上游同步工作

Question

我正在使用一个使用OpenSource项目代码的项目.其中一个要求是尽可能多地将代码推送回上游.

远程项目正在使用Subversion(不是很好).

我目前的设置如下:

[Remote SVN] (git svn fetch)-> [My public Git] <-(push/pull)-> [My dev. Git]
                                    VV
                                  (pull)
                                    VV
                               [Testing grid]

编辑11.7. - 重新阐述了这个问题

我的问题是我的本地公共回购和svn上游的共存.

我必须提供3个公共分支机构:

• 保守稳定
• 实验稳定
• 发展

这些分支现在是线性的(开发变得实验稳定,实验变得保守),但目标是合并的标准3头方法.由于他们的公共性,我不能改变这些分支.

现在与此完全正交,我试图以某种方式使补丁更容易上传.从我的分支机构挖掘它们很慢并且容易出错.

我目前的典型工作流程是:

• 在顶级开发分支上实现一些功能
• 测试和修复功能
• 测试并修复此新功能所破坏的其他功能(实际上发生了很多)
• 确定这是否可以在上游接受(30:60是:否)
• 做点什么(我通常只写一个新的TODO)

上游的另一个问题是它们接受不同分支的补丁(我的公共分支基于它们的稳定分支).一旦补丁到达稳定的分支,我可以简单地忘记它们存在,但是直到发生这种情况我还需要将它们保存在本地.

Answer 1

在处理Subversion分支时,git svn文档建议使用以下工作流程:

# Clone a repo (like git clone):
git svn clone http://svn.example.com/project -T trunk -b branches -t tags

# Append svn:ignore settings to the default git exclude file:
git svn show-ignore >> .git/info/exclude

# View all branches and tags you have cloned:
git branch -r

# Create a new branch in SVN
git svn branch waldo

# Reset your master to waldo:
git reset --hard remotes/waldo

# local changes
git add ...
git commit ...

# pull changes on current branch
git svn rebase

# send changes to Subversion
git svn dcommit

# check for new branches
git svn fetch

上面的工作流程是在单个Subversion分支上进行不间断的更改,您可以使用提交位,但是处理多个活动的Subversion和git分支有点棘手.

要跟踪Subversion存储库的waldo分支,请从开始

git checkout -b waldo-svn remotes/waldo

-svn后缀是为了避免表单的警告

warning: refname 'waldo' is ambiguous.

并且还提醒您,此git分支用于跟踪Subversion分支.始终保持对这些分支的线性变化!

要更新waldo-svn,请运行

git svn rebase

This will fetch the changes from Subversion and rebase any local changes on top of those. It's also smart enough to recognize when one of your local changes has been accepted verbatim upstream: it will be replaced by the Subversion commit and have a line beginning with git-svn-id: ... in its commit message.

When the upstream maintainers alter the contents and structure of your patches (e.g., modifying the code, splitting a patch into multiple Subversion commits, or combining multiple patches into a single commit) is when life gets fun resolving conflicts and trying to untangle the mess.

For full generality, keep your -svn branches in git clean (no changes) and create issue branches off the -svn branches. To send a patch, use

git diff waldo-svn waldo-fix-frobnicator

Then when you git svn rebase to catch up with the Subversion repo, you'll need to review the log and decide on the respective dispositions of your issue branches, sort of a GTD for git.