gitlab 培训（可以跨部门培训）

[tobemaster56]

issue 备注小技巧

1. 提及某人，使用@xxxx
2. 提及某个 issue，使用 #0( #后面紧跟 issue number id)
3. 提及某个 Merge Request，使用 !0 ( #后面紧跟 MR number id)

[tobemaster56]

MR 里也能看到相关的 issue 信息，gitlab 内部的互链很方便，便于日后排查相关信息

[tobemaster56]

在 issue 中，提及某个 MR，会有专门的链接可以看

[tobemaster56]

issue 和 wiki 做知识管理和沉淀

[tobemaster56]

内部团队的 Stack Overflow

[tobemaster56]

好用的功能，模板功能。

快速建立 bug 模板等

[tobemaster56]

引用 issue 某条 comment

如果需要引用某个 issue 中的 comment，可以这样做。 点击最右边 3 个点，打开更多菜单，点击 copy link

粘贴在需要使用的地方，这样，点击一下，就可以跳到对应的 comment 锚点，可以测试一下

http://gitlab.shuyun.com/front-end-engineering1/enterprise-stores/ekylin/enterprise-kylin-design/issues/23#note_41956

跳转后，comment 锚点有背景高亮，但不是很明星

[tobemaster56]

gitlab 内部的连续互通。或者有一些 quick action，wiki，里提到某个 issue，某次 MR。

[tobemaster56]

找对了做程序员的感觉

[tobemaster56]

怎么样阅读一个 issue，尤其是一个长 issue

分清角色

[tobemaster56]

快速查找项目，只有这两个是有意义的

• 最近访问过的
• stared 的

[tobemaster56]

67

[tobemaster56]

https://gitlab.shuyun.com/front-end-engineering1/enterprise-stores/ekylin/enterprise-kylin-design/issues/15，从issue 快速跳转到相关联的 MR，高效回溯

[tobemaster56]

关于 issue，我还想再说明一下，最近感受比较深，程序员的正确打开方式，就是通过 issue沟通协作。之前，做业务和产品的时候，没这么深的感受。

我想工作很久了，你一定会遇到过，或者听到过，这些情况

1. 产品跑来问你，这个是什么样的，为什么是这样的。你好像记得和ta 讨论过，具体是什么，记不太清了，爬楼找信息？
2. 当时的代码实现，用了什么奇技淫巧，没有注释的话，后面的人，甚至包括自己，都不太记得为啥那么搞。

要么去翻以前的聊天信息，要么翻代码，花费很多时间，也不一定能得到想要的答案。

所以，和开发有关的，就应该有个完整的记录，这些不应该只是散落在聊天工具里，而是体现在 issue 里。

issue 整的好，

1. 可以在 issue 中找到答案，并且遇到要回答的时候，贴一个链接给别人就好了。遇到扯皮的话，也是证据
2. 可以从 issue 中找到写作的素材和灵感，所以 issue 备注的好， 基本都是 md 语法，可以直接贴在文章里，加速文档写作。
3. 从团队的角度说，尽量避免不要犯同样的错误，Don't repeat yourself。
4. github 和 gitlab 有很多功能比较相似，工作中玩的好，想参与社区开源，阻力会更小。

等等吧，希望大家有想法，都通过 issue 来体现。

[tobemaster56]

在 MR 的描述中，提及某个 issue，合并每个MR时，对应的issue 就会 自动 close

对应的issue里，也会出现相关联的MR

[tobemaster56]

在 MR 中，提及 issue的时候，打出 #，可以直接搜索issue，更方便