mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-31 23:30:11 +08:00
geekpi
GitHub
commit
ec22ac9d09
@ -1,95 +0,0 @@
|
||||
[#]: subject: "My tips for maintaining dotfiles in source control"
|
||||
[#]: via: "https://opensource.com/article/22/2/dotfiles-source-control"
|
||||
[#]: author: "Moshe Zadka https://opensource.com/users/moshez"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
My tips for maintaining dotfiles in source control
|
||||
======
|
||||
When you keep the environment in source control, development VMs and
|
||||
containers become a solution, not a problem.
|
||||
![Person drinking a hot drink at the computer][1]
|
||||
|
||||
Ever started using a new computer, by choice or because the old one let the magic smoke out, and got frustrated at how long it took to get everything _just_ right? Even worse, ever spent some time reconfiguring your shell prompt, then realizing you liked it better before?
|
||||
|
||||
This problem, for me, became acute when I decided I wanted to do development in [containers][2]. Containers are ephemeral. The development tooling is easy to solve: A container image with the tooling works. The source code is easy to solve: Source control maintains it, and development happens on branches. But if every time I create a container, I need to configure it carefully—that's going to be a pain.
|
||||
|
||||
### Revision control at home
|
||||
|
||||
Keeping configuration files in version control has always been an attractive option. But doing so naively is fraught. It is not possible to directly version `~`.
|
||||
|
||||
For one, too many programs assume it's safe to keep secrets there. It's also the location of folders like `~/Downloads` and `~/Pictures`, which should probably not be versioned.
|
||||
|
||||
Carefully keeping a `.gitignore` file at the home directory to manage _include_ and _exclude_ lists is risky. At some point, one of the paths gets wrong. Hours of configuration are lost, big files end up in the Git history, or, worst of all, secrets and passwords get leaked. When this strategy fails, it fails catastrophically.
|
||||
|
||||
Manually maintaining a sea of symlinks also does not work. The whole reason for revision control is to avoid maintaining configuration manually.
|
||||
|
||||
### Write an install script
|
||||
|
||||
This hints at the first clue about maintaining dotfiles in source control. Write an installation script.
|
||||
|
||||
Like all good installation scripts, make it _idempotent_: Running it twice should not add the configuration twice.
|
||||
|
||||
Like all good installation scripts, make it _only do the minimum_: Use whatever other tricks to point to the configuration files in your source control.
|
||||
|
||||
### The ~/.config directory
|
||||
|
||||
Modern Linux programs look for their configuration in `~/.config` before looking for it directly in the home. The most important example is `git`, which looks for it in `~/.config/git`.
|
||||
|
||||
This means the installation script can symlink `~/.config` to a directory inside a source-controlled managed directory in the home directory:
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
#!/bin/bash
|
||||
set -e
|
||||
DOTFILES="$(dirname $(realpath $0))"
|
||||
[ -L ~/.config ] || ln -s $DOTFILES/config ~/.config
|
||||
|
||||
```
|
||||
|
||||
This script looks for its location and then symlinks `~/.config` to wherever it was checked out to. This means that there are few assumptions about where it needs to be inside the home directory.
|
||||
|
||||
### Sourcing files
|
||||
|
||||
Most shells still look for files directly in the home directory. To solve this, you add a layer of indirection. Sourcing files from `$DOTFILES` means that there is no need to rerun the installer when modifying the shell configuration:
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
$!/bin/bash
|
||||
set -e
|
||||
DOTFILES="$(dirname $(realpath $0))"
|
||||
grep -q 'SETTING UP BASH' ~/.bashrc || \
|
||||
echo "source $DOTFILES/starship.bash # SETTING UP BASH" >> ~/.bashrc
|
||||
|
||||
```
|
||||
|
||||
Again, notice that the script is careful to be idempotent: If the line is already there, it does not add it again. It is also considerate of any editing you have already done on `.bashrc`. While this is not a good idea, there is no need to punish it.
|
||||
|
||||
### Test and test again
|
||||
|
||||
When you keep the environment in source control, development VMs and containers become a solution, not a problem. Try an experiment: Bring up a new development environment, clone your dotfiles, install, and see what breaks.
|
||||
|
||||
Don't do it just once. Do it weekly, at least. This makes you faster at it, and it also informs you about what does not work—open issues, fix them, and repeat.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/2/dotfiles-source-control
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hot drink at the computer)
|
||||
[2]: https://opensource.com/tags/containers
|
||||
@ -0,0 +1,94 @@
|
||||
[#]: subject: "My tips for maintaining dotfiles in source control"
|
||||
[#]: via: "https://opensource.com/article/22/2/dotfiles-source-control"
|
||||
[#]: author: "Moshe Zadka https://opensource.com/users/moshez"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
我在源码控制中维护点文件的技巧
|
||||
======
|
||||
当你把环境保持在源码控制中，开发虚拟机和容器就成了一个解决方案，而不是一个问题。
|
||||
![Person drinking a hot drink at the computer][1]
|
||||
|
||||
你是否曾经开始使用一台新的电脑，不管是出于自愿还是因为旧的电脑让你的魔法烟消云散，并且对花了多长时间才把所有东西都_弄好_而感到沮丧？更糟糕的是，有没有花了一些时间重新配置你的 shell 提示，然后意识到你更喜欢以前的样子？
|
||||
|
||||
对我来说，当我决定要在[容器][2]中进行开发时，这个问题就变得很严重了。容器是短暂的。开发工具很容易解决。一个带有工具的容器镜像就可以工作。源码很容易解决。源码控制维护它，开发发生在分支上。但是，如果每次我创建一个容器，我都需要仔细地配置它，这将是一个痛苦。
|
||||
|
||||
### 主目录的版本控制
|
||||
|
||||
将配置文件保存在版本控制中一直是一个有吸引力的选择。但是天真地这么做是令人担忧的。不可能直接对 `~` 进行版本控制。
|
||||
|
||||
首先，太多的程序认为把秘密放在那里是安全的。它也是 `~/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][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/coffee_tea_laptop_computer_work_desk.png?itok=D5yMx_Dr (Person drinking a hot drink at the computer)
|
||||
[2]: https://opensource.com/tags/containers
|
||||
Loading…
Reference in New Issue
Block a user