我在源碼控制中維護(hù)點(diǎn)文件的技巧
你是否曾經(jīng)開始使用一臺新的電腦,不管是出于自愿還是因?yàn)榕f的電腦讓你的魔法煙消云散,并且對花了多長時(shí)間才把所有東西都 弄好 而感到沮喪?更糟糕的是,有沒有花了一些時(shí)間重新配置你的 shell 提示符,然后意識到你更喜歡以前的樣子?
對我來說,當(dāng)我決定要在 容器 中進(jìn)行開發(fā)時(shí),這個(gè)問題就變得很嚴(yán)重了。容器是非持久的。開發(fā)工具很容易解決:一個(gè)帶有工具的容器鏡像就可以工作。源碼很容易解決:源碼控制維護(hù)它,開發(fā)是在分支上。但是,如果每次我創(chuàng)建一個(gè)容器,我都需要仔細(xì)地配置它,這就太痛苦了。
主目錄的版本控制
將配置文件保存在版本控制中一直是一個(gè)有吸引力的選擇。但是天真地這么做是令人擔(dān)憂的。不可能直接對 ~ 進(jìn)行版本控制。
首先,太多的程序認(rèn)為把秘密放在那里是安全的。此外,它也是 ~/Downloads 和 ~/Pictures 等文件夾的位置,這些文件夾可能不應(yīng)該被版本化。
小心翼翼地在主目錄下保留一個(gè) .gitignore 文件來管理 include 和 exclude 列表是有風(fēng)險(xiǎn)的。在某些時(shí)候,其中一個(gè)路徑會出錯,花費(fèi)了幾個(gè)小時(shí)的配置會丟失,大文件會出現(xiàn)在 Git 歷史記錄中,或者最糟糕的是,秘密和密碼會被泄露。當(dāng)這一策略失敗時(shí),它就成了災(zāi)難性的失敗。
手動維護(hù)大量的符號鏈接也是行不通的。版本控制的全部原因是為了避免手動維護(hù)配置。
寫一個(gè)安裝腳本
這暗示了在源碼控制中維護(hù)點(diǎn)文件的第一條線索:寫一個(gè)安裝腳本。
就像所有好的安裝腳本一樣,讓它 冪等:運(yùn)行兩次不會兩次增加配置。
像所有好的安裝腳本一樣,讓它 只做最少的事情:使用其他的技巧來指向你的源碼控制中的配置文件。
~/.config 目錄
現(xiàn)代 Linux 程序在直接在主目錄中尋找配置之前,會先在 ~/.config 中尋找。最重要的例子是 git,它在 ~/.config/git 中尋找。
這意味著安裝腳本可以將 ~/.config 符號鏈接到主目錄中源碼控制的管理目錄中的一個(gè)目錄:
set -e
DOTFILES="$(dirname $(realpath $0))"
[ -L ~/.config ] || ln -s $DOTFILES/config ~/.config
此腳本尋找它的位置,然后將 ~/.config 鏈接到它被簽出的地方。這意味著幾乎沒有關(guān)于它需要位于主目錄中的位置的假設(shè)。
獲取文件
大多數(shù) shells 仍然直接在主目錄下尋找文件。為了解決這個(gè)問題,你要增加一層指示。從 $DOTFILES 中獲取文件意味著在修改 shell 配置時(shí)不需要重新運(yùn)行安裝程序。
$!/bin/bash
set -e
DOTFILES="$(dirname $(realpath $0))"
grep -q 'SETTING UP BASH' ~/.bashrc || \
echo "source $DOTFILES/starship.bash # SETTING UP BASH" >> ~/.bashrc
再次注意,這個(gè)腳本很仔細(xì)地做了冪等:如果這一行已經(jīng)在那里了,它就不會再添加。它還考慮到了你在 .bashrc 上已經(jīng)做的任何編輯,雖然這不是一個(gè)好主意,但也沒有必要懲罰它。
反復(fù)測試
當(dāng)你把環(huán)境保持在源碼控制中時(shí),開發(fā)虛擬機(jī)和容器就成了一個(gè)解決方案,而不是一個(gè)問題。試著做一個(gè)實(shí)驗(yàn)。建立一個(gè)新的開發(fā)環(huán)境,克隆你的點(diǎn)文件,安裝,并看看有什么問題。
不要只做一次。至少每周做一次。這將使你更快地完成工作,同時(shí)也會告訴你什么是不可行的。暴露問題,修復(fù)它們,然后重復(fù)。