我们为即将发布的版本使用一个分支，为下一个版本（稍后）使用主干。
例如： v1.1 -> v1.2 -> 主干 （v1.1 正在生产中，v1.2 是即将发布的版本，trunk 将在更接近发布时变成 v1.3）。
在开发即将发布的版本时，我们使用 SVN (TortoiseSVN) 进行检查。这样做的问题是所有签入必须手动合并到主干，如果它是与以后版本相关的更改（换句话说，大多数更改）。
问题在于，当开发人员压力大时，他们往往会忘记合并。这样做的结果是，在分支中完成的修复可能需要稍后再次修复，因为开发人员忘记将修复从分支合并到主干
有没有办法在分支签到时自动将代码合并到主干？
【问题讨论】：
是的，有可能，而且有一个开源项目可以做到！
查看https://github.com/liveperson/Auto-Merger
我们一直在使用它，它节省了大量时间并有助于避免所有那些错过的合并错误。
【讨论】：
不，我强烈反对它。有很多可能的副作用，您将遇到自动合并。
您将如何解决冲突？发展越多，分支和主干的变化越多，合并时的冲突越多。合并必须手动完成。
不需要的合并怎么办？有些事情（例如更改版本号、依赖项等）您不想合并回来。使用自动合并，您必须反向合并合并，这会导致更多的混乱和工作。
使用 SVN 1.5 的合并跟踪功能，您将获得很好的信息，并查看是否有人没有将他/她的更改合并回主干。你只需要正确使用它。
【讨论】：
您无法真正实现自动化：即使没有直接冲突，合并也可能导致代码无效。
未来改进的两种可能性，按优先顺序递增：
一：提交到主干，指定某人在发布分支中挑选修订版
二：切换到mercurial。呲牙咧嘴。它非常类似于 svn，并且不可能忘记合并，因为将分支 A 合并到分支 B 意味着将在 A 中但不在 B 中的提交添加到 B 中 所有
# alice edits some files and commits two revisions
# into her repository, then pushes them into the master
alice ~/wc/stable % hg ci
alice ~/wc/stable % hg ci
alice ~/wc/stable % hg push
pushing to http://repo/stable
searching for changes
...
# bobby tries to push, but oops, his copy is stale
bobby ~/wc/stable % hg ci
bobby ~/wc/stable % hg ci
bobby ~/wc/stable % hg ci
bobby ~/wc/stable % hg push
pushing to http://repo/stable
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
# bobby must augment his repository such that a push
# to the master will leave the master with a single
# head. this is achieved by pulling changes from
# the master, which will cause *his* repository to have
# two "head" revisions:
bobby ~/wc/stable % hg pull
searching for changes
...
added 2 changesets with 4 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
# he will now merge the heads to reduce them to a single
# head. pushing that into the master will be ok (since
# the result of such a push is a single head)
bobby ~/wc/stable % hg merge
bobby ~/wc/stable % hg ci
bobby ~/wc/stable % hg push
# ok!
您可能会说这与分支之间的合并不同，但在 mercurial 中，每个工作副本实际上都是一个分支，并且这两种情况都由一组命令处理：
alice ~/wc/stable % hg ci
alice ~/wc/stable % hg push
alice ~/wc/stable % logout
# alice went home without merging to trunk
bobby ~/wc/stable % hg pull -u
# alice's changeset is now his (only) head
# he edits a file, commits it, and pushes
bobby ~/wc/stable % hg ci
bobby ~/wc/stable % hg push
# his sole commit goes to the master
# the push is ok since it results in a single head
# bobby goes on to merge stable to trunk
bobby ~/wc/stable % cd ../trunk
bobby ~/wc/trunk % hg pull -u
# pulls changes from trunk master
bobby ~/wc/trunk % hg pull http://repo/stable
# pulls all changesets that are in stable but
# not in (this working copy of) trunk
bobby ~/wc/trunk % hg merge
bobby ~/wc/trunk % hg ci
bobby ~/wc/trunk % hg push
上面的这个工作副本很重要，但陈旧的副本不会咬你：如果 bobby 的 工作副本已过时 WRT 主服务器，推送将失败并提示他在重试之前将他之前的合并与主服务器的新更改合并。
【讨论】：
嗯，这与我们在这里所做的非常相似，但我不知道目前有什么方法可以做到这一点。
通常，此类错误会在我们的代码审查过程中发现。
我想知道在合并冲突的情况下会发生什么，当发生这种情况时，如何解决。
【讨论】：
svnmerge.py 将为您跟踪所有合并。
【讨论】：
我认为这是一个好主意，我想实现类似的东西已经有一段时间了。到目前为止，我的想法是使用我们的 CI 服务器进行合并，然后在签入结果之前运行构建和测试。如果无法自动完成合并，则 CI 作业失败（然后应通知某人手动进行）。
在合理的测试覆盖率下，我怀疑自动化的好处将超过单元测试未发现的语义不正确合并导致的偶发问题。如果合并的代码部分没有被测试充分覆盖，那么即使是这样也可能通过审查和失败的组合来消除。
【讨论】：
是的（除了上面的答案我还推荐svn auto merge project），看看这个很酷的项目叫automerger，到目前为止它已经成功地自动合并了数百个分支数十个项目和数十万次提交。
您只需要告诉它您的项目以及从哪个分支合并到哪个分支，例如 1.0.0 --> 1.0.1 --> 主干 --> 1.1.0 并且好像每次提交都具有魔力中间的任何分支都将自动向前合并。它将发送成功/失败的电子邮件通知，更新报告的电子表格，报告的 csv 文件等，甚至为失败的合并创建 jira 票证，这样开发人员就不会忘记自己合并失败的合并
它是一个开源的，这是它的链接
如果您有任何问题或启动问题，请告诉我，我将非常乐意为您提供帮助！
【讨论】：