原文来自我在 Segmentfault 的回答:git
我想,如今不少程序员都对 Github 存在误解。github
大多都是以为『虽不明,但觉厉』的样子,觉得有个 Github 账号就算是世界级的程序员了。segmentfault
因为公司招聘有 Github 加分,因此不少人都把 Git 地址贴过去,而后就这样:框架
其中不乏工做 5 年以上的,煞有介事的把 空无一物 的 Github 地址粘贴过去。 我的来讲,我要看应聘者的 Github,就是看你ide
从一个小地方能看出不少东西,我想若是 10 来分钟就能大体了解一我的的水平如何,不是能很好的节省招聘成本,为双方省时间么?工具
如今有不少工做 5 年以上的程序员,Markdown
都不会好好写(我不仇视也不鄙视这样的人,由于都是能够学的)。Github 一个仓库下来总要写个 README.md
的吧?README.md
也能告诉我不少信息:学习
Markdown
水平不说README.md
能让别人省不少事情,一样,一个清晰明了的文档能让 coworker 少不少愚蠢的问题)好久以前,我仍是个无知的菜鸟的时候(固然我如今也很弱,但我知道本身是无知的),我恐惧 CLI(命令行),依赖 GUI(图形工具,IDE 自带),而后勾选修改
-> commit
-> pull
-> merge
-> checkout
,大概就这么多了,这都没有问题的,好歹能用上版本控制了不是?编码
可是我想用 GUI 的人,多多少少没有良好的 Git 使用习惯,conflict
处理粗暴简单,无论提交能不能 Fast forward
,提交就是了,merge develop from xxxx.com into develop
这种粗暴的 merge
?不要紧,TA 不在乎。idea
Git 的学习曲线确实相对陡峭,除了基础的哲学理念让人糊涂,Git 不少陷阱难以轻易的复现,学习起来很是痛苦,它简洁,却又晦涩难懂。你用 git add | git commit | git push | git pull | git merge
以为已经够了,等到你作了一些让队友恨得牙痒痒的事情的时候,你发现那几条单薄的命令只会让你难堪。
没有学会用 rebase,就别出去跟人说会用 Git 了。Git merge
合并让你以为成就感爆棚,可是看看别人是如何优雅的使用 rebase
衍合分支的,内心总归有点儿羡慕吧。
与其哭着从新写一遍,不如了解下 Git DVCS
是用来干吗的。 git reflog
找到本身的提交记录,git cherry-pick [commit hash code]
,喏,代码还在呢。
git rebase --onto
git rebase -i
等到基础差很少了,玩玩这两条命令吧。
相信这样的 commit message 很多见:
我去,大神你写这样的 commit message 给鬼看啊?git log
你看看都是写的是些什么,我真不期望你看着 commit 时间戳就能知道那天你干了什么。
看看别人怎么写的吧:
feat(超文本驱动和资源发现): 增长了 JSON API 方案
fix(请求方法): 更新完资源后应该返回状态码 202
chore(): 增长了补充性质的文件 SUPPLEMENT.md
诶,是不看起来是 readable
了?
Git 不是看两本书就能立地成牛了,是要在平常版本管理与协做中锻炼出来的。
没事给本身常常用的第三方库提几个 issue
,改几个 bug 写几行代码,而后提起 pull request
。
一样的,本身有个好的 idea 也能够写个框架提交在上去,广邀四方英雄来参与你的项目。
这里其实有不少要说的,却发现什么也说不出来了。
哦,忘记重点了,不要怕初级太简单而被人鄙视,谁都是这么过来的。
另外也别光说不练,贴上个人 Github,其实还有不少改善的地方。如前面所说:我知道本身无知,我在努力。;-)