版本控制系統的重要性在現今的軟體開發專案中,已經是不可缺少的重要環節,而選用 GIT 作為版本控制系統的比例不在少數。
自己及團隊使用 GIT 作專案的版本控制工具已有幾年的經驗,也曾經協助團隊從無到有導入,在這些與團隊夥伴協作專案的經歷中,也會遇到夥伴詢問操作上的問題,久而久之便累積了一些教學上的經驗。
這些經驗中,其中有一部分屬於基礎操作沒問題,懂得使用 add、commit、pull、push 指令,但在遇到相對複雜的情境,如遇到版本控制的衝突解決、分支的建立合併時、只有 CLI (Command-Line Interface) 而沒有 GUI (Graphical User Interface) 可以使用時,就嚇的吃手手,進入不知道該怎麼處理的窘境。這些狀況,在討論後發現,原因常常是在學習初期對於 GIT 底層的原理知識知其然而不知其所以然,不夠熟悉每個指令的背後發生了什麼事情所致。
因此,我想將自身累積的相關經驗,嘗試透過樂高積木製作的過程說明來描述 GIT 版本控制,用不一樣的角度,讓更多 GIT 使用者更容易了解指令的底層,進而不再害怕面對較複雜的情境。
這系列「用樂高玩轉 GIT 版本控制」文章,預計將包含但不限於以下的部分:
使用「包含但不限於」是因為,這次的開賽,是男子漢的挑戰,有那麼一點莽撞,沒有任何的庫存稿,也因此還沒完賽前,寫作上有很大的彈性,要寫些什麼都還很可以討論,因此持續的調整修改架構也是必要的,當然,也可能會根據留言回饋做一些調整,整體的目的就是想發大財實驗看看,用不一樣的描述方式,是不是真的可以幫助一些讀者,真的更容易而仔細的認識 GIT 這好工具。
在正式開始之前,如果對於我過去對於 GIT 的介紹簡報有興趣,歡迎參考以下的幾個連結,所有的簡報都有附上當時的錄影紀錄:
以上是我目前對於 GIT 的相關簡報與錄影。如果有興趣,有想要討論的內容,也都可以透過留言讓我知道。歡迎明天一起進入 Day 01 - 為什麼是樂高與 GIT 呢?
如果 今天看完一系列文 ,希望可以 從單機模式 變成 多人模式。
現在 我是只會一些基礎指令
單機模式 就是 每個程式碼都自己寫,不是協作的那種
之後 如果處理的規模 一大,感覺一定會碰到 如何多人進行同一份的專案版本控制
麻煩大哥了 !!!
這系列的規劃,直到 Day 18 才開始與遠端的共用儲存庫有互動,而後才開始提 fetch, push 等指令,目的就是為了,等待本機的指令真的夠了解之後,才開始面對遠端的使用,因為基礎原理是一樣的。
所以我會認為當開始多人協作之後,只要把原則維持好,基本上使用會是一樣的。當然多人使用上,會開始有一些「流程」方便團隊作測試、驗證、正式版本釋出,這些會在最後的幾篇提到。
希望這系列對你有幫助。