作者：覃超
鏈接：http://www.zhihu.com/question/19977889/answer/13539702
來源：知乎
平時就經常實踐. 整個公司的code review就是使用這個. 具體說來, 由於我的project稍微有點特殊,所以我這一年在facebook工作的時候一直在用兩套Code Review工具: Facebook的Phabricator 和 Google的Gerrit (他們都是開源). 我覺得兩個工具都很快,很穩定,然后都有效地提供了code review必備的功能:比如比較任意兩個不同版本, 對任意一行代碼來寫評語, 以及可以很方便地導入和導出代碼到本地機器. 用了將近一年的時間,如果我要給自己的公司選一個工具的話,我會選擇Phabricator. 主要是覺得這個界面很干凈, 然后配色非常好看, 整個感覺比Gerrit要現代化不少. 另外一個方便地地方,就是Gerrit上面只能看到版本做的修改,而無法直接展開整個文件(除非下載), 而這點Phabricator完成得比較好. 還有就是Phabricator上面可以發各種圖片,顯得氣氛比較輕松. 具體你可以在http://Phabricator.com上面注冊一個賬戶,然后去看看eprisetley的diff, 就可以大致了解這個工具的功能和特點. 最后要說的是: 這個工具現在已經開源, 並不屬於Facebook, 而且開發它的首席工程師也已經離開Facebook自己創業. 在加上 AladdinZ 張超 在評論里面說的亮點: (credit屬於他,而且的確也是我用后覺得有很大差別的地方) 1. Phabricator將所有文件的比較直接展開,然后放在一起,方便人閱讀. 而Gerrit只有一個文件列表,然后用戶需要點每一個文件,才能看到具體的修改; 2. admin的權限設置問題. 另外我還想到一點Phabractor比較人性化的地方: Phabricator還可以捆綁unit test和以及格式檢查和規范的工具(e.g. JSLint), 然后用戶在上傳diff的時候, phab會自動用新版本的代碼去跑unit tests,以及運行JSLint, 然后在code review里面就可以看到unit tests有幾個failure和error,以及JSLint的報警信息. 對於Gerrit, 不知道能否類似配置一下.
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：趙戈戈
鏈接：http://www.zhihu.com/question/19977889/answer/24101951
來源：知乎
從 12 年公司老東家成立創新產品團隊開始到目前，Phabircator 已經從只有我們團隊使用到現在老東家全面投入使用。剛開始由於是創新產品團隊，不用受制於公司大環境的束縛，可以自由發揮的空間更多。由於個人比較喜歡玩工具，比如 Trac 和 Redmine 以及 Bugfree 都用過很長時間（當然從來沒有覺得很滿意），正當總是不滿意的時候 Phabricator 進入了視線，經過一些使用和研究，我們決定將傳統的 Subversion + ReviewBoard + Jenkins 切換到 Git + Phabricator 的平台上，暫時拋棄了持續集成部分，輕裝簡從開始了我們新的工具時代。Phabricator 最早是 Facebook 的內部審查工具，看過王淮的《打造 Facebook》都應該知道，Facebook 最厲害的工程師都需要進入工具部門去鍛煉深造，所以質量就不明覺歷了吧。據說后期 Phabricator 在 Facebook 資助下專心做這個，迭代和更新速度都很快，整體界面和 Facebook 的風格簡直是如出一轍（就覺得 Facebook 的傳統風格太像是工具了）。作為資深使用用戶有資格發表點對使用 Phabricator 的一些看法：首先，Phabricator 是基於 PHP + Mysql 的，但是配置起來也不麻煩。個人也曾經貢獻過一些 Bug fix，從代碼上來說 Phabricator 雖然不是我的風格，但風格和寫法上非常不錯。所有的開發都是面向 OOP，資源的管理是分離的很清楚的，配置的管理是多重的（數據庫，文件，默認）等等。高手寫的代碼都值得追隨和拜讀。所以，如果你在做 PHP 建議來讀一讀。其次，傳統的概念上，項目、倉庫和任務都是以項目為主綁定在一起的。而在在 Phabricator，所有這些都不是耦合在一起的。項目就是項目，倉庫就是倉庫，任務就是任務。但所有的東西都是以項目作為線索連接在一起的。一個任務可以屬於多個項目，倉庫的 commit 和 review 只有在提交任務的時候，可以結合進去。如果要想更好的使用倉庫，比如自動 Review，審查 commit，還需要用到 Owners，根據配置，所有人會擁有倉庫的審查權限，所有倉庫的提交也都有 Owners 來進行審核。這種松散的組合，想必和 Facebook 內部開放協作的項目態度是有關的，對於開放的團隊來說非常有好處。<img src="https://pic1.zhimg.com/c20fe9690d437e8ff9907a0a279059e8_b.jpg" data-rawwidth="940" data-rawheight="455" class="origin_image zh-lightbox-thumb" width="940" data-original="https://pic1.zhimg.com/c20fe9690d437e8ff9907a0a279059e8_r.jpg">再者，代碼倉庫的支持很完整。Git，Svn，HG 一個都不落下（什么，你說 CVS，那是什么）。對於倉庫，Phabricator 有很好的自動檢測和拉取機制，你推的代碼，很快它就能收到，根據你定制的規則去指派給相應的人去審核。除了可以審核，查看代碼也非常方便，甚至它本身支持了 ctags 的導入，如果你導入了 ctags ，在代碼中甚至可以用 IDE 中快速定位的方式去查找代碼源自哪里？高亮自然就不用說了，沒有一種語言不支持的，估計新版本連自己的 Haske Lang 都支持。<img src="https://pic3.zhimg.com/ee6064b75e5dcd2246eba696d98485f6_b.jpg" data-rawwidth="1254" data-rawheight="691" class="origin_image zh-lightbox-thumb" width="1254" data-original="https://pic3.zhimg.com/ee6064b75e5dcd2246eba696d98485f6_r.jpg">然后，輔助工具也很豐富，對於開發之外的各種需求來說都可以滿足。比如文檔、圖片審查、倒計時、問答、代碼分享、投票、密鑰管理、日歷、聊天、文件共享簡直是費盡心思。文檔是代碼開發的重要部分，Phabricator 采用了自己編寫的 reMarkup 語法和Markdown 非常相似，但是多了表格，目錄索引，引用自有文件任務等功能，使用上很快就能進入，基本不會有什么問題。簡單說說圖片審查，這塊是我最沒有想到的。不過也解決了一個我們設計的痛點。可以把設計稿提交上來給大家看，你我都可以圈圈點點，提交意見，最終定稿。否則，設計師這個跟開發同性質（需要被產品經理趕）的用戶只能上 Phabricator 看任務。其它的就不多說了，基本都是字面意思，如果你有用到最好，用不到也無所謂，只是輔助。<img src="https://pic2.zhimg.com/0f7e57ef71e7c8c4836efa5a3415c9f1_b.jpg" data-rawwidth="1051" data-rawheight="662" class="origin_image zh-lightbox-thumb" width="1051" data-original="https://pic2.zhimg.com/0f7e57ef71e7c8c4836efa5a3415c9f1_r.jpg">接着，要說下命令行。Phabricator 提供了個命令行叫 arc （Arcanist），總之很方便。它有幾個用處：操作數據（任務查看操作）；開發輔助（gitflow 工作流，查看提交的 diff，代碼檢查，執行單元測試）；輔助（文件分享下載、代碼分享，升級）等等。對於開發來說，命令行再熟悉不過，用好這個命令行可以少上 Web 界面去操作，對工作效率的提升簡直是大贊。<img src="https://pic1.zhimg.com/ce9d8f3989b61ca06eacc9cebc17cfa4_b.jpg" data-rawwidth="565" data-rawheight="354" class="origin_image zh-lightbox-thumb" width="565" data-original="https://pic1.zhimg.com/ce9d8f3989b61ca06eacc9cebc17cfa4_r.jpg">最后，Phabricator 很潮很自由。看看界面上的文字上如果你不去查查字典，估計有不少詞你都不認識，應該不少是出自希臘古語。不過可以通過配置關閉使用正常點的描述。在賬號系統支持上支持的很到位。Github、Facebook、Google 和公司內部的 LDAP 都能支持。Phabricator 的 API 是開放的，基於此你可以做出來很多符合自己需求的東西。Phabricator 也對郵件支持的也很到位，配置好收發郵件后，就可以像 Github 那樣使用郵件來進行工作流。總之。如果你在挑選 Review 系統拿不定主意，看完就果斷入了吧。這套系統是免費的開源的。就先說這么多。
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：代緒
鏈接：http://www.zhihu.com/question/19977889/answer/24122118
來源：知乎
不只是適用於開發，我們產品團隊也將pha用於產品文檔撰寫和項目進度管理pha類似markdown的語法能夠很好的控制文檔格式，在線編輯模式又提高了產品與技術直接文檔信息同步的效率，如果很好的使用郵件訂閱的功能，重要文檔的修改都可以及時的告知每一個相關人員同時，task式的任務指派模式能很好的整理產品需求，將以往Excel管理feature的模式在線化，而且由於task與wiki，code review都在一個系統中，每個task的說明能夠與產品技術說明直接關聯，每個人都可以看到該task的相關進度對於產品經理or項目經理來說，phabricator也是非常好的選擇
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：匿名用戶
鏈接：http://www.zhihu.com/question/19977889/answer/24066695
來源：知乎
正在使用Phabricator，我感覺它是：“真tmd的好”從拋棄jira，將redmine遷移到trac，專心折騰trac兩年，再用上gitlab以后，雖然每個工具定位不同，但是總體感覺沒有一個工具真的是在做“人”做的事情：
1. 溝通，Phabricator上的溝通是主對人，特別是owner這個角色，非常適用於使用快速迭代的團隊。你還在用qq和郵件做報告和推進迭代？2. 合作，Trac上無法merge request，gitlab直接搬github。硬傷就不說了，問題是merge request並非是admin/master的工作，gitlab需要新開一個fork的行為，而Phabricator的audit是非常直觀的：誰是owner，就都可以對此commit進行審核。3. 獨立，trac和gitlab都無法對自身以外的repository進行窺探。於是我在Phabricator上將以前所有trac和gitlab的repository導入。一旦決定拋棄他們，切換到自主hosting就好。同時還支持mirror到源。4. 開放，你有新的皮膚想用？想用fontawesome？開源。自用自改。實踐就是：馬上部署馬上嘗試馬上切換就可以馬上開始使用Phabricator而其他淪落為bugtracing（原本是什么就是什么）。其他工具想不用想。裝個trac加插件話費一個禮拜匹配版本，jira買或者用盜版，gitlab無。
http://www.zhihu.com/question/19977889