なぜこの記事を書くのか？
自分用・公開用の gem を書き始める時、.gitignore の内容をいつも迷うから。
- gem を作成する時、 ruby のバージョンは固定してしたほうがいいのか？
- 依存している gem を vendor/bundle に入れているとか。
- 依存している gem のバージョンが固定されているほうがいいのか？
bundle gem やってみる
bundle gem SOME_NICE_GEM
この時点で生成される .gitignore は、以下の通り（記事の作成時点）。
/.bundle/
/.yardoc
/Gemfile.lock
/_yardoc/
/coverage/
/doc/
/pkg/
/spec/reports/
/tmp/
生成される .gitignore について考えてみる
/.bundle/
bundle exec を使ってコマンド実行したりする場合、gem のインストール状態（インストール先）はその実行環境によって異なるので、bundle コマンドの設定は無視する。
Gemfile.lock
依存している gem のバージョンが固定される（はず）。
古い gem に依存していたりすると、何らかの不具合が出る可能性もある（はず）。
作成中の gem をインストールする時点で、依存している gem の最新バージョンを導入する（はず）。
git ignore 導入している場合
個人的には git ignore を導入している（「.gitignore ファイルを生成するサービス gitignore.io」参照）ので、
git ignore ruby linux osx >> .gitignore
しておく。
すると、
・・・（前略）
## Environment normalization:
/.bundle/
/vendor/bundle
/lib/bundler/man/
・・・（中略）
# for a library or gem, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
# Gemfile.lock
# .ruby-version
# .ruby-gemset
・・・（後略）
となる。
.gitignore 追加部分の再考察
/.bundle/
先ほどの考察から、そもそも /.bundle/ を追跡対象にする（.gitignoreから削除する）必要性を感じないので、そのまま使用する。
とはいえ、/.bundle/ を追跡対象にしたい場合に削除しておかないと、/.bundle/ を含めたい時に初期状態の /.bundle/ と設定がダブって「削除し忘れ」で不具合の出る可能性がある。
git ignore コマンドでまとめて追加している方を残して、初期状態の /.bundle/ を削除する方向がいいのかもしれない（なんとなく）。
/vendor/bundle
bundle install した時に標準的に使われる領域なので、除外されている。
先ほどの /.bundle/ と同様、追跡対象にする必要性は感じないので、そのまま使用する。
Gemfile.lock
初期状態の .gitignore にも書かれているので、 /.bundle/ と同じ方針にする。
初期状態の方の Gemfile.lock を削除して、git ignore 導入した方のコメントを外す。
.ruby-version
（コメントにも書かれているが）様々な環境で使用する gem というものの性質上、指定するのは良くない。
ruby のバージョンを指定してしまうと、ruby のバージョンが上がった場合に不具合が出ると思われるので、追跡対象から外した方が良い（はず）。
別の言い方をすると、ruby のバージョンが上がって不具合が出なければ gem の更新は不要で、ruby のバージョンが上がって不具合が出るようであれば gem の方も新旧の ruby に対応できるように更新した方が良い（はず）。
.gitignore 再修正
ダブっている内容は初期状態の .gitignore から除外して、 git ignore で導入した内容を修正していく方向が良いと思われる。
そうすると（記事の作成時点で）生成した初期状態の .gitignore の内容は全てダブっていたので、削除することになった。
あくまでも先ほどの git ignore 導入した状態での話だけど。
先ほどの .gitignore の考察とコメント文をもとに、「Gemfile.lock」、「.ruby-version」、「.ruby-digest」をコメントアウトしておく。
開発の準備が整った状態
とりあえず、一般的にはこの状態で開発準備が整ったと言える（はず）。
結局、初期状態の .gitignore は、git ignore で導入した内容で上書きされて、３箇所コメントアウトしただけになっている。
# Created by https://www.gitignore.io/api/ruby,linux,osx
### Ruby ###
*.gem
*.rbc
/.config
/coverage/
/InstalledFiles
/pkg/
/spec/reports/
/spec/examples.txt
/test/tmp/
/test/version_tmp/
/tmp/
# Used by dotenv library to load environment variables.
# .env
## Specific to RubyMotion:
.dat*
.repl_history
build/
*.bridgesupport
build-iPhoneOS/
build-iPhoneSimulator/
## Specific to RubyMotion (use of CocoaPods):
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# vendor/Pods/
## Documentation cache and generated files:
/.yardoc/
/_yardoc/
/doc/
/rdoc/
## Environment normalization:
/.bundle/
/vendor/bundle
/lib/bundler/man/
# for a library or gem, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
Gemfile.lock
.ruby-version
.ruby-gemset
# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
.rvmrc
### Linux ###
*~
# temporary files which can be created if a process still has a handle open of a deleted file
.fuse_hidden*
# KDE directory preferences
.directory
# Linux trash folder which might appear on any partition or disk
.Trash-*
### OSX ###
*.DS_Store
.AppleDouble
.LSOverride
# Icon must end with two \r
Icon
# Thumbnails
._*
# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk
蛇足
文中に「はず」が多いし、結局は自分の環境（git ignore 導入状態）での内容になってしまってお恥ずかしい。
論拠や背景に詳しい方・情報があったら是非、別記事で作成していただきたい。