原文來自我在 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,其實還有不少改善的地方。如前面所說:我知道本身無知,我在努力。;-)