我们为即将发布的版本使用一个分支,为下一个版本(稍后)使用trunk。
例如: v1.1 - > v1.2 - >树干 (v1.1正在生产中,v1.2即将发布,后备箱将在接近发布时变为v1.3。)
在处理即将发布的版本时,我们使用SVN(TortoiseSVN)办理登机手续。这样做的问题是,所有签入都必须手动合并到trunk,如果它是一个与以后版本相关的更改(换句话说大多数更改)。
问题在于,当开发人员感到压力时,他们往往会忘记合并。这样做的结果是,在分支中完成的修复可能需要稍后再次修复,因为开发人员忘记将修复从分支合并到主干
在向分支机构办理登机手续时,有没有办法自动将代码合并到主干?
答案 0 :(得分:6)
是的,这是可能的,并且有一个开源项目可以做到这一点!
结帐https://github.com/liveperson/Auto-Merger
我们一直在努力,它可以节省大量时间,并有助于避免所有错过的合并错误。
答案 1 :(得分:4)
不,我会严格劝阻它。您可以通过自动合并来解决许多可能的副作用。
你如何解决冲突?开发越多意味着分支和主干的更多变化,意味着合并时会出现更多冲突。合并必须手工完成。
不受欢迎的合并怎么样?有些东西(比如更改版本号,依赖项等)你不想合并。通过自动合并,您必须反向合并合并,这会导致更多的混淆和工作。
使用SVN 1.5的合并跟踪功能,您将获得良好的信息,并查看是否有人未将他/她的更改合并回主干。你只需要正确使用它。
答案 2 :(得分:2)
你无法真正实现自动化:即使没有彻底的冲突,合并也可能导致无效的代码。
未来改进的两种可能性,按优先顺序递增:
一:提交到主干,让某人在发布分支中挑选修改版本
二:切换到mercurial。 srsly。它非常像svn,并且不可能忘记合并,因为将分支A合并到分支B意味着添加到B 所有提交,这些提交在A中但不在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主人,推送会失败并提示他在重试之前将他之前的合并与主人的新变更合并。
答案 3 :(得分:0)
通常,我们的代码审核流程会记录这样的错误。
我想知道在合并冲突的情况下会发生什么,当发生这种情况时,它将如何解决。
答案 4 :(得分:0)
svnmerge.py将为您跟踪所有合并。
答案 5 :(得分:0)
我认为这是个好主意,我想在一段时间内实现类似的功能。到目前为止,我的想法是使用我们的CI服务器进行合并,然后在检查结果之前运行构建和测试。如果无法自动完成合并(这应该通知某人手动执行),则CI作业失败。
通过合理的测试覆盖率,我怀疑自动化这一点的好处将超过由单元测试未捕获的语义错误合并引起的偶然问题。如果合并的代码部分没有被测试充分覆盖,那么通过评论和失败的工作可能会消除这种情况。
答案 6 :(得分:0)
是的(除了上面的回答我还推荐svn auto merger项目),看看这个名为automerger的酷项目,它已经成功地自动合并了数百个分支机构,数十个项目和数十万次提交到目前为止。
你只需告诉它你的项目以及合并到哪个分支,例如1.0.0 - > 1.0.1 - >主干 - > 1.1.0并且好像它是一个魔术,每次提交到它们之间的任何分支都将被自动合并到前面。它将发送成功/失败的电子邮件通知,更新报告的电子表格,报告的csv文件等,甚至为失败的合并创建jira票证,以便开发人员不会忘记自己合并失败的合并
这里的开源是它的链接
如果您有任何问题或任何问题,请告诉我,我将非常乐意为您提供帮助!