**小组：GS07E15gDAMA **
至此，我组摸索的Git-hub在和合技中的应用模式，已经初步完成。

特别鸣谢：
ZoomQuiet 他是知识的源头，他引领小组，溯着他的已知，到达我们的未知。他完善正确，他修补缺损，他否决弯路。

安心竹 她稳重大气，脚踏实地。她说，先空格，再递交。她四两拨千斤，为疑惑找到解决方案。

一坪海岸线 她善良温润，柔韧亲和。她说，逐行空格，便可评论。她心思细致，将小组的声音，在云端安放。

申小七 他扬鞭飞奔，磐石无转移。他敦促节奏，靠谱真坚实。他说，还是要强调第一作者，于是［B-C模式］的出现得到有力的支撑。

和合技Github应用扼要

1. 开放式咨询，交流思路和意见－－C-C模式
   C-C模式的说明，请参考 「私塾7.1/36」和合技C-C模式

2. 颠覆性提案，强调整体效果－－BC模式
   B-C模式的说明，正是本文的主要内容

3. 应保证［BC模式］下的所有版本可进行开放性咨询，符合C-C模式

4. ［BC模式］的触发机制和版本说明，应根据不同和合题目的需求进行规约，在破题环节解决，因地制宜。

BC 模式规约

BC 模式定义

1. BC 模式，即大装修模式。
2. 大装修模式是使第一作者和其他修订者获得更直观的整体修改效果体验的和合模式。操作方法是，修订者通过edit界面对原文进行整体修改，然后commit递交。
3. 简写：［Big Change Model］简称 ［BC模式］

BC模式正文格式规约：

1. 要求尽量每行都修改，或通过逐行空格，使得装修后的新版，能够以[C-C模式]开放咨询。
2. [C-C模式]在大装修模式版本中的应用，可以使大装修后的新版本能够被逐行评论，同时统一所有历史版本的格式，保持美观。

BC模式 与 C-C模式的协同条件

1. [C-C模式] 精髓是开放式咨询，即意见交流，修订者可以通过评论，描述其修改思路，方便修订者与第一作者，以及修订者之间的多边交流。 ＊注：第一作者，[first-editor]-简称[fE]

2. ［BC模式] 精髓是颠覆性提案效果，即修订者使用edit界面，按照自己的思路将原文修改后，呈现更为直观的整体效果，并将之其提交为新的版本［commit］，以供fE 参考，并请其他修订者审阅及评论。

3. ［BC模式] 产生的新版本，应当采用[C-C模式] ，使得新版本对fE及所有修订者开放咨询，［BC］版全文可以逐行被评论。

4. 只要有版本说明的细致规定，即［Commit Logging 规约]，[C-C模式] 和［BC模式]可以协同混用。因此 ［Commit Logging 规约] 是 [C-C模式] 和［BC模式] 的协同条件。

BC模式下Commit-Logging 规约 － 版本说明

扼要：fE_Vn_En_date

1. 引入“成稿” 概念--用 [Vn, n=1,2,3...] 表示

“稿”的概念其实在C-C模式中已经提到，当github应用在文字和合中，在gh预设的“版本commit”概念之上，应当有一个手动认证的“稿”的概念，高于版本。

引用[C-C模式] 说明
在github“版本”概念基础之上，commit-comment和合模式提出整合多个“版本”的“成稿”的概念。即，通过时阶性禁用edit功能，用更佳清晰的comment功能来记录和合过程。避免github形成无效的新版本，将修改版本“隐藏”化，形成更层次分明的“成稿”迭代。类似photoshop中的合并图层，跨越历史记录的时序，强调经过和合之后，文章当下的整体效果。如果没有此成稿概念，很难再github中对版本进行分类分层

因为很容易出现就为了改一个字就出现了一个新版本，或者仅仅改了一个名称就出现新版本的情况。多重无效版本堆积在commit history中不利于开放咨询。

因此，我们赋予第一作者决定现在是第几稿 （Vn, n=1,2,3...）的权利，手动体现在第一作者命名的版本说明中。

例如：

fE(小七)跑步文 - V3 第三稿 - C-C模式开放咨询

＊注：其实最理想的名称应当为 fE(名称) -V3- C-C， 但因为该模式尚在摸索阶段，我们鼓励成员将汉语提示著明在版本说明中，以提高效率。

2. 引入［大装修版本序号］概念--用 [En, n=0,1,2,3...] 表示

BC模式版本说明[Commit Logging]公式： fE-Vn-修订者En-date

例如：

fE(小七)跑步文-V2第二稿-小宋大装修版 E1

这时，大妈想对小宋大装修版进行再次大装修，则大妈再次大装修的版本名称应为：

fE(小七)跑步文-V2第二稿-小宋E1-ZQ E2 - 20170311

然后竹子又来了，想对大妈再装修版进行三装修，于是版本名称应该为：

fE(小七)跑步文-V2第二稿-ZQ E2-竹子E3 - 20170311

然后海岸线来了，想对竹子的三装修版进行四装修，于是版本名称应该为：

fE(小七)跑步文-V2第二稿-竹子 E3-海岸线 E4-20170311

直到第一作者fE(小七)将版本名改成：

fE(小七)跑步文-V3第三稿-C-C模式开放咨询-20170312

＊注：
i. 只有fE可修改[Vn, n=1,2,3...] 的数值, 即成稿的序号，修订者只能改 [En, n=0,1,2,3...] 的数值，即大装修版本的序号。 在例子中，“成稿”的序列号“三”，是fE (第一作者) 小七决定的，所有修订者不得修改。

ii. 理论上不需要著明［小宋大装修版］，因为修订者的署名会自然显示，而[En, n=0,1,2,3...] 本身就代表大装修版［BC MODEL］，但但因为该模式尚在摸索阶段，我们鼓励成员将汉语提示著明在版本说明中，以提高效率。

3. 其他说明

i. 如果在code入口，看到的是［BC模式］的版本说明[Commit Logging]，则可以通过history回到fE发布的[C-C模式]。即：
code --> cimmits --> ［BC模式］最新版本
code --> file --> history --> 当前文本的所有版本
通过两个维度的转换，实现[C-C模式]和［BC模式］的协同。

ii. 本着加速和合的原则，理论上应当规定，所有后来修订者，应该针对同一成稿序号（Vn, n=1,2,3...）下的两类文稿(C-C模式和所有En序列)均进行和合。

例如：

只要最新序号是第三稿，修订者既要评论第一作者的开放咨询，也须就其他修订者的大装修版进行评论，此外还可以自己完成一个装修版。

但这三个和合的可能性均不做强制执行，有话想说才需要和合，没话说，就保持沉默。爱用哪个或哪几个方式，就用哪个或哪几个方式，今日不想评论也ok。