我在源碼控制中維護點文件的技巧

你是否曾經開始使用一台新的電腦，不管是出於自願還是因為舊的電腦讓你的魔法煙消雲散，並且對花了多長時間才把所有東西都 弄好 而感到沮喪？更糟糕的是，有沒有花了一些時間重新配置你的 shell 提示符，然後意識到你更喜歡以前的樣子？

對我來說，當我決定要在 容器 中進行開發時，這個問題就變得很嚴重了。容器是非持久的。開發工具很容易解決：一個帶有工具的容器鏡像就可以工作。源碼很容易解決：源碼控制維護它，開發是在分支上。但是，如果每次我創建一個容器，我都需要仔細地配置它，這就太痛苦了。

主目錄的版本控制

將配置文件保存在版本控制中一直是一個有吸引力的選擇。但是天真地這麼做是令人擔憂的。不可能直接對 ~ 進行版本控制。

首先，太多的程序認為把秘密放在那裡是安全的。此外，它也是 ~/Downloads 和 ~/Pictures 等文件夾的位置，這些文件夾可能不應該被版本化。

小心翼翼地在主目錄下保留一個 .gitignore 文件來管理 include 和 exclude 列表是有風險的。在某些時候，其中一個路徑會出錯，花費了幾個小時的配置會丟失，大文件會出現在 Git 歷史記錄中，或者最糟糕的是，秘密和密碼會被泄露。當這一策略失敗時，它就成了災難性的失敗。

手動維護大量的符號鏈接也是行不通的。版本控制的全部原因是為了避免手動維護配置。

寫一個安裝腳本

這暗示了在源碼控制中維護點文件的第一條線索：寫一個安裝腳本。

就像所有好的安裝腳本一樣，讓它 冪等：運行兩次不會兩次增加配置。

像所有好的安裝腳本一樣，讓它 只做最少的事情：使用其他的技巧來指向你的源碼控制中的配置文件。

~/.config 目錄

現代 Linux 程序在直接在主目錄中尋找配置之前，會先在 ~/.config 中尋找。最重要的例子是 git，它在 ~/.config/git 中尋找。

這意味著安裝腳本可以將 ~/.config 符號鏈接到主目錄中源碼控制的管理目錄中的一個目錄：

#!/bin/bash
set -e
DOTFILES="$(dirname $(realpath $0))"
[ -L ~/.config ] || ln -s $DOTFILES/config ~/.config

此腳本尋找它的位置，然後將 ~/.config 鏈接到它被簽出的地方。這意味著幾乎沒有關於它需要位於主目錄中的位置的假設。

獲取文件

大多數 shells 仍然直接在主目錄下尋找文件。為了解決這個問題，你要增加一層指示。從 $DOTFILES 中獲取文件意味著在修改 shell 配置時不需要重新運行安裝程序。

$!/bin/bash
set -e
DOTFILES="$(dirname $(realpath $0))"
grep -q 'SETTING UP BASH' ~/.bashrc || 
  echo "source $DOTFILES/starship.bash # SETTING UP BASH" >> ~/.bashrc

再次注意，這個腳本很仔細地做了冪等：如果這一行已經在那裡了，它就不會再添加。它還考慮到了你在 .bashrc 上已經做的任何編輯，雖然這不是一個好主意，但也沒有必要懲罰它。

反覆測試

當你把環境保持在源碼控制中時，開發虛擬機和容器就成了一個解決方案，而不是一個問題。試著做一個實驗。建立一個新的開發環境，克隆你的點文件，安裝，並看看有什麼問題。

不要只做一次。至少每周做一次。這將使你更快地完成工作，同時也會告訴你什麼是不可行的。暴露問題，修復它們，然後重複。

via: https://opensource.com/article/22/2/dotfiles-source-control

作者：Moshe Zadka 選題：lujun9972 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive