放着,我来 by zhongl

一个简单易行的Gitlab项目分支管理办法

master
   + -----> release/1.0                                     (1)
   |            + ------------> issue/1                     (2)
   |            |                  |
   |            | <----- MR ------ +                        (3)
   |            |                                           (4)
   + <--- MR ---+                                           (5)
   |  <tag:v1.0>                                            (6)

我的开源经历

开源并不是多么牛逼事情,至少在我今天看来是这样的。

为什么还值得拿出来一说,是因为没有参与其中的人都只看到了开源的结果,而完全不了解产生的过程。 这其中发生哪些有趣事情,又是怎样的机缘巧合,一切的细节是值得耐人寻味的。

我所经历的单元测试的三个境界

最开始测试也就是代码写完后运行一下看有没有什么问题。那个时候不会认真的去想要测试什么,因为问题会自己找上门来。:P

public class Killer {
  public void doAwsomeThings() { ... }

  public static void main(String[] args) throws Exception {
    System.out.println("Start...");
    new Killer().doAwsomeThings();
    System.out.println("Ended");
  }
}

写个 main 就可以跑起来看看打印出来是不是自己期望的。不出意外的话, 一般是各种异常堆栈会最先出现。囧rz

其实我一个人写来自己用的,有没有单元测试,怎么实现单元测试,真的没有那么重要。

如何用 Gitlab 做 Code Review

基于分支的代码 Review

  1. 新建 Issue (无论是 bug 还是 feature), 描述背景或问题,
  2. 本地创建分支 issue/123 (123是 issue 的 ID), 围绕关联 issue 进行 program -> commit -> push,
  3. 新建 Merge Request 从 issue/123master, 并指派给项目 Owner (或合适 Reviewer) ,
  4. 被指派人完成代码审查后, 执行代码合并, 同时删除分支 issue/123 .

微信开发平台本地调式方法

          <WOS>                      <AE>                 <ML>
 +--------------------+         +------------+        +-----------+
 | WeChat Open Server | <=====> | Aliyun ECS | <====> | My Laptop |
 +--------------------+         +------------+        +-----------+