有 Github 帐号 ≠ Github

原创
2014/10/23 16:49
阅读数 3.9K

原文来自我在 Segmentfault 的回答:

GitHub 应该放什么类型的代码?

这是一个误会

我想,现在很多程序员都对 Github 存在误解。

大多都是觉得『虽不明,但觉厉』的样子,以为有个 Github 帐号就算是世界级的程序员了。

由于公司招聘有 Github 加分,所以很多人都把 Git 地址贴过去,然后就这样:

空无一物的 Github

其中不乏工作 5 年以上的,煞有介事的把 空无一物 的 Github 地址粘贴过去。 个人来说,我要看应聘者的 Github,就是看你

  • 做了什么项目
  • 编码风格如何
  • 能不能用 Git 做好版本控制
  • commit message 写得怎么样
  • 工程管理习惯
  • 等等

从一个小地方能看出很多东西,我想如果 10 来分钟就能大致了解一个人的水平如何,不是能很好的节省招聘成本,为双方省时间么?

Markdown

现在有很多工作 5 年以上的程序员,Markdown 都不会好好写(我不仇视也不鄙视这样的人,因为都是可以学的)。Github 一个仓库下来总要写个 README.md 的吧?README.md 也能告诉我很多信息:

  • Markdown 水平不说
  • 文档的编写风格决定了我能不能跟 TA 做朋友(无所谓的态度、乱糟糟的文档,我不喜欢这样的程序员,哪怕他水平比我高很多,团队协作的时候他会不在乎很多东西)
  • 把合作对象当做用户来友好对待(一个好的 README.md 能让别人省很多事情,同样,一个清晰明了的文档能让 coworker 少很多愚蠢的问题)

你真的会用 Git?

很久之前,我还是个无知的菜鸟的时候(当然我现在也很弱,但我知道自己是无知的),我恐惧 CLI(命令行),依赖 GUI(图形工具,IDE 自带),然后勾选修改 -> commit -> pull -> merge -> checkout,大概就这么多了,这都没有问题的,好歹能用上版本控制了不是?

但是我想用 GUI 的人,多多少少没有良好的 Git 使用习惯,conflict 处理粗暴简单,不管提交能不能 Fast forward,提交就是了,merge develop from xxxx.com into develop这种粗暴的 merge?没关系,TA 不在意。

Git 的学习曲线确实相对陡峭,除了基础的哲学理念让人糊涂,Git 很多陷阱难以轻易的复现,学习起来非常痛苦,它简洁,却又晦涩难懂。你用 git add | git commit | git push | git pull | git merge 觉得已经够了,等到你做了一些让队友恨得牙痒痒的事情的时候,你发现那几条单薄的命令只会让你难堪。

rebase 是什么东西?好吃吗?

没有学会用 rebase,就别出去跟人说会用 Git 了。Git merge 合并让你觉得成就感爆棚,但是看看别人是如何优雅的使用 rebase 衍合分支的,心里总归有点儿羡慕吧。

不小心 reset --hard 了,代码全没了!

与其哭着重新写一遍,不如了解下 Git DVCS 是用来干嘛的。 git reflog 找到自己的提交记录,git cherry-pick [commit hash code],喏,代码还在呢。

merge 之外,另有一番天地

git rebase --onto git rebase -i 等到基础差不多了,玩玩这两条命令吧。

好好写 commit message!

相信这样的 commit message 不少见:

  • init
  • update
  • merge
  • chore
  • 提交
  • 解决了一些问题
  • 增加了一些功能

我去,大神你写这样的 commit message 给鬼看啊?git log 你看看都是写的是些什么,我真不指望你看着 commit 时间戳就能知道那天你干了什么。

看看别人怎么写的吧:

  • feat(超文本驱动和资源发现): 增加了 JSON API 方案
  • fix(请求方法): 更新完资源后应该返回状态码 202
  • chore(): 增加了补充性质的文件 SUPPLEMENT.md

诶,是不看起来是 readable 了?

分享与协作 —— Github 之真义

Git 不是看两本书就能立地成牛了,是要在日常版本管理与协作中锻炼出来的。

没事给自己经常用的第三方库提几个 issue,改几个 bug 写几行代码,然后提起 pull request

同样的,自己有个好的 idea 也可以写个框架提交在上去,广邀四方英雄来参与你的项目。

这里其实有很多要说的,却发现什么也说不出来了。

哦,忘记重点了,不要怕初级太简单而被人鄙视,谁都是这么过来的。

另外也别光说不练,贴上我的 Github,其实还有很多改善的地方。如前面所说:我知道自己无知,我在努力。;-)

展开阅读全文
打赏
10
158 收藏
分享
加载中
讲的不错13
2014/10/28 09:40
回复
举报
我一般是用 reStructuredText 而不是那蹩脚的 Markdown 。编写提交描述的确是个很有意思的活儿,常常纠结于如何写好,不过只要尽可能地一次提交只保持是完整地解决一个问题的话一般都是没有问题的。
2014/10/27 22:46
回复
举报
3我竟无言以对
2014/10/27 14:59
回复
举报
说的是 我12年注册的 只是老人家的项目 自己没提交过源码 没利用好 惭愧
2014/10/25 20:14
回复
举报
常看到一些commit message可读性差,很是无语啊
2014/10/24 09:54
回复
举报
RyanHoo博主

引用来自“leo108”的评论

多人合作开发同一分支的时候还是不要用rebase
rebase 不是乱用的,对于提交到远程的分支就不要用 rebase。
2014/10/24 09:31
回复
举报
多人合作开发同一分支的时候还是不要用rebase
2014/10/24 08:29
回复
举报
说的对
2014/10/24 08:27
回复
举报
更多评论
打赏
8 评论
158 收藏
10
分享
返回顶部
顶部