如何妥善使用 Github 還有 Git?三個簡單原則讓你效率翻倍

【我們為什麼挑選這篇文章】Git 和 GitHub ,對於一個工程師的能力成長、職涯可以說是非常重要的一件事,而又該怎麼應用這兩個工具最好呢?(責任編輯:林子鈞)

本文經知乎專欄    論智  (公眾號 ID :jqr_AI) 授權轉載

本文不會涉及如何創建 GitHub 配置文件和如何在本地推送 Git 這類具體問題,相反地,首先我們會解釋為什麼用好 Git 和 GitHub 非常重要,然後再介紹三個簡單規則,只要養成習慣,你就能從中受益無窮。

為什麼 Git 和 GitHub 如此重要?

如果你剛開始學計算機,那麼之後你的目標可能就是積累知識,畢業後獲得一份對口工作,比如軟體工程師、數據科學家等。在這種情況下。答案很簡單——

學習怎麼用 Git 和 GitHub 很重要,因為你工作後會頻繁用到它們的概率幾乎是 99%,它們已經成為所有科技公司的標配。所以,如果你想從初級開發人員脫穎而出,你最好在 Git 和 GitHub 上多用點心。

高級開發人員的「高級」之處不是他們對程式語言的語法有什麼更高深的理解,而是他們在實際複雜大型項目上有更多經驗。

而如果只是個剛入行的新人,你是很難獲得這種體驗的。經驗來源於生活,來源於實踐。Git 和 GitHub 正是你從實際項目中積累實際經驗的一種好途徑。

話說到這裡,可能你已經認同這些工具對找工作的裨益,那麼剩下的問題就是:為什麼 Git 和 GitHub 對公司也那麼重要?

簡而言之,Git 這個工具允許團隊成員以異步的方式高效、有效地為同一個項目提交開發代碼。人與人之間能更好地協作,團隊能解決的問題自然也更大更複雜。這是一個分佈式版本控制系統,它提供還原更改、創建代碼分支、解決代碼合併衝突等機制——這些都是非常有用的功能,可以幫助解決團隊每天都會遇到的常見問題。

而對於這些問題,Git 是當前最好的解決方案。

另一方面,GitHub 是通過 Git 進行版本控制的軟件源代碼託管服務,它為各類特定問題、常見問題提供解決方案,例如 Code Review、pull reqeust、問題管理/ bug 跟蹤等。

說明:即便 Git 是大多數公司的首選版本控制工具,GitHub 還是有一些強大的競品的,如 GitLab 和 Bitbucket。事實上,之前 GitHub 被微軟收購時,已經有少數開發者把自己的代碼庫遷移了出去,但現在 GitHub 還是主流。如果你已經熟練掌握怎麼用 GitHub,你會發現自己用 GitLab 和 Bitbucket 也不會覺得手生。

Git 和 GitHub 實踐建議:三個簡單規則

因為我個人是 Microverse 的創始人,所以這裡簡單提一下我的教學經驗。Microverse 是一個面向軟件工程師的遠程培訓學校,在給學生上課時,我們不僅會教他們如何寫代碼,也會提供大量指導和規劃,以便他們把課上學到的東西用於實踐。

我們要求學生做的第一件事是遵循以下三個簡單規則,成為 Git 和 GitHub 的專業使用者。但在具體展開前,請先問自己以下兩個問題:

  1. 你熟悉 Git 和 GitHub 嗎?如果不,HubSpot 上有一個值得閱讀的教程。
  2. 您知道 GitHub Flow 是什麼嗎?如果不,先去 GitHub 閱讀官方介紹。

接下來就是這一節的重點:三個規則。

  • 規則一:為每個新項目創建一個 Git 存儲庫。
  • 規則二:為每個新功能創建一個新分支。
  • 規則三:用 pull reqeust 把代碼合併到 Master 分支。

規則一:為每個新項目創建一個 Git 存儲庫

第一條規則很簡單,但養成這個習慣不容易。每當你開始做一個新項目——投資組合、學習項目、競賽解決方案等——你就應該新開一個 Git 存儲庫,然後把它上傳 GitHub。

一個專用的 repo 是為你編寫的每一行代碼使用版本控制的第一步,而版本控制是各大公司處理實際項目的工作方式。因此今早學會這一點並養成習慣,會對你日後發展帶去幫助。

規則二:為每個新功能創建一個新分支

假設你正在開發一個投資組合項目(比如股票債券投資組合),而且想構建一個「聯繫我們」的組件,那麼你應該為這個新功能構建一個專用分支,並給他一個直觀有意義的名字(比如 contact-me-section),然後把所有和這個組件有關的代碼都存到裡面去。

如果你不知道什麼叫分支,可以去看之前推薦閱讀的 GitHub Flow。

通過分支,你就能和其他團隊成員並行處理不同功能,同時保持每個功能的特定代碼和其他功能的隔離。這種方法有助於篩查不穩定代碼,確保合併代碼的高效。

即便團隊裡就你一個人,養成這種習慣也有助於你理順思路,同時在日後的工作中建立起優勢。

規則三:用 pull reqeust 把代碼合併到 Master 分支

默認情況下,在數據庫進行最初的提交後,Git 會創建一個名為 master 的分支。但是,你絕對不應該直接把更改內容添加進去。相反地,你應該用上上面提到的功能分支,然後打開一個新的 pull reqeust,把功能分支代碼和主分支代碼合併。

在實際工作中,有些人可能會在你不知情的情況下查看你的 pull reqeust,並進行代碼審查。同時,GitHub 自己也會對你的代碼做自動化測試,然後向你提交 bug 提醒。也就是說,如果你的代碼和主分支代碼之間存在衝突,它會報錯,而且這個錯不一定是你造成的,團隊中其他開發人員提交的更改也會通知你。

只有在確保自己的代碼已經經過審核、測試和批准的情況下,你才能合併 pull  reqeust,或者負責審核的人會直接代勞。

如果這個項目只有你一個人,那你也要習慣於這麼做,因為這幾乎是每個開源項目的基本工作流程。如果你參與過其他人的項目,那麼踐行這三個規則也有助於你明確自己的貢獻。

也許看完上述內容後,你還有些困惑,但是現在你就可以開始慢慢牢記並養成這三個習慣。不要想著自己該「如何」這麼做,如果你能始終專注於「做什麼」和「為什麼」,你會發現整個過程會變得無比簡單和自然。

原文網址

給工程師

Github 8 月深度學習項目精選 Top 10,第一名是「開源版」Google AutoML

GitHub 上的深度學習專案 Top 200,2018 年最該學的 AI 精華都在這裡了

GitHub 機器學習 100 天自學專案,內容強大學了保證一生平安!

(本文經原作者 論智(公眾號 ID :jqr_AI) 授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈三個簡單規則,助你養成 Git 和 GitHub 好習慣 〉)


邊緣運算的應用可行性在人工智慧技術演進下快速演進
台灣應該如何從中挖出商機,看見未來?

10/12(五)9:30 ~18:00,南港展覽館 504 會議室
把握數位轉型升級關鍵要素

立即購票

點關鍵字看更多相關文章: