為 Git 指令和術詞加上英文附註

Author: YueLinHo

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -1,30 +1,30 @@
 === 分支和合併的基本用法
 
-讓我們來看一個你在現實生活中，有可能會用到的分支與合併工作流程的簡單範例，
+讓我們來看一個你在現實生活中，有可能會用到的分支（branch）與合併（merge）工作流程的簡單範例，
 你做了以下動作：
 
 . 開發一個網站。
 . 建立一個分支以實現一個新故事。
 . 在這個分支上進行開發。
 
-此時你接到一個電話，有個很危急的問題需要緊急修正，
+此時你接到一個電話，有個很危急的問題需要緊急修正（hotfix），
 你可以按照下面的方式處理：
 
 . 切換到發佈產品用的分支。
 . 在同一個提交上建立一個新分支，在這個分支上修正問題。
-. 通過測試後，切回發佈產品用的分支，將修正用的分支合併進來，然後再推送出去以發佈產品。
+. 通過測試後，切回發佈產品用的分支，將修正用的分支合併進來，然後再推送（push）出去以發佈產品。
 . 切換到之前實現新需求的分支以繼續工作。
 
 [[_basic_branching]]
 ==== 分支的基本用法
 
 (((branches, basic workflow)))
-首先，我們假設你正在開發你的專案，並且已經有一些提交了。
+首先，我們假設你正在開發你的專案，並且已經有一些提交（commit）了。
 
 .一個簡單的提交歷史
 image::images/basic-branching-1.png[一個簡單的提交歷史。]
 
-無論你的公司使用的議題追蹤系統是哪一套，你決定要修正其中的議題 #53；
+無論你的公司使用的議題追蹤系統（issue-tracking system）是哪一套，你決定要修正其中的議題 #53；
 要同時新建並切換到新分支，你可以在執行 `git checkout` 時加上 `-b` 選項：
 
 [source,console]
@@ -45,7 +45,7 @@ $ git checkout iss53
 image::images/basic-branching-2.png[建立一個新分支指標。]
 
 你開始開發網站，並做了一些提交；
-因為你檢出了這個分支（也就是 `HEAD` 指標正指向它），`iss53` 分支也隨之向前推進：
+因為你檢出（checkout）了這個分支（也就是 `HEAD` 指標正指向它），`iss53` 分支也隨之向前推進：
 
 [source,console]
 ----
@@ -57,12 +57,12 @@ $ git commit -a -m 'added a new footer [issue 53]'
 image::images/basic-branching-3.png[分支 `iss53` 會隨工作進展向前推進。]
 
 現在你接到電話，那個網站有一個問題需要立即修正；
-有了 Git ，你就不用把你的緊急修正連同 `iss53` 尚未完成的內容一起部署到正式環境；你也不用為了正確地套用修正而先花一大堆功夫回復之前 `iss53` 的修改；
+有了 Git ，你就不用把你的緊急修正連同 `iss53` 尚未完成的內容一起部署（deploy）到正式環境；你也不用為了正確地套用修正而先花一大堆功夫回復之前 `iss53` 的修改；
 唯一需要做的只是切換回發佈產品用的 `master` 分支。
 
-然而，在切換分支之前，留意一下你的工作目錄或預存區裡是否有還沒提交的內容，它可能會和你即要檢出的分支產生衝突，Git 會因此而不讓你切換分支；
+然而，在切換分支之前，留意一下你的工作目錄或預存區（staging area）裡是否有還沒提交的內容，它可能會和你即要檢出的分支產生衝突（conflict），Git 會因此而不讓你切換分支；
 所以切換分支的時候最好先保持一個乾淨的工作區域。
-稍後會在 <<_git_stashing>> 中介紹幾個繞過這種問題的辦法（分別叫做「使用收藏」和「提交的修訂方法」）。
+稍後會在 <<_git_stashing>> 中介紹幾個繞過這種問題的辦法（分別叫做「使用收藏（stashing）」和「提交的修訂方法（commit amending）」）。
 目前先讓我們假設你已經提交了所有的變更，因此你可以切回 `master` 分支了：
 
 [source,console]
@@ -72,7 +72,7 @@ Switched to branch 'master'
 ----
 
 此時工作目錄中的內容和你在解決問題 #53 之前的內容一模一樣，你可以集中精力進行緊急修正了；
-很重要的一點需要牢記：當你切換分支時，Git 會重置工作目錄內容，就像回到你在這個分支最後一次提交後的內容，
+很重要的一點需要牢記：當你切換分支時，Git 會重置（reset）工作目錄內容，就像回到你在這個分支最後一次提交後的內容，
 它會自動地增加、刪除和修改檔案以確保工作目錄的內容和當時的內容完全一樣。
 
 接下來開始緊急修正；
@@ -106,7 +106,7 @@ Fast-forward
 
 注意合併時有一個「Fast-forward」字眼；
 由於你要合併的分支 `hotfix` 所指向的提交 `C4` 直接超前了提交 `C2`，Git 於是簡單地把分支指標向前推進；
-換句話說，如果想要合併的提交可以直接往回追溯歷史到目前所在的提交，Git 會因為沒有需要合併的工作而簡單地把指標向前推進——這就是所謂的「快進」。
+換句話說，如果想要合併的提交可以直接往回追溯歷史到目前所在的提交，Git 會因為沒有需要合併的工作而簡單地把指標向前推進——這就是所謂的「快進（fast-forward）」。
 
 現在你的修改已經含在 `master` 分支所指向的提交的快照中，你可以部署該修正了。
 
@@ -162,13 +162,13 @@ index.html |    1 +
 這次的合併和之前合併 `hotfix` 的情況看起來有點不一樣；
 在這種情況下，你的開發歷史是從一個較早的點便開始分離開來，
 由於目前所在的提交（譯註：C4）並不是被合併的分支（譯註：`iss53`，它指向 C5）的直接祖先，Git 必需進行一些處理；
-就此例而言，Git 會用兩個分支末端的快照（譯註：C4、C5）以及它們的共同祖先（譯註：C2）進行一次簡單的三方合併。
+就此例而言，Git 會用兩個分支末端的快照（譯註：C4、C5）以及它們的共同祖先（譯註：C2）進行一次簡單的三方合併（three-way merge）。
 
 .典型的合併會用到的三個快照
 image::images/basic-merging-1.png[典型的合併會用到的三個快照。]
 
 不同於將分支指標向前推進，Git 會對三方合併後的結果產生一個新的快照，並自動建立一個指向這個快照的提交（譯註：C6）。
-這個提交被稱為「合併提交」，特別的是它的親代超過一個（譯註：C4 和 C5）。
+這個提交被稱為「合併提交（merge commit）」，特別的是它的親代（parent）超過一個（譯註：C4 和 C5）。
 
 .一個合併提交
 image::images/basic-merging-2.png[一個合併提交]
@@ -201,7 +201,7 @@ Automatic merge failed; fix conflicts and then commit the result.
 ----
 
 Git 沒有自動產生新的合併提交，
-它會暫停下來等你解決衝突；
+它會暫停下來等你解決（resolve）衝突；
 在合併衝突發生後的任何時候，如果你要看看哪些檔案還沒有合併，可以使用 `git status`：
 
 [source,console]
@@ -220,7 +220,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 ----
 
 它會列出所有有合併衝突且仍未解決的檔案（譯註：列在 `Unmerged paths:` 下面）；
-Git 會在有衝突的檔案裡加入標準的「衝突解決」標記，因此你可以手動開啟它們以解決這些衝突；
+Git 會在有衝突的檔案裡加入標準的「衝突解決（conflict-resolution）」標記，因此你可以手動開啟它們以解決這些衝突；
 你的檔案會包含類似下面這樣子的區段：
 
 [source,html]
@@ -247,7 +247,7 @@ please contact us at [email protected]
 
 這個解決方案分別採納了兩個分支中的各一部分內容，並且完整地移除了 `<<<<<<<`、`=======` 和 `>>>>>>>` 這些標記行。
 在解決了每個衝突檔案裡的每個衝突後，對每個檔案執行 `git add` 會將它們標記為已解決狀態，
-因為預存動作代表了衝突已經解決。
+因為預存（stage）動作代表了衝突已經解決。
 
 如果你想用圖形介面的工具來解決這些衝突，你可以執行 `git mergetool`，它會呼叫一個適當的視覺化合併工具並引導你解決衝突：(((git commands, mergetool)))