scatterd-dotfiles/README.md

263 lines
8.6 KiB
Markdown
Raw Normal View History

thoughtbot dotfiles
===================
2015-09-30 16:33:18 -07:00
![prompt](http://images.thoughtbot.com/thoughtbot-dotfiles-prompt.png)
Requirements
------------
2014-02-07 23:30:11 -08:00
Set zsh as your login shell:
2014-02-07 23:30:11 -08:00
chsh -s $(which zsh)
Install
-------
Clone onto your laptop:
git clone git@github.com:thoughtbot/dotfiles.git ~/dotfiles
(Or, [fork and keep your fork
updated](http://robots.thoughtbot.com/keeping-a-github-fork-updated)).
Install [rcm](https://github.com/thoughtbot/rcm):
2014-01-10 16:05:21 -05:00
brew install rcm
2014-01-10 16:05:21 -05:00
Install the dotfiles:
env RCRC=$HOME/dotfiles/rcrc rcup
After the initial installation, you can run `rcup` without the one-time variable
`RCRC` being set (`rcup` will symlink the repo's `rcrc` to `~/.rcrc` for future
runs of `rcup`). [See
example](https://github.com/thoughtbot/dotfiles/blob/master/rcrc).
This command will create symlinks for config files in your home directory.
Setting the `RCRC` environment variable tells `rcup` to use standard
configuration options:
* Exclude the `README.md`, `README-ES.md` and `LICENSE` files, which are part of
the `dotfiles` repository but do not need to be symlinked in.
* Give precedence to personal overrides which by default are placed in
`~/dotfiles-local`
* Please configure the `rcrc` file if you'd like to make personal
overrides in a different directory
Update
------
From time to time you should pull down any updates to these dotfiles, and run
rcup
2011-08-10 11:32:44 -03:00
to link any new files and install new vim plugins. **Note** You _must_ run
`rcup` after pulling to ensure that all files in plugins are properly installed,
but you can safely run `rcup` multiple times so update early and update often!
Make your own customizations
----------------------------
Create a directory for your personal customizations:
mkdir ~/dotfiles-local
Put your customizations in `~/dotfiles-local` appended with `.local`:
* `~/dotfiles-local/aliases.local`
* `~/dotfiles-local/git_template.local/*`
* `~/dotfiles-local/gitconfig.local`
* `~/dotfiles-local/psqlrc.local` (we supply a blank `.psqlrc.local` to prevent `psql` from
throwing an error, but you should overwrite the file with your own copy)
* `~/dotfiles-local/tmux.conf.local`
* `~/dotfiles-local/vimrc.local`
* `~/dotfiles-local/vimrc.bundles.local`
* `~/dotfiles-local/zshrc.local`
* `~/dotfiles-local/zsh/configs/*`
2011-03-24 13:35:49 -04:00
For example, your `~/dotfiles-local/aliases.local` might look like this:
# Productivity
alias todo='$EDITOR ~/.todo'
Your `~/dotfiles-local/gitconfig.local` might look like this:
[alias]
l = log --pretty=colored
[pretty]
colored = format:%Cred%h%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset
[user]
name = Dan Croak
email = dan@thoughtbot.com
Your `~/dotfiles-local/vimrc.local` might look like this:
" Color scheme
colorscheme github
highlight NonText guibg=#060606
highlight Folded guibg=#0A0A0A guifg=#9090D0
If you don't wish to install a vim plugin from the default set of vim plugins in
`.vimrc.bundles`, you can ignore the plugin by calling it out with `UnPlug` in
your `~/.vimrc.bundles.local`.
" Don't install vim-scripts/tComment
UnPlug 'tComment'
`UnPlug` can be used to install your own fork of a plugin or to install a shared
plugin with different custom options.
" Only load vim-coffee-script if a Coffeescript buffer is created
UnPlug 'vim-coffee-script'
Plug 'kchmck/vim-coffee-script', { 'for': 'coffee' }
" Use a personal fork of vim-run-interactive
UnPlug 'vim-run-interactive'
Plug '$HOME/plugins/vim-run-interactive'
Add more Git hooks, delegate to .local convention The `pre-commit` and `prepare-commit-msg` git hooks can be used for some interesting things such as linting files. For example, I need to format, vet, and lint Go files: https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commit https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg We've rejected Go-related pull requests to thoughtbot/dotfiles due to not doing enough "official" Go work at the company. This change helps me start with `.local` for now, and then promote to "upstream" (thoughtbot/dotfiles) at some point in the future if we do more "official" Go work. I'm a believer in having linting done at VCS "commit time", either locally in a pre-commit so I have a chance to fix things and not both my teammates with linting issues, or at post-commit time via Hound comments (also automated, but opportunity to ignore). I've tried adding linting libraries to my editor, and found them too slow, at least for Ruby. I've limited "editor-time" checking to just syntax checking via Syntastic. The downsides I see to adding linting to the test suite are: * Style violations are not functional failures and logically shouldn't fail a build. * Adding code coverage, linting, etc. to a test suite slows down the build. * I only need to lint my diff (the commit), not the whole codebase, when I make changes. * Style violations should not prevent a user-facing, production deploy. * Adding linting to the test suite can slow that process down unnecessarily, particularly in continuous integration setups. I see the appeal of linting in the test suite, particularly for greenfield apps where we have total control, but I don't think it's a practice that we can universally apply to our client projects who have different deploy setups and existing codebases. So, I prefer the git hooks + Hound approach as a pragmatic middle ground.
2014-09-04 14:48:20 -07:00
To extend your `git` hooks, create executable scripts in
`~/dotfiles-local/git_template.local/hooks/*` files.
Add more Git hooks, delegate to .local convention The `pre-commit` and `prepare-commit-msg` git hooks can be used for some interesting things such as linting files. For example, I need to format, vet, and lint Go files: https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commit https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg We've rejected Go-related pull requests to thoughtbot/dotfiles due to not doing enough "official" Go work at the company. This change helps me start with `.local` for now, and then promote to "upstream" (thoughtbot/dotfiles) at some point in the future if we do more "official" Go work. I'm a believer in having linting done at VCS "commit time", either locally in a pre-commit so I have a chance to fix things and not both my teammates with linting issues, or at post-commit time via Hound comments (also automated, but opportunity to ignore). I've tried adding linting libraries to my editor, and found them too slow, at least for Ruby. I've limited "editor-time" checking to just syntax checking via Syntastic. The downsides I see to adding linting to the test suite are: * Style violations are not functional failures and logically shouldn't fail a build. * Adding code coverage, linting, etc. to a test suite slows down the build. * I only need to lint my diff (the commit), not the whole codebase, when I make changes. * Style violations should not prevent a user-facing, production deploy. * Adding linting to the test suite can slow that process down unnecessarily, particularly in continuous integration setups. I see the appeal of linting in the test suite, particularly for greenfield apps where we have total control, but I don't think it's a practice that we can universally apply to our client projects who have different deploy setups and existing codebases. So, I prefer the git hooks + Hound approach as a pragmatic middle ground.
2014-09-04 14:48:20 -07:00
Your `~/dotfiles-local/zshrc.local` might look like this:
# load pyenv if available
if which pyenv &>/dev/null ; then
eval "$(pyenv init -)"
fi
Your `~/dotfiles-local/vimrc.bundles.local` might look like this:
Plug 'Lokaltog/vim-powerline'
Plug 'stephenmckinney/vim-solarized-powerline'
zsh Configurations
------------------
Additional zsh configuration can go under the `~/dotfiles-local/zsh/configs` directory. This
has two special subdirectories: `pre` for files that must be loaded first, and
`post` for files that must be loaded last.
For example, `~/dotfiles-local/zsh/configs/pre/virtualenv` makes use of various shell
features which may be affected by your settings, so load it first:
# Load the virtualenv wrapper
. /usr/local/bin/virtualenvwrapper.sh
Setting a key binding can happen in `~/dotfiles-local/zsh/configs/keys`:
# Grep anywhere with ^G
bindkey -s '^G' ' | grep '
Some changes, like `chpwd`, must happen in `~/dotfiles-local/zsh/configs/post/chpwd`:
# Show the entries in a directory whenever you cd in
function chpwd {
ls
}
This directory is handy for combining dotfiles from multiple teams; one team
can add the `virtualenv` file, another `keys`, and a third `chpwd`.
The `~/dotfiles-local/zshrc.local` is loaded after `~/dotfiles-local/zsh/configs`.
vim Configurations
------------------
Similarly to the zsh configuration directory as described above, vim
automatically loads all files in the `~/dotfiles-local/vim/plugin` directory. This does not
have the same `pre` or `post` subdirectory support that our `zshrc` has.
This is an example `~/dotfiles-local/vim/plugin/c.vim`. It is loaded every time vim starts,
regardless of the file name:
# Indent C programs according to BSD style(9)
set cinoptions=:0,t0,+4,(4
autocmd BufNewFile,BufRead *.[ch] setlocal sw=0 ts=8 noet
What's in it?
-------------
[vim](http://www.vim.org/) configuration:
* [fzf](https://github.com/junegunn/fzf.vim) for fuzzy file/buffer/tag finding.
* [Rails.vim](https://github.com/tpope/vim-rails) for enhanced navigation of
Rails file structure via `gf` and `:A` (alternate), `:Rextract` partials,
`:Rinvert` migrations, etc.
* Run many kinds of tests [from vim]([https://github.com/janko-m/vim-test)
* Set `<leader>` to a single space.
* Switch between the last two files with space-space.
* Syntax highlighting for Markdown, HTML, JavaScript, Ruby, Go, Elixir, more.
* Use [Ag](https://github.com/ggreer/the_silver_searcher) instead of Grep when
available.
* Map `<leader>ct` to re-index ctags.
2014-09-30 09:31:48 -07:00
* Use [vim-mkdir](https://github.com/pbrisbin/vim-mkdir) for automatically
creating non-existing directories before writing the buffer.
* Use [vim-plug](https://github.com/junegunn/vim-plug) to manage plugins.
[tmux](http://robots.thoughtbot.com/a-tmux-crash-course)
configuration:
* Improve color resolution.
* Remove administrative debris (session name, hostname, time) in status bar.
2015-07-04 18:40:22 +03:00
* Set prefix to `Ctrl+s`
* Soften status bar color from harsh green to light gray.
[git](http://git-scm.com/) configuration:
* Adds a `create-branch` alias to create feature branches.
* Adds a `delete-branch` alias to delete feature branches.
* Adds a `merge-branch` alias to merge feature branches into master.
* Adds an `up` alias to fetch and rebase `origin/master` into the feature
branch. Use `git up -i` for interactive rebases.
* Adds `post-{checkout,commit,merge}` hooks to re-index your ctags.
Add more Git hooks, delegate to .local convention The `pre-commit` and `prepare-commit-msg` git hooks can be used for some interesting things such as linting files. For example, I need to format, vet, and lint Go files: https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/pre-commit https://github.com/croaky/dotfiles/blob/master/git_template.local/hooks/prepare-commit-msg We've rejected Go-related pull requests to thoughtbot/dotfiles due to not doing enough "official" Go work at the company. This change helps me start with `.local` for now, and then promote to "upstream" (thoughtbot/dotfiles) at some point in the future if we do more "official" Go work. I'm a believer in having linting done at VCS "commit time", either locally in a pre-commit so I have a chance to fix things and not both my teammates with linting issues, or at post-commit time via Hound comments (also automated, but opportunity to ignore). I've tried adding linting libraries to my editor, and found them too slow, at least for Ruby. I've limited "editor-time" checking to just syntax checking via Syntastic. The downsides I see to adding linting to the test suite are: * Style violations are not functional failures and logically shouldn't fail a build. * Adding code coverage, linting, etc. to a test suite slows down the build. * I only need to lint my diff (the commit), not the whole codebase, when I make changes. * Style violations should not prevent a user-facing, production deploy. * Adding linting to the test suite can slow that process down unnecessarily, particularly in continuous integration setups. I see the appeal of linting in the test suite, particularly for greenfield apps where we have total control, but I don't think it's a practice that we can universally apply to our client projects who have different deploy setups and existing codebases. So, I prefer the git hooks + Hound approach as a pragmatic middle ground.
2014-09-04 14:48:20 -07:00
* Adds `pre-commit` and `prepare-commit-msg` stubs that delegate to your local
config.
* Adds `trust-bin` alias to append a project's `bin/` directory to `$PATH`.
[Ruby](https://www.ruby-lang.org/en/) configuration:
* Add trusted binstubs to the `PATH`.
2017-09-07 23:48:46 -04:00
* Load the ASDF version manager.
Shell aliases and scripts:
* `b` for `bundle`.
* `g` with no arguments is `git status` and with arguments acts like `git`.
* `migrate` for `bin/rails db:migrate db:rollback && bin/rails db:migrate db:test:prepare`.
* `mcd` to make a directory and change into it.
* `replace foo bar **/*.rb` to find and replace within a given list of files.
* `tat` to attach to tmux session named the same as the current directory.
* `v` for `$VISUAL`.
Thanks
------
2013-03-06 11:01:26 -08:00
Thank you, [contributors](https://github.com/thoughtbot/dotfiles/contributors)!
Also, thank you to Corey Haines, Gary Bernhardt, and others for sharing your
dotfiles and other shell scripts from which we derived inspiration for items
in this project.
License
-------
2018-01-05 09:10:56 -05:00
dotfiles is copyright © 2009-2018 thoughtbot. It is free software, and may be
redistributed under the terms specified in the [`LICENSE`] file.
[`LICENSE`]: /LICENSE
About thoughtbot
----------------
2017-03-10 09:39:51 -05:00
![thoughtbot](http://presskit.thoughtbot.com/images/thoughtbot-logo-for-readmes.svg)
dotfiles is maintained and funded by thoughtbot, inc.
The names and logos for thoughtbot are trademarks of thoughtbot, inc.
We love open source software!
See [our other projects][community].
We are [available for hire][hire].
[community]: https://thoughtbot.com/community?utm_source=github
[hire]: https://thoughtbot.com/hire-us?utm_source=github