diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc
index 7196738..a13a5fe 100644
--- a/book/03-git-branching/sections/workflows.asc
+++ b/book/03-git-branching/sections/workflows.asc
@@ -1,63 +1,63 @@
 === 分支工作流程
 
-Now that you have the basics of branching and merging down, what can or should you do with them?
-In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.
+現在你已經熟練了分支（branch）和合併（merge）的基本用法，那麼你能夠或者你應該把它們拿來做些什麼呢？
+在這一節中，我們將會介紹一些得益於輕便的分支功能而常見的工作流程，接著你可以自己決定是否想要將它們整併到你的開發循環中。
 
 ==== 長期分支
 
 (((branches, long-running)))
-Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do.
-This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.
+由於 Git 使用簡單的三方合併（three-way merge），所以就算在一段較長的時間內，反覆把一個分支合併入另一個分支，也不是什麼難事；
+也就是說，你可以擁有一些開放的長期（long-running）分支，分別用於開發循環中不同階段的任務，並且可以經常性地把某些分支合併到其他分支中。
 
-Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch – possibly only code that has been or will be released.
-They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`.
-It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs.
+許多 Git 開發者都喜歡用這種方式來工作，比如只在 `master` 分支中保持完全穩定的程式碼——亦即已經發行或即將發行的程式碼；
+他們還會有其它平行的長期分支，像是 `develop` 用於後續的開發，或者 `next` 用於測試穩定性——這種分支並不一定要一直保持穩定性，不過一旦進入穩定狀態，便可以把它合併到 `master` 裡；
+它也被用來引進已完成的主題分支（短期分支，比如之前的 `iss53` 分支），並確保它們能通過測試而不會引入臭蟲。
 
-In reality, we're talking about pointers moving up the line of commits you're making.
-The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history.
+實際上，我們談論的是隨著提交（commit）不斷線性向前移動的指標；
+在提交歷史中，穩定分支總是落後一大截，而前沿分支則是超前一大截。
 
-.A linear view of progressive-stability branching
-image::images/lr-branches-1.png[A linear view of progressive-stability branching.]
+.一種漸進式穩定的分支用法所呈現的線性觀點
+image::images/lr-branches-1.png[一種漸進式穩定的分支用法所呈現的線性關係。]
 
-It's generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they're fully tested.
+一般而言，把它們想像成工作流水線會比較好理解，當這些提交經過完整的測試後便可以前進到更穩定的流水線中。
 
 [[lrbranch_b]]
-.A ``silo'' view of progressive-stability branching
-image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching.]
+.一種漸進式穩定的分支用法所呈現的「流水線」觀點
+image::images/lr-branches-2.png[一種漸進式穩定的分支用法所呈現的「流水線」觀點]
 
-You can keep doing this for several levels of stability.
-Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch.
-The idea is that your branches are at various levels of stability; when they reach a more stable level, they're merged into the branch above them.
-Again, having multiple long-running branches isn't necessary, but it's often helpful, especially when you're dealing with very large or complex projects.
+你可以不斷地用這種方式擴展出更多層次的穩定性，
+像是某些大型專案還會有一個 `proposed` 或 `pu`（**p**roposed **u**pdates）分支，它會整合那些可能還沒有準備好進入 `next` 或 `master` 的分支；
+而所使用的概念就是讓這些分支處於不同層次的穩定性：當這些分支進入到更穩定的水準時，再把它們合併到更高層的分支。
+再次說明，使用多個長期分支的做法並非必需，但是對於特別大型或者複雜的專案而言是有幫功的。
 
 [[_topic_branch]]
 ==== 主題分支
 
 (((branches, topic)))
-Topic branches, however, are useful in projects of any size.
-A topic branch is a short-lived branch that you create and use for a single particular feature or related work.
-This is something you've likely never done with a VCS before because it's generally too expensive to create and merge branches.
-But in Git it's common to create, work on, merge, and delete branches several times a day.
+然而，在任何規模的專案中使用主題（topic）分支都是有用的；
+它是一種短期的分支，用來實現單一特性或相關工作；
+這是你可能從未在之前的 VCS 中做過的事情，因為建立與合併分支開銷通常太大；
+但是在 Git 中，一天之內多次地建立、使用、合併，和刪除分支是常見的事。
 
-You saw this in the last section with the `iss53` and `hotfix` branches you created.
-You did a few commits on them and deleted them directly after merging them into your main branch.
-This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such.
-You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on.
+你已見識過在上一節中所建立的 `iss53` 和 `hotfix` 分支便是這樣的用法：
+在這二支個分支上做了一些提交，並在合併到主分支後刪除它們；
+該技術可以讓你迅速地且完整地進行內容切換——因為你的工作被隔離在不同的流水線中，使得該分支裡的所有變更都只和它的主題相關；並且在諸如程式碼審核的過程中，它也讓檢視修改內容變得更簡單了；
+你可以在主題分支中保留修改的內容幾分鐘、幾天，或幾個月，等它們準備好之後再將它們合併，而不用在乎它們被建立或工作的順序。
 
-Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your `master` branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch).
-Your commit history will look something like this:
+來看一個例子！一開始在 `master` 上工作（譯註：來到 `C1`），然後為了一個議題切換到分支 `iss91` 上工作一會兒（譯註：`C2`、`C4`～`C6`）；由於想嘗試用另一種方法來解決相同的議題，於是使用 `iss91v2` 分支重新展開工作（譯註：回到 `C4` 再展開新的工作 `C7`、`C8`、`C11`）；之後又回到 `master` 工作了一段時間（譯註：一路來到 `C10`），接著腦中有個不太確定的想法，於是再建立一個新的分支 `dumbidea` 做了一些工作（譯註：`C12`、`C13`）。
+你的提交歷史看起來像這樣：
 
-.Multiple topic branches
-image::images/topic-branches-1.png[Multiple topic branches.]
+.多個主題分支
+image::images/topic-branches-1.png[多個主題分支。]
 
-Now, let's say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius.
-You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two.
-Your history then looks like this:
+現在，你決定使用第二個方案（`iss91v2`）來解決議題；你也把分支 `dumbidea` 的工作內容展示給同事們看之後，發現它是個天才之作；
+接下來，你可以丟棄原來的 `iss91` 分支（會失去提交 `C5` 和 `C6`），然後把那二個分支合併進入 `master` 分支。
+提交歷史將變成這樣：
 
-.History after merging `dumbidea` and `iss91v2`
-image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.]
+.合併 `dumbidea` 和 `iss91v2` 後的歷史
+image::images/topic-branches-2.png[合併 `dumbidea` 和 `iss91v2` 後的歷史。]
 
-We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
+我們將在 <<_distributed_git>> 詳細地介紹各種 Git 專案可能的工作流程，所以在你下次的專案決定採用哪一種分支使用規劃之前，記得閱讀那一章。
 
-It's important to remember when you're doing all this that these branches are completely local.
-When you're branching and merging, everything is being done only in your Git repository – no server communication is happening.
+有一點很重要請牢記：這些分支全部都是本地分支；
+當你在使用分支及合併時，一切都是在你自己的 Git 版本庫中進行的——完全不涉及與伺服器的通訊。
diff --git a/status.json b/status.json
index d73a26c..ca3acfa 100644
--- a/status.json
+++ b/status.json
@@ -30,7 +30,7 @@
       "sections/nutshell.asc": 100,
       "sections/rebasing.asc": 1,
       "sections/remote-branches.asc": 1,
-      "sections/workflows.asc": 1
+      "sections/workflows.asc": 100
     },
     "04-git-server": {
       "1-git-server.asc": 1,