Question

我有一个主干设置，我的所有生产代码都在这里。

然后我有一个debug分支（父级是trunk），我添加了调试代码，例如日志记录，var转储等等......这应该永远不会在生产中。这个分支很少改变。

最后我有一个feature分支（父级是debug），我在那里编写了所有编码并具有调试的好处。这个分支一直有提交。

我只想知道是否有更简单的方法将我的feature代码移至trunk。这就是我目前所做的事情：

将所有更改提交至feature分支
切换到其他开发者的master和git svn rebase更改。
rebase我的feature分支到master分支（git rebase --onto master debug feature）
merge功能master
git svn dcommit对其他开发者的更改
rebase debug至master（git rebase master debug）
删除feature分支
从feature分支机构创建新的debug。

Answer 1

我会说你的工作流程非常优秀。我认为挑选樱桃是一种矫枉过正（但这取决于提交的次数）。

你可以做的就是将所有提交压缩成一个，然后选择樱桃挑选/改造。

顺便说一句，为什么不写一个简单的脚本，如果它是你一直在做的事情？ Git是一个有点低级别的工具，所以编写额外的脚本来帮助重复性任务是一个非常好的主意。

Answer 2

好的，我会说一个异端邪说，每个人都会投票给我，但我们走了。如果你直接使用svn，你的工作流程会简单得多。

使用--reintegrate feature of subversion可以很容易地使trunk和debug分支保持同步。要合并功能分支，您需要合并主干中功能分支的所有修改。命令类似于：

将trunk合并到debug：

cd debug_branch_workcopy
svn merge --reintegrate http://server/project/trunk .
svn commit

将功能分支合并到trunk：

svn log --stop-on-copy http://server/project/branches/feature123 #see the last revision listed
cd trunk_workcopy
svn merge -r{revision_above}:HEAD http://server/project/branches/feature123 .
svn commit

如果在合并后更改分支，则可以多次运行上一个合并命令。 Subversion将记住已经合并的修订版，并且不会尝试两次修改它们。如果你在Windows中，免费的TortoiseSVN将为你提供一个很好的合并界面。

顺便说一句，我试着不要只有调试功能的单独分支。制作手动错误并将调试代码发送到生产主干非常容易。我会使用更动态的东西来在生产中不运行调试代码。

Answer 3

如果我理解正确，您希望仅在您的（非常静态）调试分支中使用您的调试功能，而不是在您的主分支中。试试这个：

将调试“虚假合并”为主

git checkout master
git merge --no-commit debug
git checkout master .        # undo all changes, get the files from master again
git add .                    # stage all files
git commit

这样，debug将合并到master中，但master中的所有文件都不会更改。

现在，您可以在调试之上简单地创建功能分支，并在完成后将它们合并到主服务器中。 Git现在知道调试功能是从master中删除的：

git checkout debug
git checkout -b new_feature  # create a new feature branch
# hack, hack, hack
git commit
git checkout master          # All works fine...
git merge new_feature        # ...so merge into master. Debug code will be stripped here

您可以在new_feature上快进调试分支，然后删除new_feature分支。

请注意，无论何时更改调试分支，都必须重做伪合并过程。

Answer 4

我们为每个功能或错误修复都有一个单独的分支。然后，当它们经过充分测试后，可以将它们合并回主干。

如果分支变得有点老，可以更新分支。

我们倾向于直接向主干发布微小更改，但是对于更多重大更改，我们将它们收集到一个候选版本分支中，我们将包含更改的所有相关分支合并到该分支中。可以部署和测试这个新分支，以查看组合更改是否会在最终合并回主干并投入生产之前破坏任何内容。

这种方法创建了很多分支，但由于我们将这些分支命名为与我们的问题跟踪系统相关，因此它们很容易跟踪。很容易包含或排除对版本的任何更改。

希望有所帮助

Answer 5

我认为你正在寻找的是git-cherry-pick。这允许您在不执行您描述的rebase舞蹈的情况下应用master上的功能提交。

因为你要删除功能分支，所以你不需要看到我认为的显式合并。

Answer 6

您的工作流程很复杂，因为您要做的事情很复杂。我所知道的没有VCS可以让您轻松维护一些永远不应该合并的更改。它说明了很多关于git的强大功能，你的工作流程并不比它更难。

我假设您的语言具有某种条件编译机制（#IFDEF预处理程序指令等）。如果你将调试代码包装在这些代码中，你会遇到更少的摩擦。

将GIT-SVN调试 - >特征分支转移到中继的最佳方法是什么？

6 个答案: