Tonjiru v1.1.0 ＋ GitHub Flow × GitHub for Windows
執筆日時：
- アイコンを付けた
- SendMessage と PostMessage を選択できるように
- 不具合の修正
SendMessage だと相手がメッセージの処理を完了するまで制御が返ってこないので、PostMessage を使う方がいいかなって思った。
関係のない話：GitHub Flow × GitHub for Windows
GitHub Flowとは何だろうか？
- masterブランチのものは何であれデプロイ可能である
- 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: new-oauth2-scopes）
- 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
- フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する
- 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
- マージをしてmasterへpushしたら、直ちにデプロイをする
これがフローのすべてだ。
去年ぐらいからこれを実践している（つもり）なのだけど、如何せん、一人でやっているのであまり自信がない。ので、自分のやり方をさらしておく。
1. 何か改善を思いついたら issue にメモする
この作業が一番面倒くさい……なにかいいアプリ（できればモバイル）があればいいんだけどな。
2. GitHub for Windows を起動して Sync
コマンドだと間違えるマンなので、GUI クライアントを使う。GitHub for Windows（現行安定版）を起動したらこまめに Sync しておく。
3. ブランチを切って Visual Studio で実装する
ローカルでブランチを切る。名前は……最近は解決する issue の名前を付けている。今回は issue #12 を直したいので、“issue12”と付けた。
Visual Studio でしばし開発――中断するときは Sync しておく。
4. コミット
終わったらコミットする。コメントを“resolve #”にすると、issue が保管されるのが GitHub for Windows のよいところ。
追記（2017/07/08）
書き忘れたけど、こうしておくと issue が自動でクローズされて便利。
5. プルリクエストを作成
画面左上の［Pull request］ボタンを押してプルリクエストを作成する。
送信したら［Visit it on GitHub］をクリック。ブラウザーでプルリクエストの画面を開く。
6. プルリクエストをマージ
あまり何も考えずにマージ。
マージが終わったら、ブランチを削除しておく。
7. ローカルを master に切り替えて Sync
GitHub for Windows に戻ってブランチを master に切り替えて、Sync ボタンを押す。プルリクエストがにょきっと表れて、master にむちょちょ～っと追加されるのを眺めて達成感に浸る。
→ 3 に戻る。
注意点
- ブランチを切った後に master を更新してしまったら、［Update from master］する。
- とりあえずミスしても落ち着く（master に戻すのを忘れて、サブブランチからブランチを切ったとか）。シンプルに保っていれば、復旧はそんなに難しくない。小幅な変更なら思い切って捨てて、master に戻れ
- master で作業しないようにだけ気を付ける。バージョンのインクリメントとか、しょうもないのはそのまま作業していいことにしてるけど。
- アレしてる間にコレしたくなっても我慢しろ。コレは issue に書いておけ。あとでブランチ切って コレ に取り組め。
いろいろ試してみたけどダメだった／(^o^)＼ ってときにブランチごと捨てられるので、昔みたいにプロジェクトをコピペしてサンプルコードを書く（！！）みたいなことはしなくなった。“test”なんちゃらというブランチを切って、試して捨てる。これだけでもだいぶ進歩したのかなって思うけれど、一人でやってるとこれでいいのかさっぱりわかんなくて不安になるネ。