需要直接复制Git仓库地址的功能#1924
从产品角度来考虑，还是照顾用户的使用习惯来设计，目前使用了各家仓库管理，都习惯在固定位置找复制仓库地址。
我刚刚使用的CNB的时候也有这个疑问，当然最后还是根据经验，复制的浏览器地址栏里面的地址作为仓库地址来使用。
最后想说的建议还是加上。
以下为个人感受与判断，无意冒犯，如有偏差欢迎指正。
最近的体验让我觉得，CNB 在路线选择上更偏向另起炉灶、强调差异化，并把教育用户放在较前的位置。这种“先差异、再稳定”的节奏，短期看确实更有“年轻化的活力”，但也随之带来迁移与学习成本上升、既有习惯被打断的问题，反而削弱了开发团队的专注度与效率。
从平台属性出发，Git 平台的基调应当是稳重与克制：
先稳重——低迁移成本、尽量保留用户习惯、把时间还给业务；
再差异——在稳固底座之上，逐步释放“有活力”的增值能力。
目前给我的直观感受是优先级有些倒置（玩笑地说，有点“倒反天罡”）：差异化与教育用户在前，稳定性与兼容性在后。
具体建议（不改变“教育用户”，但调整其位置与方式）：
稳定先行：加强对 Git 语义、常见流水线范式、权限/Hook 的兼容；保障“GitHub/GitLab → CNB”迁移默认即低成本。
习惯保留 + 默认友好：在不牺牲安全/合规的前提下，尽量让既有习惯“开箱可用”；对不兼容处给出等价模板与一键迁移。
教育用户前置于关键节点、弱化为“引导 + 校验”：保留“教育用户”，但更多通过模板、最佳实践默认值、自动化检查去“润物细无声”。
差异化渐进式推出：将“年轻化活力”的能力作为可选增强，让团队在稳定落地后自愿上车。
以上是我对节奏与优先级的看法：稳重优先，其次差异；先把成本降下去，再把活力拉上来。期望在不牺牲效率的前提下，让“教育用户”真正成为缩短学习曲线的助推器，而不是额外阻力。
以GitHub为中心设计？
还是以GIT为中心设计？
两者是完全不同的。
比如github-action第一步是clone代码，
在cnb上已经没有这一步了，
如果为了习惯对齐，
就要强行补一个本不应该存在的东西！
随着技术演进，
有的东西就变简单了，甚至不需要了，
比如：cvm 到 docker，
环境管理变简单了，
完全不需要服务器概念，
习惯的变化那是必然的，
技术的进步从来不等人。
更多的简化，
cnb不再需要再配软件源，
cnb不再需要邮件和密码登录，
cnb不再需要webhook，因为webhook第一步得clone代码，
cnb不再依赖邮件通知而是微信通知，
cnb在微信里点击即可登录讨论问题，更简单。
关注中国开发者的习惯和痛点去重新设计产品，
而不是盯着github抄作业，
cnb是全新的东西，
cnb有自己的设计理念，Everythins as Code，
中国开发者是一个非常酷的群体，CNB也是。
github照顾中国用户的使用习惯了么？
中国用户：666
美国用户：LGTM
答案是否定的，那么，
cnb也没必要照顾美国用户的使用习惯！
CNB的远程开发已经足够强大，
直接复制浏览器地址栏本就可以克隆代码，
所以复制独占一个按钮就没那个必要，
弱化复制按钮，省出的位置给知识库，这才是AI时代的GIT。
个人观点，cnb 首先是一个代码托管平台，其次才是其他优秀的特质。感觉应该要照顾用户习惯，或者做好引导。而不是漠视用户需求，一昧按照自己的想法来。
@rzhangsan(Pai2s) 如果你使用CNB只是为了托管代码，不开发？不构建？对此类用户表示抱歉~ 国内已经很多这种纯GIT产品了，不缺CNB这一个。
个人观点，cnb 首先是一个代码托管平台，其次才是其他优秀的特质。感觉应该要照顾用户习惯，或者做好引导。而不是漠视用户需求，一昧按照自己的想法来。
@rzhangsan(Pai2s) 为啥首先是一个代码托管平台🤔。。cloud native build. 。。。怎么就首先是托管代码了🙃
感觉你们都在“我觉得”
“你们觉得cnb 首先是一个代码托管平台”
但其实人家cnb是云原生开发和构建平台，代码托管只是为了实现云原生开发和构建的一个小功能。就像制品库一样，别的代码托管平台有制品库吗？
如果单纯的再做一个“代码托管平台”，那我们何必要选择cnb呢。
我觉得保留可以正常使用的前提下，简化一切不是很必要的功能和按钮，是非常合理的
@rzhangsan(Pai2s) 为啥首先是一个代码托管平台🤔。。cloud native build. 。。。怎么就首先是托管代码了🙃
@imdingtalk(景哈哈) 产品介绍第一条，代码托管
描述一下体验不好的点
每次打开git仓库页面，只有仓库的名称、没有仓库的地址。想要拉去仓库就要找团队成员要git链接，或者从项目url手动拼接出来。好费劲
