3.3k 3 分鐘

# 前言 Rebase 如果直接翻譯,意思會是「重新定義基底」。 行為上就有點像是花草樹木長得太亂,要重新修剪嫁接的感覺。 以這個特性來說,我們也可以做到類似分支合併的操作。 比起用文字說明,直接來看執行 rebase 的效果,可能更能體會 rebase 的意義。 老樣子,前面講指令,後面講 Fork GUI。 # git rebase 執行效果示範 這是目前分支的狀況, master 合併了 Emilia 分支,尚未合併 Rem 分支。 此時我停在 Rem ,並且執行這個指令: git rebase master終端機會跑出成功 rebase 的訊息 $ git rebase...
4.6k 4 分鐘

# 前言 相信看完分支的觀念與操作後,還是會有人對分支操作的某些「正常現象」還是會有疑惑,同時也有一些實務上的問題,在之前的文章礙於篇幅而沒有提及。 這篇文章來說說筆者曾經疑惑,或是覺得可以記錄一下的內容。 進入今天的主題: 分支操作常見問題 # 建立分支提交的 commit,不是應該要有「岔路」嗎? 只有在兩個分支分別走向不同的路,才會出現岔路。 這個問題應該是新手初次接觸分支比較不好體會的地方,我們都以為建立了分支發佈版本之後,線圖應該會有另一個顏色進行區分。但實際操作下來,卻會發現新分支的 commit 好像跟原本的分支在同一條線… 像是下圖的情境,開了新分支 dev 執行...
5.7k 5 分鐘

# 前言 開始使用分支之後,總是會需要把開發的內容合併回來的一天。 在使用分支之前,操作的指令不太需要在乎目前所在的分支在哪,儘管執行指令操作資料就是了,不過要執行分支合併的動作,代表我們會去處理「兩個分支」的資料,要在哪個分支執行指令就是一件很重要的事情了! 剛接觸分支合併會遇到的幾個疑問不外乎是這些: 指令該在哪個分支執行? 分支合併之後會發生什麼事情? 進行合併分支是不是一定會發生衝突? 種種的疑問將會在這篇文章解答! 直接進入今天的主題: 分支合併與衝突解決! #...
3k 3 分鐘

# 前言 這篇文章,開始來介紹該如何開始使用分支吧! 一樣介紹完指令之後,來介紹 GUI 的操作方式。 老樣子,我可能會直接在指令操作的內容敘述一些觀念,也請 GUI 派的讀者也稍微看一下指令的內容。 # 使用指令操作分支 跟分支有關的指令需要認識兩個英文單字: branch ,也就是分支本身 checkout , 中文是取出 不過我看著「取出」兩個字,實在想不到他的意義是什麼。 所以 checkout 我會直接把他想成「切換」。 # 查詢分支 若要查詢目前專案中的分支,直接使用這個指令就可以了: git branch$ git branch*...
3.8k 3 分鐘

# 前言 終於可以進入 Git 的重頭戲,分支篇! 分支是 Git 極度重要的功能之一,因為有了分支的各種運作,Git 的世界才會變得如此精彩。 同時也會讓我的文章變得很難解釋 在 Git 中要操作分支是一件非常簡單的事情,無論是建立分支、切換分支、分支更名稱,基本上只要簡單一個指令,或是點幾下 GUI,就能完成。 不過在實際學習操作之前,想先用一篇文章的內容,幫大家先建構好看待 Git 分支應該有的觀念,避免在直接學習操作的過程,不知不覺對分支建立錯誤的印象。 接著就來聊聊「為什麼要使用分支」,以及「分支到底是什麼」吧! #...
6k 5 分鐘

# 前言 git reset ,一個之前文章時不時會出現的字詞,但當時文章又一直不認真說明。 看看這篇文章右手邊的滾軸有多小,你大概就能體諒我為什麼當初對 reset 一直要說不說的了 Orz… 在開始介紹 reset 用途之前,有幾個先備知識複習一下,對後面的內容理解可能會有幫助。因為觀念很重要,後續還是會繼續提及。 之前把 「暫存區 (索引)」比喻成「購物車」,接著我們把 「提交版本」 比喻成 「商品下單」,這可能讓讀者以為「提交版本」之後,「索引」就會被清空。 不過在 Git 中,提交版本的行為「不會」清空索引裡面記錄的資料! 提交版本 更貼切的想像,應該是把 commit...
3.7k 3 分鐘

# 前言 有時候我們在執行完 commit 之後,發現有一些「小地方」應該也要記錄在同一個版本,或是發現版本訊息有錯字想要改一下,這些都算是很常見的狀況,畢竟只要是人都一定會有小疏失。 「雖然」 之前把 Commit 訊息比喻成訂單紀錄,在網購世界想操作歷史訂單,只要找到特定訂單就能修改。 不過在 Git 的世界,除了最新一筆的 Commit 之外, 沒辦法 「單獨修改」 其中一個 Commit 。 原因其實也很簡單:每個 Commit 都是緊緊相依的! Git 的 Commit 視同「資料的變化」,每一版的「變化」都是跟「上一版」相比,更動歷史的 Commit...
3.6k 3 分鐘

# 前言 我們在開發專案時,不太可能一帆風順,永遠依循著 開發完 => 暫存 => 提交 的順序持續上版。 有時候手速一個太快,只是想暫存部分檔案,結果執行到 git add . ,但實際上並不是想暫存所有更動的檔案,有沒有辦法將部份內容移出暫存區? 像是一股腦把所有東西加到購物車,結帳前看到總金額嚇了一跳,想把部分商品移除購物車的行為。 又或者開發到一半發現改爛了,能不能一次捨棄編輯的資料,讓檔案回到原本的 commit 狀態? 就像是之前提玩遊戲下完存檔點後,繼續打 Boss...
2.1k 2 分鐘

# 前言 這篇文章的內容,原本是想放在 commit 的常見問題。 結果當時寫完發現內容太多,如果全部塞到同一篇文章,應該會讓人看不下去。 不過這篇文章記錄的兩個問題,可能會是已經學會版控一段時間之後,或是實務上真的遇到時,才會去思考的問題。 很適合拿來當【一起學 Git 吧!】系列文章,中場休息的小品文閱讀。 我們就一起來看看吧! # 每個 commit 的資料都只有專案「部分」的檔案,每個版本不是應該都要版控「所有」檔案嗎? 這問題可能一時之間不好理解,容許我重新描述一下問題的意思。 開始在執行版控之後,commit 的內容可能會是這樣: 第一版:新增專案說明檔案,記錄一個檔案:...
3k 3 分鐘

# 前言 基本指令外加一些輔助操作,到目前為止應該算是介紹完畢。 在開始進入下一個主題之前的 幾篇 文章,我打算來聊聊一些能承上啟下的觀念。 對… 大概會有一兩篇都是閒聊性質 這些觀念跟指令沒什麼關係,但是如果沒把他搞懂的話,卻會 直接影響 部分指令的操作。 由於筆者不太喜歡在主要內容中穿插各種補充讓文章失焦 雖然已經…,於是乾脆把一些觀念與問題獨立出來聊。 希望大家能因為這幾篇文章更認識 Git ,同時可以在開始介紹其他操作之前,奠定一些概念。 # 聊聊 CommitID 我們再次把這個線圖請出來,並且把關注點放在最右邊的 CommitID 。 這些字母「看起來」很沒意義,不過它卻是我們在用...