分享 Awesome Ruby China

liukun_lk · 2018年05月24日 · 最后由 liukun_lk 回复于 2018年06月12日 · 3658 次阅读
本帖已被设为精华帖!

先介绍下自己

我是 2013-11-29 注册的 Ruby China,那也是我知道 Ruby 的时候。或许有些人当初是因为 Rails 能十五分钟创建一个 blog 而被深深吸引,又或许是被 Ruby 的许多语法糖所吸引,又或许公司要求使用 Ruby 😅 。然而我是因为学长说了句:“Ruby 在硅谷很流行。”(原话大概是这样),然后就学了 Ruby 无法自拔。当时大一加入社团,学长要我们在 PHP、Android、iOS、JS、Python 以及 Ruby 几个里面挑选一个(不要问我为什么是这几个,可能当时比较火??),类似加入兴趣小组。你说一个大一的小菜鸟,才知道 C 语言,我怎么知道改选什么啊 😂 ,后来问学长该选什么,然后就有了上面学长说的那句话。

后来学长就开始给我们萌新布置任务,是一个已经毕业的学长给我布置的,没错,后面就只有我一个人学 Ruby。。。

当时看社区的帖子,大部分都是出于懵的状态,很多都看不懂。后来也看了 Wiki 里面关于新手如何入门的几个帖子,但是说实话一直入不了门。而且那时候感觉 Git 这工具要命了,怎么这么难用呢,但是似乎学长们都特别推崇这个东西啊。

大学的前两年时间,似乎一直都在门口徘徊,感觉连入门都困难(其实现在想想其实就是代码写的太少)。直到大三,因为有一门课教 HTML、CSS 和 JS,然后期末老师需要一个平台来验收作业,然后就叫我和几个同学一起开发了这个平台,我主要负责后端这块。当然老师也是学院里面唯一用 Rails 的 😂 ,经过这个项目,算是对 Rails 的 MVC 有了初步的认识。

后来大四开始实习,我觉得那时候才算是我 Ruby 以及 Rails 真正入门以及后来快速的提升的阶段。直到现在,在现在的公司待了两年,回想起当初那段自学的过程,虽然比较坎坷,但中间看了许多技术文章(不只是 Ruby、Rails 的),其实对我后面的学习帮助还是挺大的。最近翻看社区 Wiki 里面的内容,发现有些内容也已经好久没更新了,正好自己最近准备深入学习 Rails,就先把社区里面的所有精华帖都筛选了一遍。由于社区会有「提及该帖」,我就不直接贴在帖子里面了,有兴趣的同学可以去 awesome-ruby-china ,有些筛选不对的地方或者有精彩的帖子推荐的,也欢迎给我提 issue 或 PR。

感想

Ruby China 社区是我每天都必逛的网站,也非常感谢几个管理员悉心的维护着这个社区。而且在我整理帖子的时候,感触最深的就是 Ruby Conf 了,因此我特意把第一届开始的新闻,到最近一次 2017 年的 Ruby Conf 的相关帖子都整理进来了,起初是想看看一个活动从发起、举办到结束都需要哪些流程,然而后面却被一张张照片感染了,深深感觉 Ruby China 不只是简简单单的一个技术交流社区,更是一个好友相聚的场所,在获取技术的同时也能够遇到许许多多有趣的人(或许后者我还做的不够,主要是比较羞涩,没好意思主要搭讪)。

最后

我希望这些筛选的帖子能够帮到你,当然有些内容会因为一些版本的内容不同而过时,在查看的时候也是需要注意时间的。如果想交个朋友的话,也欢迎加我微信:FeelMix 备注下你自己哦。恩,就这样,晚安💤

共收到 67 条回复

Git你需要一个牛逼的GUI。光用命令行,几乎干不了什么复杂的事情。

大三开始学 Ruby,最近也开始看精华帖了,我是上下班的路上看的,刚看完一半,楼主收集的很棒 👏 微信加了你哦。另外同样求同行微信好友,pineswong,随便取个秒懂的备注就行

msg7086 回复

哈,现在用vscode还是很爽的

msg7086 回复

你说反了吧...

msg7086 回复

啥?

很有意义!! 感谢分享!!

这波操作6

msg7086 回复

没用过git gui

不这么放,我都不知道 Ruby China 有这么多精品内容了

huacnlee 回复

其实个人觉得 ruby china 的维基很多都可以更新了 链接也有一些是损坏的。可不可以考虑放开 ruby china wiki 的维护权?这样大家都可以贡献一份力量,还能把平时论坛好的资料都放在 ruby china 的 wiki 上

hooopo 回复

还是感觉大佬们分享了这么多的内容😀

就用 GitHub 协作挺好的。

nightire 回复

是啊,整理的时候发现好多的帖子和回复都有你。也非常感谢你分享的内容

写得很不错!很真诚哈 😀

精品常在

msg7086 回复

啥GUI?真的没用过,求推荐

再加上高手对战帖

Rei 将本帖设为了精华贴 05月25日 11:17

不能给这篇加精啊, 会 stack level too deep 的 !!!@Rei

cqcn1991 回复

SourceTree

谢谢 @danielglh 告诉我用 tig, @dfguo 教我git rebase -i

good job! 👍

YanhaoMo 回复

说反了什么?

teddyinfi 回复

请问你想表达什么?

cqcn1991 回复

可以尝试一下SmartGit,边用边学可以让你学会很多Git的使用技巧。

大一开始学习Ruby➡️现在大四即将毕业,没有从事Ruby方向的工作,但对Ruby不离不弃 discord : laxse#5627 欢迎添加好友 交流分享

Awesome job! 荣幸文章能被收录,一直觉得Ruby-China是技术讨论氛围最好的中文技术社区!

整理的好棒!

楼主厉害~

msg7086 回复

第一次听说git 命令行几乎干不了复杂的事情....

msg7086 回复

记住了:GUI能干的,命令行也能干,GUI不能干的,命令行也能干

hxh1246996371 回复

记住了,学好语文很重要。

我说的是 用命令行,几乎干不了什么复杂的事情,主语是人,说的是人类的能力无法达到充分利用命令行赋予的功能。

你说的是 命令行也能干,主语是命令行。命令行当然都能干,GUI就是代替人类去调用命令行的。

回答牛头不对马嘴,还说什么记住,记个蛋蛋。请好好学习语文,谢谢。

另外,GUI能干的,命令行不能干,命令行能干的,GUI不能干,他们是互相对接的。刀柄能让你握,菜刀不能让你握。菜刀能切肉,刀柄不能让你切肉。

握着一把没有刀柄的菜刀的人,何必去鄙视那些用着有刀柄的菜刀的人呢。

xyuchen 回复

我也是第一次听说,不知道你是哪里听来的。

msg7086 回复

git + tig + sublime/atom/任意编辑器,可以实现绝大部分需求。 git需要的不是GUI,而是使用者的细心研究。

msg7086 回复

你这智商已经基本告别Git了,来来来,说一个你认为命令行干不了的复杂的事情

楼主有点暴躁啊~

Git从来不用GUI, GUI能做到的, 命令行都能做到. 相反, 我见过很多使用GUI的, 在我看来, 他们使用Git的方式跟SVN一样,根本不理解Git的工作模式, 很多Git非常牛叉的特性完全不会用, 暴殄天物.

hxh1246996371 回复

是啊你说得对,我智商不行。

我经常做的事情:Git Flow新建Feature分支以后,日常开发频繁提交,一个分支开发完成或者到一个阶段以后,整理分支提交记录,把涉及多于一个功能的提交拆分,按照功能和页面,代码和测试分开归类重新合并成多个大提交,每个提交测试跑通保证可以单独回滚,最后清理完分支以后从主线Rebase更新然后再Merge回主线。

我不知道你平时是怎么处理这样复杂的操作的,但是我用GUI操作的速度起码可以省掉我用interactive rebase至少80%的时间。可能你手速飞快,每个提交rebase单独编辑stage index再分开commit然后再重新排序提交再squash commits可以一气呵成,然而我做不到。特别是,GUI可视化操作只要点几下鼠标就能可视化编辑stage index就能可视化重排commits的,我为什么要憋屈的去vim和shell来回切?我为什么要浪费我的宝贵时间干这些我不需要干的事情?

还有,能不要再瞎瘠薄捏造我没说过的话吗?

我智商捉急,刚刚才想起git的rebase也是个语法糖,说不定大神你是用更底层的git commit -F来重写提交链的,如果我低估了你的能力,那我十分抱歉。

msg7086 回复

不错啊,你们这样commit记录超整洁的

楼主运气真好,还有身边的老师,学长搞Rails...我就是因为某大我2届的朋友跟我安利Ruby,然后开始学。

先发现入门难度好像挺大的,对于一个小白。后来发现了Rails Tutorial,用来入门...前后仔仔细细刷了3遍发现自己入门了,因为感觉这已是对于小白最好的辅助材料了....之后找到个实习...上路了😅

adamshen 回复

我们项目归我管了以后,我就要求每个Feature的提交记录都要干干净净,方便调试回滚,代码Merge前都必须要Peer Review过。以前招了一堆外国人,佛性提交,坚持只用命令行,但是又只会commit pull push merge,推上来的提交乱七八糟,各种名为root@ubuntu的用户穿插其中,分支纵横交错,Merge节点还偷偷藏着几个冲突处理更改,回头做Blame和Rollback的时候心态都崩了。

msg7086 回复

我觉得工具不是最主要的,主要还是你说的每一个 commit 记录是否能表达清楚做了什么。顺便也是给项目做很好的注释,这样子项目接手过来也能够通过 blame 知道每行代码的功能和作用。而且出问题的时候也能够责任到人。

liukun_lk 回复

工具不是最主要的,但是有一个趁手的工具可以极大地提高效率。

为什么我们会用Ruby on Rails?难道就不能用C或者汇编写网站吗?当然可以,但是用更趁手的工具可以提高开发效率,减少失误。我一开始推GUI也是同样的道理。古人写代码,起手就是汇编,纸带打洞写代码,那是因为他们没有条件用高级工具。现在学编程,谁起手从汇编开始学起的?

我一开始就说,光用命令行,干不了多少复杂的东西。类比到编程也一样,光用C,写不了多少大型网站。这当然不是说C语言写不了大型网站,C当然能写,人家世界级大师水平的大佬,泡在牛逼公司里拿着高薪用C语言写核心业务,当然可以。我们这些普通人呢,为什么不去用PHP Python Ruby Go,而要跑去死抠内存指针和汇编优化呢。

更理想的情况是,我很多Git技巧就是GUI教的。写商业版本Git GUI的人,自己是早就吃透VCS的方方面面,你去用这些GUI,然后看他们是怎么一阵蛇皮走位骚操作的,再吸收回来为自己所用,这才是正确的学习方法。我要是丢给你一个Git Manual,你去看一年都不一定能想通为什么Git rebase是Git commit --author --date -F的一个语法糖。

我进公司之前,他们是这么用Git的:

后来他们觉得单线程开发受不了了,开始用分支,那时候记录是这样的:

而现在我的要求是这样的:

其中一个分支是我带的新人写的,他之前是客服部的,说想来做开发,我带他学了Ruby和Rails,教了他怎么用Git GUI,大概一两个月就能按照要求完成任务了。而之前的那堆蛇皮走线,是好几位Git用了两三年的人搞出来的。

你说我为什么要推GUI?

msg7086 回复

tig算gui么

msg7086 回复

你所指的是一些人因为能力有限, 使用git 的命令行干不了什么复杂的事情, 我们想表达的是,我们使用git 命令行完成了一切复杂的事情. 而你举的这个例子只是一个团队约定和流程的问题, 总结起来还是某些人会不会用命令行、以及git的命令行. 你说git GUI 更适合新手上手做实际的东西, 没有人会和你争论, 这是事实, 但是你要是把git CLI说的一无是处, 那请问, GUI 是怎么完成复杂的操作的, 不是调用Git CLI吗?

msg7086 回复

你这个挺好的,话说 Git 的 GUI 我比较推荐 SourceTree,之前带新人学 Git,用 SourceTree 就好了,掌握思想之后可以把一些操作迁移到命令行提高效率

xyuchen 回复

你说的就是我一开始说的意思,麻烦你爬一下帖子可以吗?我不想一次又一次地纠正语文问题。

hooopo 回复

tig我没用过,看了截图,我觉得应该是处于GUI和CLI之间的位置。也有人管这样的程序叫做CUI。

msg7086 回复

请问你最后的图每次合并分支都是通过 rebase 吗?能分享下你们是按照怎么样的流程走的呢?

liukun_lk 回复

一般每次develop上有新的提交以后,分支都要阶段性地rebase到develop HEAD,保证正在修改的程序和已经提交定稿的程序没有冲突。develop上只提交一些比较简单、浅显的改动,比如修改日志格式、更新gem版本等等不会有太大影响的东西。分支则是先规划好大的模块(通常是一个或者半个功能),然后里面有多个小任务,一般一个小任务(通常是一张页面和一套CRUD)一两个提交,相关的提交整理到相邻位置,或者如果量不大的话就直接Squash掉。页面我一般是前端后台代码一个提交,然后RSpec一个单独提交。如果是lib业务模块的话,则是一小块业务逻辑功能一个提交,可以参考下图:

有时候会遇到一个功能做不完的情况,比如我们曾经出现过一个想上一个大功能,但是最后因为人力限制或者需求不大而腰斩的情况,那就把要留下的功能整理到相邻位置,然后Merge回主线;不要的部分撇开,单独留一个尾巴分支挂在外面,每隔一两个月Rebase刷新一下,等以后功能重开的时候可以继续工作。

我想 @msg7086 这里的要点估计是,使用好用的 GUI 可以“更容易”看到当前整个 repo 的进度(这个也同样依赖于使用者或者 GUI 每次提交前 fetch/pull 要提交到的 branch 的所有最新的 commits ),这样子能够尽量避免“蛇皮走线”的发生。 但其实这就像前面的兄弟说的那样,主要还是个流程控制的管理问题。

zhangkaizhao 回复

我不完全是这个意思,但是我觉得该说的我已经说了,能理解的人也应该已经理解了,不能理解的人不管说什么大概也不会理解,所以我不想再翻来覆去重复那些话了。如果大家想继续讨论的话当然没问题。如果有人还想杠的话我就直接Block得了。时间宝贵,不想浪费在无谓的争吵上。

我的观点是任何一个对Git有比较复杂需求的人都应该用GUI辅助而不是裸撸CLI,从来不会犯错而且手速飞快or闲得没事干的人除外。

困了,睡了。

emacs 的 magit 算 git 的 GUI 吗?

嗯,我只是针对那个“蛇皮走线”来说。不可否认,你提到的 GUI 的好处,也是不难理解的。我想最大的好处应该是直观。然后就是好的 GUI 应该包含一些最佳实践,类似你说的语法糖那样的说法(发现 Ruby 社区大家都很喜欢用“语法糖”这个词),比如对一些常用操作的组合封装,使之成为简单的操作、按钮、菜单,不过我想这也需要 GUI 良好的设计支持,特别是中间某些步骤涉及到网络交互的时候,就像是在处理数据库事务那样,如果 GUI 设计没有做好这些的话,我想有时候也可能会一团糟,因为网络出问题或者服务器开小差那是常有的事情。使用 CLI 去实现一个比较复杂的功能的时候,比如把很多提交压缩成一个大的提交,或者 cherry-pick 很多 commits 等,可能需要多步操作,命令行输入出错那也是常有的事情,这样子的确费时费力,而且也容易出错。理想情况下应该是两者都熟悉,简单的操作使用哪个都无所谓,哪个自己使用更快用哪个,复杂的操作使用更直观更容易的,不过出了问题,估计还是得一步一步来解决,或者干脆整个 hard reset ,然后再从垃圾堆里 cherry-pick 回重要的 commits 😓

git 蛇皮走位很正常。。。

hxh1246996371 回复

花在GIT上的时间真的没什么用。。。用不明白命令行不如用GUI(针对新人)

推荐gitkraken 做的比sourcetree早https://www.gitkraken.com/

yfractal 回复

算吧,因为我现在已经不怎么会用命令行了。。。

msg7086 回复

理解了一下,我的理解是要做出这种提交历史,就是在分支开发的时候时不时地rebase到develop,分支内部squash整理,最后合并分支用merge,是这样吗?

waytohigh 回复

是这样的。时不时这个间隔可以是一两天也可以是一两周,主要是保证迭代开发的基是比较新的,避免开发完成了要合并的时候才发现冲突。分支内部除了要squash以外,也可能会split,比如一个WIP提交里包含两三处更改,可能会先split成多个提交,然后再归类合并。

这个一定要赞

很好奇楼主加入的是哪个大学的怎样一个社团,从大一开始就安排这些学习任务,并且有毕业的学长带 …… 另外求问截图中使用的任务和TODO管理服务是?

dimpurr 回复

杭州的一个学校,主要是学长很有想法和能力;工具的话叫做 trello

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册