容易被忽视的：代码merge的一些rules

今日比较闲，恰好碰到QQ群内有朋友询问相关问题，正好把这个问题整体说说。

主要讨论下commit的一些rules。可能不是很全，随便想着写的。如果有朋友有新问题请提，我空了来回答下。

问题1：新feature提交到哪？

答： 新feature当然是提trunk, branch不管。等下一次拉分支的时候新的feature就会在新的branch上了。

如果是某个branch单独拉出来测某个feature的，那么需要测试保证这个feature在这个Branch运行OK以后。提交trunk。

PS：到时候提交的时候可能需要重构，因为trunk上代码可能有变。

问题2：Bug correction提交到哪？

答：这个问题得看哪里发现的bug，如果是trunk上面发现的bug，只需要在trunk上fix。如果是在branch上发现的bug，需要在trunk和这个branch都fix，还要找到哪些branch拥有相同功能，并把这个bug再那些branch上fix。 如果是最老的branch上发现的bug，那么需要在所有存活的branch上面fix。

举例：

我在branch A上发现了bug,那么开发需要在branch A,C, trunk上fix。因为AC,以及trunk会包含A的feature。

我在branch B上发现了bug,那么开发需要在branch A,B,C ,trunk上fix。因为ABC以及trunk包含了B的feature。

我在branch C上发现了bug,那么开发需要branch C, trunk上fix。并且跟开发组确认该bug所在功能是否A,B branch拥有，有的话也一起fix。因为A,B不一定包含了C的feature。

我在trunk上的新feature发现了bug，那么只需要fix trunk。(基本trunk的测试重点为新feature.)老feature的修复会由branch的bug发现而被修复。

问题3：merge时候很多文件怎么办？

答：一次merge需要包括所有的文件。比如一个feature开发修改了10个文件，那么这个feature在merge的时候就需要全部10个文件一起Merge。

问题4：merge的时候comments怎么写？

答：每个公司有每个公司的格式，但是基本要包含以下的：

feature ID,feature name, bug ID, bud name. 

  其他的根据各个公司情况做些其他要求。