Vagrantで起動しているVMを一覧する
VagrantでVMをポコポコ起動していると、どこで何を起動して、どのVMが生きているのか良くわからなくなる。
いつも、VirtualBoxを起動して確認するのも面倒くさいしイケてないきがする。
vagrant statusはVagrantfileがある場所でしか表示されないし、
表示されてもその場にあるVMに関しての情報しか表示されない。
調べてみると、vagrantにはvagrant-global-statusというpluginがあるらしい。
なんと、このpluginをインストールすると、vagrant global-statusコマンドで、
いつでもどこでも全てのVagrantVMの状態を一覧で表示することができる。素晴らしい。
vagrant-global-status のインストール
$ vagrant plugin install vagrant-global-status
使い方
次のコマンドを実行するとVM一覧が表示される。
$ vagrant global-status
こんな感じで表示されて便利。
/Users/ringo/work/vag
default running (virtualbox) 2014-03-12 14:43:07 +0900
/Users/ringo/work/docker
default running (virtualbox) 2014-03-12 14:43:59 +0900
試しにVMを一つ落として実行してみると。。。 シャットダウンした奴は表示されません。
/Users/ringo/work/docker
default running (virtualbox) 2014-03-12 14:43:59 +0900
-a, --allオプションを使うと起動していないやつも表示されます。
$ vagrant global-status -a
/Users/ringo/work/vag
default poweroff (virtualbox) 2014-03-12 14:43:07 +0900
/Users/ringo/work/docker
default running (virtualbox) 2014-03-12 14:43:59 +0900
注意
このプラグインを入れた後に起動したVMしかリストされないので、 起動している場合は、一度落として立ち上げ直すと一覧されるようになります。
オプションはこのallとhelpしかないっぽい。
$ vagrant global-status -h
Usage: vagrant global-status [--all]
-a, --all Displays information about all machines (instead of just the active ones)
-h, --help Print this help
参考
VagrantでSnapShotを撮る
Vagrantプラグインにvagrant-vbox-snapshotというものがある。
これを使うと簡単にスナップショットが撮れて便利なのでメモ。
スナップショットを使うと、その瞬間のVMの状態をまるごと記憶しておくことができる。
例えば、サーバに様々なミドルウェアをインストールして、ごちゃごちゃになってしまったとしても、 スナップショットを撮っておけば、インストール前の状態に戻すことができる。 ちょっと、手元でChefのレシピを流したいときなどに便利です。
vagrant-vbox-snapshot のインストール
vagrant plugin install vagrant-vbox-snapshot
使い方
スナップショット一覧
vagrant snapshot listスナップショットを撮る
vagrant snapshot take [NAME]スナップショットへ戻る（ロールバック）
vagrant snapshot go [NAME]
参考
おまけ
溜まってるドラフト記事を放出していきたい。。。
nodebrewでnode.jsのインストール
環境
- Scientific Linux 6.5
- Mac OSX 10.7, 10.9
前準備（Scientific Linux）
ビルドに必要なパッケージをインストールします。 飛ばして、エラーが出てきたら実行するでもいいかも。Macの場合は不要。
sudo yum install gcc-c++
nodebrewを使ってnode.jsをインストール
- nodebrewのインストール
curl -L git.io/nodebrew | perl - setup- OS X の場合は
brew install nodebrew。
- .zshenv/.zshrc/.bashrcにPATH設定を追加
export PATH=$HOME/.nodebrew/current/bin:$PATH
- rc（もしくはenv）ファイルの再読み込み
. ~/.zshrc
- nodeのインストール
nodebrew install-binary v0.10.26nodebrew helpでhelpが見れます。nodebrew ls-remoteでインストール出来るバージョンの一覧を確認できます。nodebrew install VERSIONを使うとソースからビルドします。nodebrew install latestで最新版をインストールすることができるのですが、node.jsはマイナーバージョンが偶数だと安定版なので、偶数を入れるのがオススメです。
- 使用するnodeのを指定
nodebrew use v0.11.12- ※ 指定できるバージョンは
nodebrew listで確認できます。
- 確認
node -v
参考
``git branch -a''で消したはずのリモートブランチが出てくる
毎回、調べ直してるのでメモ。
gitで不要なリモートブランチを狩った後に、ローカルでgit branch -aを実行すると、
消したはずのブランチが残っていることがある。
これを消すには以下のコマンドを実行する。
git fetch --prune
また、remoteの状態を見たいときは、
git remote show origin
を実行する。
参考
Devsumi 2014: 「サーバプロビジョニングのこれまでとこれから」の感想とメモ
サーバプロビジョニングのこれまでとこれから
- 宮下 剛輔 さん
- @gosukenator
- github.com/mizzy
- paperboy&co.
- サーバプロビジョニングのこれまでとこれから
- [Slide] Future of Server Provisioning at Developers Summit 2014
感想
Developers Summit 2014 に参加してきました！
まずは、一番最初に出た「13-B-1」の感想から。
今はの業務はインフラ専門では無いけれども、興味があったのでセッションに参加してみました。
個人的に（仕事でも少し）Chefのrecipeとか書いたり、serverspecを使ってみたりして「面白い」と思っていたので、他にどんな技術があるのかワクワクしながら聞いてました。
インフラのコード（chefのrecipeなど）を、徹底的にGitHubで管理したり、
テスト駆動インフラをすると安定して環境が整えられていいと思います。
開発環境はChefで作ってますが、ちょっとrecipeを直したりすることが億劫でした。
今は、recipe書き換えて、動作確認して、レビューして、マージしてみたいなことを全部手動でやっていて、正直面倒臭いなぁと思うことが多々あります。
結果、自分のローカル環境だけ変更をとどめたり（あとで纏めて出せばいいやとか）してしまって、非常に良くない。
テスト駆動インフラにすることで、こまめに書き換える習慣がつきそうです。
あと最近、よく耳に入ってくるDockerとかについても少し知ることができたのでよかったです。
うちのチームの開発環境でも、ChefのレシピをCIしたり、Dockerとか使ってやってみたいなぁと思います。
いやー、このセッション楽しかった。
以下は、セッション中に書いたメモです。
間違いとか、何かあったら教えていただけると助かります。
サーバプロビジョニング
サーバプロビジョニングを3つのレイヤで整理すると、
- Bootstrapping: OS install など
- Configuration: サーバの設定など
- 最近はサーバプロビジョニングはここらへんのことを指すことが多い
- middle ware の install
- 手動, シェルスクリプト, chef, puppet など
- Orchestration: Fabric, capistrano など
- わかりにくい概念
- インフラの新しい概念とともに意味も変わってきている
のようにまとめられる。
Infrastructure as Code
歴史
- 2005年に Puppet が登場
- 2005年に論文が出ている
- 源流はCFEngine(1993)
- 宣言的: 何をしたいか（どうするかを記述しない）
- 抽象化: 詳細の面倒を見てくれる
- 冪等性: 必要なときだけ実行する
- 収束化: 放っておけばどうにかなる
- 「Infrastructure as Code」という言葉は2008年くらいに言われ始めた
Infrastructure as Code とは
- 以下の項目からビジネスをゼロから再構築できるようにすること
- ソースコード
- アプリケーションのデータのバックアップ
- サーバリソース
「コードでインフラの情報を記述する」ということを推し進めていったのがChef。 「ソフトウェアと同じ概念が使えないか？」という発想を元に、 「Infrastructure as Code」から「Test-Driven Infrastructure（テスト駆動インフラ）」へ。
テスト駆動インフラ
この、発想は Chef 周辺で盛り上がってきて、「Test Kitchen CI」というツールが登場している。 でも、「Chefしか対応してない！」ということで、作ったのが serverspec。 テスト駆動インフラの「駆動」は、インフラを記述したコードを書くことを駆動するという意味。 serverspecはインフラの状態をテストするためのツールではない（使ってもいいけど）、 インフラの状態を記述した「コード」をテストするツール。
インフラCI
ツール的には、もう使い慣れているもので、
- Jenkins
- Wercker
- Travis
- Drone
などでまわす。
GtiHub Flowによるインフラワークフロー
GitHubに連携させて、
- Test OK
- Review OK
- Merge OK
となる。 ここまでがひとつの流れ。
Immutable Infrastructure (Disposable Components)
Immutable ~（不変）より、Disposable ~ （使い捨て）のほうが重要。
- 動いているサーバには変更を加えない
- 新しいサーバを構築してロードバランサーで切り替える
- 成功したら元のサーバは破棄（ここが disposable）
- ダメだったら切り戻す
- 昔は（当時？）Blue-Green Deploymentと呼ばれていた（Immutable Infrastructure という言葉が出てきたのは2013くらい）
- EC2のようなIaaSが出てきたから容易になった
Immutable/Disposable の制約で得られるメリット
- 変更に伴うトラブルが起こりにくい
- 継続的改善がしやすい
- 設計へのよい影響 The Twelve-Factor App(IX. Disposability), 日本語版: The Twelve-Factor App
- Chef, Puppetのようなツールがよりシンプルになる(常にまっさらな状態でインストールするため)
Immutableにできないところはどうするのか？
- 永続化や可変なデータをどうするか？
そこは、やはりケースバイケースになる。
Container Base Deployment
- コンテナとは、単機能で、軽量なVM っていうイメージ。厳密には違うけど。
- コンテナをまるごと差し替えてデプロイする
- . サーバにコンテナが乗っていて、その上で Middle ware が動いている
- . コンテナを載せる
- . コンテナの接続先（？）をかえる
- Docker のポータビリティによって普及
- ローカル環境のコンテナを本番環境でつかえる
- ローカルで十分テストすることが出来る
- テスト駆動して、CIでまわして、コンテナデプロイ
- 単機能なVMのイメージで、1コンテナ1機能と単純化し、これらを組み合わせてサービスを構築する
- サーバ部品のコンポーネント化
- 差しかえもし易い
- テスタビリティも向上
- IaaS上じゃなくても Bule-Green Deployment ができる
- Mesos/YARN などと組み合わせて自動的なリソース配置
Orchestration
イメージ的には、
- Configuration: 単一サーバで完結
- Apache, Nginx の install
- Orchestration: 複数のサーバが関連するもの
- LBへのノード追加
- MuninやNagiosへのノード追加
- アプリケーションデプロイ
とするとつかみやすい。
旧来と新しい Orchestration
- 旧来
- Immutable Infrastructure 前提ではない
- サーバの増減が頻繁でないので Config. の領域でも可能
- Command & Control 型
- 新しい
参考
- サーバプロビジョニングのこれまでとこれから
- [Slide] Future of Server Provisioning at Developers Summit 2014
- serverspec
- The Twelve-Factor App(IX. Disposability)
- 日本語版: The Twelve-Factor App
Tools
MongoDB のタイムゾーンについて
MongoDB ではタイムゾーンを指定できない．
すべて，協定世界時（UTC）で表現される．
JSTの時刻を扱いたい場合は，mongoから取り出した時に+09:00したりしないといけない．
db.things.insert( { "time1": new Date() } )
db.things.find()
すると，
{
"_id" : ObjectId("52f0cdeb344f397bf593bb87"),
"time1" : ISODate("2014-02-04T11:24:27.602Z")
}
が出力される．
この「2014-02-04T11:24:27.602Z」は，ISO 8601 で規定されている，日付と時刻の表記である．
「T」は，日付と時刻を分ける記号である．
「Z」は，タイムゾーンが協定世界時（UTC）であることを示す．
どんな形で入れてもZつくから，UTCのみなんだね．
参考
OSXでJavaのバージョンを切り替える
先日，Java8で遊んでみようと思って，OSXにインストールしました．
java -versionを打つと
java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b121) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63, mixed mode)
がでて，ちゃんと1.8になってるなよしよし．
と思って生活してたんだけども，思わぬところで事故ったので，1.6に戻す事にしました．
でも，いじっているうちに良くわからなくなったので，ログとしてやったことをまとめておこうと思います．
Javaのバージョンを切り替える2つの方法
OSXでJavaのバージョンを切り替える方法は2つ（しか知らない）あります．
JAVA_HOMEを切り替える- 非推奨:
/System/Library/Frameworks/JavaVM.framework/Versionsの下のCurrentJDKを切り替える
javaコマンドの実体
まず，1.8をインストールした後，which javaを打つと，/usr/bin/javaが返ってきます．
実は，シンボリックリンクなのでls -l /usr/bin/javaでリンク先を見てみると，
java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
という結果が返ってきます．
javaコマンドだけではなく，javacなどのコマンドも/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands下にあるものを指してます．
MacOSXにおけるjavaのバージョンについて
Mac OSXのJavaのバージョンは一応，/System/Library/Frameworks/JavaVM.framework/Versionsで管理（？）されています（本当か？）．
ここの，ディレクトリをみてみると，
$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions total 40K lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.4 -> CurrentJDK/ lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.4.2 -> CurrentJDK/ lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.5 -> CurrentJDK/ lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.5.0 -> CurrentJDK/ lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.6 -> CurrentJDK/ lrwxr-xr-x 1 root wheel 10 8 27 12:53 1.6.0 -> CurrentJDK/ drwxr-xr-x 9 root wheel 306 1 27 18:57 A/ lrwxr-xr-x 1 root wheel 1 1 28 12:39 Current -> A/ lrwxr-xr-x 1 root wheel 59 8 27 12:53 CurrentJDK -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/
となっています．
ん？1.4も1.5も1.6もCurrentJDKを指してます．
CurrentJDKは，/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/を指しています．
つまり，バージョン1.4も1.5も，実は1.6だったということ．
各Javaバージョンの実体
OSXへJavaを提供する提供元は2箇所あります．AppleとOracleです．
Appleが提供しているJavaは，CurrentJDKの指している/System/Library/Java/JavaVirtualMachinesに格納されています．
また，Oracleが提供しているパッケージを使って1.7や1.8をインストールした場合は，
/Library/Java/JavaVirtualMachinesになります．
JDKの置き場所は2箇所ある．
JDKのバージョン切り替え
1. JAVA_HOMEを切り替える
OSXのJavaは次のような項目で環境が決定されるそうです．
Java Preferencesは，2012年10月16日にのJavaのセキュリティアップデート（Java for OS X 2012-006）で削除されました． これ以降（？），OSXにJavaに提供するのはAppleからOracleに変わったようです． どちらにせよ，JAVA_HOMEを設定して上書きしてしまえばバージョンは変更できそうです．
このバージョンのパスを返す便利なコマンドが実は存在します．
java_home コマンド
このコマンドは，指定したJavaバージョンのhomeがどこにあるかを返すコマンドです．
配置されている場所は，/System/Library/Frameworks/JavaVM.framework/Versions/A/Commandsです．
実行するとこんな感じになります．
$ ./java_home -v "1.4" Unable to find any JVMs matching version "1.4". /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home $ ./java_home -v "1.5" Unable to find any JVMs matching version "1.5". /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home $ ./java_home -v "1.6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home $ ./java_home -v "1.7" Unable to find any JVMs matching version "1.7". /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home $ ./java_home -v "1.8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
1.6と1.8しかインストールしてないので，1.4，1.5と1.7は最新である1.8を指します． 1.6だけはインストールされているので，ちゃんと1.6のパスが返ってきます．
設定ファイルに記述する
.profile, .bashrc, .zshrcなどなんでもいいですが，どれかで，環境変数JAVA_HOMEに設定します．
さきほどのjava_homeコマンドを使います．
export JAVA_HOME=`/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java_home -v "1.6"`
PATH=${JAVA_HOME}/bin:${PATH}
以降，1.6の部分を，1.8に変えると簡単にバージョンを切り替えることができます．
2. 非推奨？: /System/Library/Frameworks/JavaVM.framework/Versionsの下のCurrentJDKを切り替える
この方法は，OSX標準の構造を色々といじるので，いつ，どこで，どんな事件が起こるかわかりません． そのため，個人的には非推奨です． アンチパターン？として，一応紹介しておきます．
まず，/System/Library/Frameworks/JavaVM.framework/Versionsにある，1.6以前のバージョンを整理します．
1.4 -> CurrentJDK/ 1.4.2 -> CurrentJDK/ 1.5 -> CurrentJDK/ 1.5.0 -> CurrentJDK/ 1.6 -> CurrentJDK/ 1.6.0 -> CurrentJDK/ CurrentJDK -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/
CurrentJDKをバシバシ切り替えたいので，1.4と1.5の向き先を1.6にします． （上書きしようと思ったけれども，-f,Fつけても上書きされなかった．．）
sudo rm 1.4; sudo ln -sf 1.4.2 1.4 sudo rm 1.4.2; sudo ln -sf 1.5 1.4.2 sudo rm 1.5; sudo ln -s 1.5.0 1.5 sudo rm 1.5.0; sudo ln -s 1.6 1.5.0 sudo rm 1.6; sudo ln -s 1.6.0 1.6 sudo rm 1.6.0; sudo ln -s /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents 1.6.0 sudo rm CurrentJDK; sudo ln -s 1.6 CurrentJDK
次に，1.8を入れたので1.8用のリンクを追加します．
ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents 1.8.0 ln -s 1.8.0 1.8
すると，こういう構成になります．
$ ls -l total 40K lrwxr-xr-x 1 root wheel 5 1 28 16:39 1.4 -> 1.4.2/ lrwxr-xr-x 1 root wheel 3 1 28 16:40 1.4.2 -> 1.5/ lrwxr-xr-x 1 root wheel 5 1 28 16:45 1.5 -> 1.5.0/ lrwxr-xr-x 1 root wheel 3 1 28 16:45 1.5.0 -> 1.6/ lrwxr-xr-x 1 root wheel 5 1 28 16:46 1.6 -> 1.6.0/ lrwxr-xr-x 1 root wheel 59 1 28 16:47 1.6.0 -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/ lrwxr-xr-x 1 root wheel 5 1 28 15:27 1.8 -> 1.8.0/ lrwxr-xr-x 1 root wheel 55 1 28 15:26 1.8.0 -> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/ drwxr-xr-x 9 root wheel 306 1 27 18:57 A/ lrwxr-xr-x 1 root wheel 1 1 28 12:39 Current -> A/ lrwxr-xr-x 1 root wheel 3 1 28 16:50 CurrentJDK -> 1.6/
CurrentJDKの向き先を1.8や1.6にすると切り替えられるようになりました．
javaコマンド
この状態でjava -versionコマンドを実行すると，まだ1.8のjavaが実行されてます．
Current -> A下のCommand下にあるjavaコマンドを実行しています（Aってなんだ．．．）．
Aの中身は，
$ ls -l A total 40K lrwxr-xr-x 1 root wheel 3 1 27 18:57 1.6 -> 1.6 drwxr-xr-x 44 root wheel 1.5K 8 27 12:53 Commands/ drwxr-xr-x 4 root wheel 136 11 18 2011 Frameworks/ drwxr-xr-x 14 root wheel 476 3 29 2013 Headers/ -rwxr-xr-x 1 root wheel 102K 8 27 12:53 JavaVM* drwxr-xr-x 42 root wheel 1.4K 8 27 12:53 Resources/ drwxr-xr-x 3 root wheel 102 8 27 12:53 _CodeSignature/
のようになっています． 1.6のシンボリックリンクは無限ループになってます．
おそらく，1.8をインストールすると，
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/binにあるコマンドが，
/System/Library/Frameworks/JavaVM.framework/Versions/A/Commandsにコピーされているような気がします．
なので，これもシンボリックリンクで参照してあげます．
sudo mv Commands Commands.back sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin Commands
おまけ
はてなブログのMarkdownって脚注（[^1]）とかうまくやってくれないんですね．
参考文献
Node Knockout 2013 にでたよ！
一人アドベントカレンダーも達成できず，年明けるまでにこの記事も投稿しておこうと思うも投稿できず，酔っ払ってテレビ見てました．あけましておめでとうございます．
先日(11/9-11)，Node Knockout 2013に出ました！ 書こう，書こうと思ってずっとほったらかしにしてしまいました．．
Node Knockoutはnode.jsを使って行われるハッカソンで， 日をまたいで3日間，48時間開催されます． 今年で，4回めだか5回めだかだそうです．
チームmesolabsで，参戦し100位以内（75位くらい）に入ることが出来ました．
作ったもの: Walk Sharing
今回何を作ったかというと，Walk Sharingというサービス（？）です．nodeは初心者で良くわかってなかったんですが，nodeパイセンがガリガリ書いてくれたので，完成しました．
Google ストリートビューの視点を共有するもので，Navigatorの操作してるWalkingに参加すると同じ風景をリアルタイムで共有できます．Youtubeにアップロードした動画はこちら．
また，誰かが観た視点や位置を記録しておき，後から再生することができるタイムシフトもつけました．
公開した1，2日後くらいに非推奨パラメータを利用していたため，Googleの仕様変更（？）にハマってしまい審査期間に体験できないという残念なコトになってしまいました． 非推奨のものは使わないようにしましょう．
やったこと
簡単に説明すると，TwitterでのOAuth認証はPassportというLibraryを使って，簡単に出来ました． ツイートも，TwitterのAPI叩くだけなので難しくなかった．
一番面倒くさかったのが，スクリーンショットを撮る機能で，完成しませんでした．ストリートビューが真っ白になってしまったり，コメントだけ撮影出来てしまったり．．．上手く保存する方法が見つかりませんでした．本当は画像付きでツイート出来たら良かったです．
あとは，コメント描画．とりあえず，Canvasでニコニコっぽくコメントを流すようにしました．ただ，すごいファンが回り出したりしてもっと最適化する必要があると思います．コメント描画のロジックはなかなか複雑で，大変だなぁと思いました．ただ，JavaScriptでも出来なくはないんじゃあないか．．と思ったので，機会があったらなにか作りたいですね．
bashでビープ音を消す
bash: scp: コマンドが見つかりません
SCPでファイルをサーバにコピーしようとしたら，
bash: scp: コマンドが見つかりません
というエラーが出てしまい，送信できなかった．
調べてみたら，openssh-clientsが入っていないことが原因らしい．
Scientific Linux 6.xを最小インストールするとインストールされないらしいので自分で入れてやる必要がある．
yum install openssh-clients
参考文献
vimで貼付け時に自動でpasteモードにする
vimでOSのクリップボードから貼り付けたいときは，
一度set pasteでペーストモードにしてから貼り付ける．
これが，結構面倒くさいんだけど以下のスクリプトを使うと簡単に貼り付けができるようになる．
ノーマルモードでペーストを行うと自動でペーストモードになって， クリップボードの中身を貼り付けてくれる．
オススメです．
if &term =~ "xterm"
let &t_ti .= "\e[?2004h"
let &t_te .= "\e[?2004l"
let &pastetoggle = "\e[201~"
function XTermPasteBegin(ret)
set paste
return a:ret
endfunction
noremap <special> <expr> <Esc>[200~ XTermPasteBegin("0i")
inoremap <special> <expr> <Esc>[200~ XTermPasteBegin("")
cnoremap <special> <Esc>[200~ <nop>
cnoremap <special> <Esc>[201~ <nop>
endif
参考文献
- あったけどロストしてしまいました．．．
gitでpull(fetch) 専用のremoteを登録する方法
git で dry-run
svnで使っているdry-runをgitでも実行したい時があると思います．
しかし，gitにdry-runに当たるものはないっぽいです．
一度マージを実行して，コミットせずに手動で戻すという形をとるようです．
--no-commitをつけてdevelopをコミットなしでマージします．
git merge --no-commit --no-ff develop
ただ，マージはされるので，resetでHEADまで戻します．
git reset HEAD
参考文献
gitでディレクトリ構成を維持する
今日もgitネタ．
gitでディレクトリ構成を維持したい時が度々ある． しかし，空のディレクトリはgitで管理されない．
そこで，ディレクトリを保持したい場合は，中に.gitkeepをおいておくといいそうな．
git gitkeep
すべてのディレクトリに，いちいち作成していくのは面倒臭いのでgitのサブコマンド(gitkeep)https://gist.github.com/ringohub/7939324を作りました．
せっかくなので，コードを解説． シェルで書きました．bashが入っていれば動きます．
gitリポジトリかどうかをチェック
gitリポジトリでないところで実行した場合，.gitkeepが作成されてしまうと困るので，ガード文を書きました．
if ! git rev-parse 2> /dev/null; then echo -e "\033[0;31mERROR\033[0;39m: This directory is not git repository \033[0;31m:(\033[0;39m" exit 1 fi
ディレクトリを探索しながら.gitkeepを配置
次のような流れで.gitkeepを作成してます．
Seek() {
for DIR in * ; do
if [ -d "${DIR}" ]; then
if [ -f "${DIR}/.gitkeep" ]; then
echo ".gitkeep already exists .gitkeep in `pwd`/${DIR}"
elif [ -z "$(ls -A ${DIR})" ]; then
touch ${DIR}/.gitkeep
echo "Create .gitkeep in `pwd`/${DIR}"
fi
(cd "${DIR}"; Seek;)
fi
done
}
Seek;
- 入力がディレクトリか否かを判定
if [ -d "${DIR}” ] - 対象のディレクトリに
.gitkeepが存在するかを判定if [ -f "${DIR}/.gitkeep” ] - 存在しない場合，ディレクトリが空か判定
elif [ -z "$(ls -A ${DIR})” ] - 空だった場合，
.gitkeepファイルを作成touch ${DIR}/.gitkeep
使い方，
- git-gitkeep.shをダウンロードしてパスが通ってる場所に配置
chmod 755で権限を与えるgit gitkeepを実行
ディレクトリが空じゃなくなったら.gitkeepを削除するようにした方がいいのかなぁ？？
参考
git ignore のデフォルトを設定する
chefネタがevernoteからなくなってきたので，前々回に続きgitネタを． 一人Advent calendar結構しんどいね．．
はじめに
毎回，git initして.gitignoreつくって，.DS_StoreとかThumbs.dbとかを追加する． これはすごい面倒くさいので，デフォルトで何とかしたい．
方法1 gitignoreのテンプレートを書く
ホームディレクトリに.gitignore.defaultを作成
.DS_Store Thumbs.db
git config --global core.excludesfile ${HOME}/.gitignore.default
とすると，デフォで.gitignore.defaultを見てくれる．
でも，できればgit initしたときに， .gitignoreの作成してほしい（今後の課題）．
gitignore.ioをつかう
gitignoreを作成してくれるサービス.gitignore.io ．
これは，shellに関数を定義する． 関数内でapiを呼び出すことによって取得することができる．
function gi() { curl http://gitignore.io/api/$@ ;}
gi osx
自分で.gitignoreを集める必要がないので非常に簡単！
gi osx,javaとすると，java用とosx用のgitignoreが出力される．
まとめ
ということで，gitのサブコマンドを作ってみました
