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头方法。由于他们的公共性，我不能改变这些分支。

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

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

在顶级开发分支上实现一些功能
test＆amp;修复功能
test＆amp;修复这个新功能破坏的其他功能（实际上发生了很多）
确定这是否可以在上游接受（30:60是：否）
做点什么（我通常只是写一个新的TODO）

上游的另一个问题是他们接受不同分支的补丁（我的公共分支基于他们的稳定分支）。一旦补丁到达稳定的分支，我可以简单地忘记它们存在，但在此之前我还需要将它们保存在本地。

Answer 1

在处理Subversion分支时，git svn documentation建议使用以下工作流程：

# 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

这将从Subversion获取更改并在其上更改任何本地更改。它还足够聪明，可以识别当你的一个本地更改被逐字逐句接受时：它将被Subversion提交取代，并在其提交消息中以git-svn-id: ...开头。

当上游维护者改变补丁的内容和结构时（例如，修改代码，将补丁分成多个Subversion提交，或者将多个补丁组合到一个提交中）就是生命得到的时候有趣的解决冲突，并试图解决混乱。

为了完全通用，请将-svn分支保存在git中（无更改）并在-svn分支上创建问题分支。要发送补丁，请使用

git diff waldo-svn waldo-fix-frobnicator

然后当你git svn rebase赶上Subversion回购时，你需要查看日志并决定你的问题分支的相应处置，为git排序GTD。 / p>

Answer 2

我不确定我是否理解了您的问题，但我认为您可能正在寻找git stash。

Answer 3

我不确定您的功能与上游代码的高度耦合程度，但您可能可以将上游的“核心”分支，与您的功能添加分开。只有在可以对代码库进行分区时才能正常工作。

Answer 4

你真的没有说清楚你想做什么。在你的陈述中提到“（因此维护每个特征的单独分支是非平凡的）”，我只能想知道为什么你认为它应该是微不足道的。相互依赖的两个补丁应该是单个补丁，或者至少在一个分支上。依赖于A（但不是另一种方式）的补丁B应该在具有A的分支上，或者在A分支上具有父提交的分支上。

现在，如果您想要对上游补丁的位置保持“清晰概览”，那么这将归结为保留所有上游分支的本地副本。我没有看到问题出在哪里。如果你想要更准确的答案，你真的需要精确。

好的，现在更容易解决。

你有两个问题。

（1）获得fork提交，一旦你意识到你永远不会将它们发送回来，它们永远不会从你的主开发分支上游进入fork分支。

做一个fork分支。一旦您意识到某个功能没有返回，请从保持fork功能的分支中拉出。然后使用git revert fork功能来应用从local- *撤消功能的补丁。根据需要重复。

（2）您是否担心上游补丁会发生什么。

你真的不应该追踪他们是否已经将你的补丁应用到远程稳定（以后的r-stable ）。如果从r-stable拉出来并且尚未应用补丁，则不会丢失L-stable中的补丁。唯一可能的问题是补丁中的代码会出现合并冲突，但是你无法解决这个问题。一旦他们应用补丁，它将看起来与您解决合并冲突的方式完全一样（在这种情况下，当您从R-stable中提取补丁时，您将不会获得差异），或者它们将以不同的方式合并，你将得到一个合并冲突，并有机会决定保持他们的方式或方式。请记住，如果你想保持自己的方式，你将从r-stable中分离出来。一种选择是将“你的方式”移到fork上并保持在本地 - *。

与SVN上游同步工作

4 个答案: