作為一個寫作者如何使用 Git 版本控制
![](https://linuxstory.org/wp-content/uploads/2024/06/162801m4i1ydc4dkcz6111-800x400.jpg)
我相信當代的寫作者們應該開始思考他們的工作流程了。
在一個注意力高度分散的世界裡,作為寫作者,我們必須對每天執行的任務鏈擁有控制權。傳統上,作家們會把他們的寫作放在分散注意力的事較少、注意力高度集中的時間段。不幸的是,海明威、阿特伍德們的這些建議不再真正適用於我們了。我們所生活的世界聯繫得更緊密了,因此對作家來說就有了更多的陷阱。這首先要求我們要有足夠的自制力,不要讓社交媒體或小狗和小貓的可愛視頻在我們寫作的時候分散我們的注意力。
但是,如果你的寫作需要快速地檢查事實、拼寫不常見和技術性的辭彙等,斷開與互聯網連接並不是一個現實的選項 —— 這正是我寫作時的場景。另一個問題是你用於寫作的應用程序本身的干擾;作為一個長期使用 MS Word 的人,我發現它越來越漂亮,但速度越來越慢,也越來越讓人分心。作為當初我 遷移到 Vim 的主要原因 之一,我曾詳細地談到了這一點,所以我不打算再在這個問題上大談特談。重點是,在現代世界中,在現代設備上進行寫作,可能遠非理想狀態。
因為我已經詳細介紹過了 我為什麼轉向 Vim 和開源版本控制,在這篇文章中,我更想談談該 怎麼做,特別是如何使用開源的版本控制技術,比如 Git(和 GitHub)。
什麼是版本控制?再來一次?
上圖是我們如何進行傳統版本控制的一個說明。這個圖中假設你有一台設備,而且你只在那台設備上寫作。但對我而言,我在許多機器上寫作,包括我的安卓手機和一些不同年代的筆記本電腦,我會在特定的任務、特定的位置使用到它們。我在所有這些設備上進行的一個共同任務就是寫作 —— 因此,我的設備必須以合理的方式捕捉變化並控制文件的版本。不要再讓我將 file1V1_device1_date.doc
作為文件名了。
上圖也沒有考慮到我們用來寫作的工具。像 LibreOffice Write 這樣的文字處理器可以在 Linux、Mac 和 Windows 系統上使用,但在手機上使用文字處理器將會是一段不愉快的經歷。我們中的一些寫作者還使用其他文本工具(包括 Gmail 或我們的電子郵件客戶端)來為我們的寫作打草稿。但按邏輯順序跟蹤所有這些文件和電子郵件是相當折磨人的,我就用這樣的流程寫過一本書,相信我:我花在弄清文件名、版本變化、評論、給自己的注釋以及帶有附加註釋的電子郵件上的時間,足以讓我精神錯亂。
讀到這裡,你們中的一些人可能會正確地指出,有雲備份技術呀。雖然雲存儲的好處是巨大的,而且我也在繼續使用它們,但其版本控制幾乎不存在,或者說並不強大。
一個更好的工作流程
就像地球上的其它地方一樣,大流行病的開始引發了一些焦慮和一些反思。我利用這段時間在 The Odin Project(強烈推薦給那些想學習 html、CSS、JavaScript/Ruby 的人)上自學了網路開發。
在課程的第一個模塊中,有一個關於 Git 的介紹:什麼是版本控制,以及它試圖解決什麼問題。讀了這一章後,我豁然開朗。我立即意識到,這個 Git 正是我作為一個寫作者所要尋找的東西。
是的,更好的方法不是本地化的版本控制,而是 分散式 的版本控制。「分散式」描述的是設備的分布,而我在這些設備上訪問文件,以及之後進行編輯修改。下圖是分散式版本控制的一個直觀說明。
我的方法
我為寫作建立一個版本控制系統的目標如下:
- 使我的稿件庫可以從任何地方、任何設備上訪問
- 易於使用
- 減少或消除因在寫作、學習和編碼各工作流程之間的場景切換而產生的摩擦 —— 儘可能使用同一工具(即 Vim)。
- 可擴展性
- 易於維護
基於以上需求,下圖是我進行寫作的分散式版本控制系統。
如你所見,我的版本控制系統是分散式版本控制的一個簡單的適配。在我的例子中,通過將 Git 版本控制應用到雲存儲(pCloud)的一個文件夾上,我可以同時利用這兩種技術的優點。因此,我的工作流程可以用下圖描述:
優勢
- 我用一個寫作(和編碼)工具
- 我可以對我的手稿進行版本控制,無論我是從什麼設備上訪問文件的
- 超級簡單,幾乎沒有任何不便之處
- 易於維護
缺點
你們中的寫作者一定想知道這個系統存在什麼缺點。以下是我在持續使用和完善這一工作流程時預計到的幾個問題。
- 對草稿的評論:文字處理器的一個更有用的功能是具有評論的功能。當我希望以後再回到文本的某一部分時,我經常在這部分為自己留下一個評論。我仍然沒有想出一個解決這個問題的辦法。
- 協作:文字處理程序允許寫作者之間進行協作。在我以前做廣告相關工作的時候,我會用 Google Docs 來寫文案,然後分享鏈接給我的設計師,從而他可以為廣告和網站對文案進行摘錄。現在,我的解決方法是用 Markdown 寫文案,並通過 Pandoc 將 Markdown 文件導出為 .doc 文件。更關鍵的是,當我的手稿完成後,我仍然需要將文件以 .doc 格式發送給我的編輯。一旦我的編輯做了一些修改並把它發回來,我再嘗試用 Vim 打開它就沒有意義了。在這一點上,該系統的局限性變得更加明顯。
我並不是說這是最好的方法,但在我職業生涯的這個階段,這是對我來說最好的方法。我想,隨著我對我的新的 用於寫作的開源工具 和版本控制越來越熟悉和適應,我將進一步完善這個方法。
我希望這篇文章能為那些想使用 Git 進行文檔版本控制的寫作者提供一個很好的介紹。這肯定不是一篇詳盡的文章,但我將分享一些有用的鏈接,使你的旅程更容易。
- The Odin Project 介紹的 Git 基礎知識
- 開始使用 Git
- GitHub 的 Git 基礎知識教程
via: https://news.itsfoss.com/version-control-writers/
作者:Theena 選題:lujun9972 譯者:piaoshi 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive