export DOTFILES_GH_USER=jianingxu1
export DOTFILES_GH_BRANCH=main
bash -c "$(curl -fsSL https://raw.github.com/$DOTFILES_GH_USER/dotfiles/$DOTFILES_GH_BRANCH/bin/dotfiles)" && source ~/.zshrcOr:
git clone https://github.com/jianingxu1/dotfiles.git ~/.dotfiles --recursive
~/.dotfiles/bin/dotfiles
source ~/.zshrcdotfilesJust modify the ~/.dotfiles repository that has been cloned in your machine, and add the commits.
To push the changes, you have to before: Use a personal SSH key for this repository (when you already have a work key) If your machine already uses a work SSH key tied to your company GitHub, pushes from this repo may fail or be attributed to the wrong account. By creating a separate personal key and wiring this repo to use it (via an SSH host alias), you can keep both keys side-by-side without affecting other repos.
- Generate a personal key and add it to your GitHub account:
ssh-keygen -t rsa -b 4096 -C "58917306+jianingxu1@users.noreply.github.com" -f ~/.ssh/id_rsa_personal
cat ~/.ssh/id_rsa_personal.pub
# Add this key to GitHub: Settings -> SSH and GPG keys -> New SSH key- Tell SSH to use this key when talking to a "personal" GitHub host alias:
cat >> ~/.ssh/config <<'EOF'
Host github.com-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa_personal
IdentitiesOnly yes
EOF- Set repo-local identity and point the remote at the personal host alias:
cd ~/.dotfiles
git config user.email 58917306+jianingxu1@users.noreply.github.com
git config user.name "Jianing Xu"
git remote set-url origin git@github.com-personal:jianingxu1/dotfiles.git
# Now pushes from this repo will use your personal key- About this project
- How the "dotfiles" command works
- Hacking my dotfiles
- Aliases and Functions
- Inspiration
- License
I've been using bash on-and-off for a long time (since Slackware Linux was distributed on 1.44MB floppy disks). In all that time, every time I've set up a new Linux or OS X machine, I've copied over my .bashrc file and my ~/bin folder to each machine manually. And I've never done a very good job of actually maintaining these files. It's been a total mess.
I finally decided that I wanted to be able to execute a single command to "bootstrap" a new system to pull down all of my dotfiles and configs, as well as install all the tools I commonly use. In addition, I wanted to be able to re-execute that command at any time to synchronize anything that might have changed. Finally, I wanted to make it easy to re-integrate changes back in, so that other machines could be updated.
That command is dotfiles, and this is my "dotfiles" Git repo.
When dotfiles is run for the first time, it does a few things:
- In Ubuntu, Git is installed if necessary via APT (it's already there in OSX).
- This repo is cloned into your user directory, under
~/.dotfiles. - Files in
/copyare copied into~/. (read more) - Files in
/linkare symlinked into~/. (read more) - You are prompted to choose scripts in
/initto be executed. The installer attempts to only select relevant scripts, based on the detected OS and the script filename. - Your chosen init scripts are executed (in alphanumeric order, hence the funky names). (read more)
On subsequent runs, step 1 is skipped, step 2 just updates the already-existing repo, and step 5 remembers what you selected the last time. The other steps are the same.
- The
/backupsdirectory gets created when necessary. Any files in~/that would have been overwritten by files in/copyor/linkget backed up there. - The
/bindirectory contains executable shell scripts (including the dotfiles script) and symlinks to executable shell scripts. This directory is added to the path. - The
/cachesdirectory contains cached files, used by some scripts or functions. - The
/confdirectory just exists. If a config file doesn't need to go in~/, reference it from the/confdirectory. - The
/sourcedirectory contains files that are sourced whenever a new shell is opened (in alphanumeric order, hence the funky names). - The
/testdirectory contains unit tests for especially complicated bash functions. - The
/vendordirectory contains third-party libraries.
Any file in the /copy subdirectory will be copied into ~/. Any file that needs to be modified with personal information (like copy/.gitconfig which contains an email address and private key) should be copied into ~/. Because the file you'll be editing is no longer in ~/.dotfiles, it's less likely to be accidentally committed into your public dotfiles repo.
Any file in the /link subdirectory gets symlinked into ~/ with ln -s. Edit one or the other, and you change the file in both places. Don't link files containing sensitive data, or you might accidentally commit that data! If you're linking a directory that might contain sensitive data (like ~/.ssh) add the sensitive files to your .gitignore file!
Scripts in the /init subdirectory will be executed. A whole bunch of things will be installed, but only if they aren't already.
- Minor XCode init via the init/10_osx_xcode.sh script
- Homebrew via the init/20_osx_homebrew.sh script
- Homebrew recipes via the init/30_osx_homebrew_recipes.sh script
- Homebrew casks via the init/30_osx_homebrew_casks.sh script
- APT packages and git-extras via the init/20_ubuntu_apt.sh script
- Vim plugins via the init/50_vim.sh script
Because the dotfiles script is completely self-contained, you should be able to delete everything else from your dotfiles repo fork, and it will still work. The only thing it really cares about are the /copy, /link and /init subdirectories, which will be ignored if they are empty or don't exist.
To keep things easy, the ~/.bashrc and ~/.bash_profile files are extremely simple, and should never need to be modified. Instead, add your aliases, functions, settings, etc into one of the files in the source subdirectory, or add a new file. They're all automatically sourced when a new shell is opened.
https://github.com/gf3/dotfiles
https://github.com/mathiasbynens/dotfiles
(and 15+ years of accumulated crap)
Copyright (c) 2014 "Cowboy" Ben Alman
Licensed under the MIT license.
http://benalman.com/about/license/