一個工程師的筆記天地

# 前言 上一篇文章聊到 rebase 可以用來把分支連根拔起，重新栽種到某個分支上。 而這個重新摘種的方式，會把拔起來的分支線所有 commit 內容全部重新 commit 一次。 這也代表說，我們可以用 rebase 做到：「不要將分支移花接木，但全部幫我重新 commit」，這樣就可以達到「修改歷史資料」的目的。 之前在 --amend 章節有提到，如果要修改歷史的 commit ，牽一髮就會動全身，就很像 rebase 在做的事情，而這篇文章的內容，就是要來說說如何使用 rebase 來修改歷史資料。 老樣子，指令講完講 GUI，觀念會在指令說 雖然今天的內容寫完指令…...

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

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

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

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

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

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

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

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

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