黃乃林
第一、git主要擅長處理純文本。這也是辦公領域不使用git的最主要原因。計算機編程大部分都用的純文本。純文本，可以方便地比較每次提交修改了哪些內容，還可以進行衝突合併。但是辦公領域絕大多數用的都不是純文本，特別是以微軟的word，Excel為代表。git當然也可以對這類二進制文件進行簡單的版本管理，但絕對不是強項。辦公軟件也有用純文本形式的，比如LaTeX，但是僅見於專業領域，使用的人也不多，門檻很高。
第二、辦公領域編輯文檔的週期往往都比較短。純粹的辦公部門，編輯一個文檔往往幾天，十來天就出來一個文件。如此短的週期根本沒有必要用git這樣的版本管理。這類辦公文檔一旦發佈蓋紅章，通常都是“最終版”。不像軟件，似乎就沒有“最終版”的說法。像QQ的代碼，都已經維護20年了。從來沒有哪個辦公文檔能有這麼長的時間去維護。
第三，辦公領域很少需要多人複雜協作去完成同一個任務。類似著作、重要報告也是重大工程，也需要分工合作。但是往往都是一個人負責寫一個章節，最後統稿，基本上是互不干涉。極少出現軟件編程那樣牽一髮而動全身的情況，至少一個章節出現一個錯別字不會影響其他章節。而軟件的這種複雜性，決定了需要維護代碼的人彼此同步修改的內容，還經常出現一個文件同時幾個人去修改的情況。
第四、git使用比較複雜。我把這個原因放到最後，因為它相對前面幾條，反而是最不重要的。git客觀上使用起來確實有難度，影響了其他領域的人使用。不過，如果git真的適合管理辦公文件，則複雜性不是問題，因為發明一些圖形化界面並不是難事。事實上，我在寫很多代碼的時候，用git還真的很少敲命令，大多數時候使用IDE自帶的(或第三方插件)圖形化界面就夠用了。
犍為真人
1、一個工具再好用但如果推廣給非專業並且需要大量的學習成本，那麼就沒法使用。
2、git主要是通過命令或者工具界面操作，進行協同辦公，共同開發、共同維護。那麼想將此服務推廣給其他非專業用戶，那麼一定要找到一個切入點；簡單易用無邏輯感知的傻瓜式操作，並且是在用戶痛點下手（多人信息填寫到excel、夥伴聚餐菜品錄入）
3、現在能滿足這個痛點的工具已經出來了，它叫石墨文檔，微信小程序就能搜索到。隨叫隨到、簡單易用。
bugstack蟲洞棧
GIT是個開源的分佈式版本控制系統，雖然可以有效、高速地處理從很小到非常大的項目版本管理。
但是，該系統的相關資料少（起碼中文資料很少，大學圖書館很難找到，學的人少）且學習週期相對而言比較長，同時該系統不太符合常規思維，最重要的是它的代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息，因此許多辦公領域不使用gIt。
歡迎採用。（2019.06.22）
科技中國2019
首先，其他領域使用git的一個典型案例是Oreilly的一些作者寫書的時候是使用版本控制系統的。最早的時候使用RCS，CVS，Subversion，後來也大量的在用Git。這些在某些作者的書稿裡面都有記載。
然鵝，這些領域的應用是有重要的前提的。首先Oreilly是一家著名的以技術見長的出版公司，所以他的作者們通常都有很強的IT技術背景。
其次，這些作者無一例外的都是使用英文寫作的。為什麼英文很重要？因為英文和中文的排版習慣很不一樣。英文排版裡面有很重要的軟回車和硬回車的區分。英文作家在寫作的時候通常會根據屏幕的寬度，在適當的地方加入軟回車，造成文字換行，而在段落結束的時候加入硬回車，進入一個新的段落。
這些特性甚至在Emacs和Vim這些最常見的編輯器裡面都會自動完成。作者只要專注寫作，編輯器會自動完成軟回車的插入。
為什麼軟回車這麼重要？讓我們看看下面這一段文字。
例一
然鵝，這些領域的應用是有重要的前提的。首先Oreilly是一家著名的以技術見長的出版公司，所以他的作者們通常都有很強的IT技術背景。 其次，這些作者無一例外的都是使用英文寫作的。為什麼英文很重要？因為英文和中文的排版習慣很不一樣。英文排版裡面有很重要的軟回車和硬回車的區分。英文作家在寫作的時候通常會根據屏幕的寬度，在適當的地方加入軟回車，造成文字換行，而在段落結束的時候加入硬回車，進入一個新的段落。 這些特性甚至在Emacs和Vim這些最常見的編輯器裡面都會自動完成。作者只要專注寫作，編輯器會自動完成軟回車的插入。
然後是下面這一段文字。
例二
然鵝，這些領域的應用是有重要的前提的。首先Oreilly
是一家著名的以技術見長的出版公司，所以他的作者們
通常都有很強的IT技術背景。
其次，這些作者無一例外的都是使用英文寫作的。為什
麼英文很重要？因為英文和中文的排版習慣很不一樣。
英文排版裡面有很重要的軟回車和硬回車的區分。英文
作家在寫作的時候通常會根據屏幕的寬度，在適當的地
方加入軟回車，造成文字換行，而在段落結束的時候加
入硬回車，進入一個新的段落。
這些特性甚至在Emacs和Vim這些最常見的編輯器裡面
都會自動完成。作者只要專注寫作，編輯器會自動完成
軟回車的插入。
很顯然，只有在例二的這種版面中，用Git來管理內容的變化才是有意義的。對於例一那樣的排版，不管是用Git還是用Subversion，都是沒有任何意義的。
不如說我現在修改了這樣一個版本
然鵝，這些領域的應用是有重要的前提的。首先Oreilly是一家著名的以技術見長的出版公司，所以他的作者們通常都有很強的IT技術背景。 其次，這些作者無一例外的都是使用英文寫作的。為什麼英文很重要？因為英文和中文的排版習慣很不一樣。英文排版裡面有很重要的軟回車和硬回車的區分。英文作者在寫作的時候通常會根據屏幕的寬度，在適當的地方加入軟回車，造成文字換行，而在段落結束的時候加入硬回車，進入一個新的段落。 這些特性甚至在Emacs和Vim這些最常見的編輯器裡面都會自動完成。作者只要專注寫作，編輯器會自動完成軟回車的插入。
然後我又修改了這樣一個版本，
然鵝，這些領域的應用是有重要的前提的。首先Oreilly是一家著名的以技術見長的出版公司，所以他的作者們通常都有很強的IT技術背景。 其次，這些作者無一例外的都是使用英文寫作的。為什麼英文很重要？因為英文和中文的排版習慣很不一樣。英文排版裡面有很重要的軟回車和硬回車的區分。英文作者在寫作的時候通常會根據屏幕的寬度，在適當的地方加入軟回車，文字換行，而在段落結束的時候加入硬回車，進入一個新的段落。 這些特性甚至在Emacs和Vim這些最常見的編輯器裡面都會自動完成。作者只要專注寫作，編輯器會自動完成軟回車的插入。
不管是用Git還是用Subversion都只會報告說內容修改了。廢話當然修改了，那麼哪裡不同了呢？ 整個這一段都不一樣了。這不是跟沒說一樣嗎？
但是如果是例二那種的排版，那麼Git會很清晰的告訴你，
這一行
作家在寫作的時候通常會根據屏幕的寬度，在適當的地
和這一行
方加入軟回車，造成文字換行，而在段落結束的時候加
不一樣了。而其他的地方沒有變化。
很顯然，這個才是你想要的結果。但是中文寫作的排版不是這樣走的。所以在中文辦公里面使用Git沒有實用價值。
小和平鴿66
git有使用門檻或者說學習成本，另外其他領域用戶也沒有如程序員寫代碼一般分佈式協同的需求。
對於那些用戶，SVN甚至共享文件服務器就足夠了
Quarterback45
火車軌道為什麼不跑汽車？
投案光榮
舉一個簡單的例子，office都是xml實現的，但是隻能用office套件打開，如果用git管理，衝突了，xml文件裡都是版本差異標記，office套件是無法打開這樣錯誤的xml的，所以你的文檔就報廢了。
kid7157887
GIT是一個源代碼版本管理軟件。GIT誕生之初就是為了管理程序源代碼和分佈式協作，它的主要用戶是程序員、IT技術人員，所以一些操作命令對普通辦公人員來說未必好理解，其次辦公領域的分佈式協作需求可能也沒那麼大，有很多現成的在線文檔工具可使用。辦公領域如果要用GIT勢必對使用人員提出更高的要求，不利於傳播使用。所以辦公領域不常見GIT的使用。
區塊鏈龍門陣
git考慮完整性，但是大多數時候我們並不需要完整的文檔，所以svn更適合管理文檔，git更適合管理項目代碼
網上搬磚頭z
辦公領域svn夠用了吧
