わたしのGit/GitHubの使い方

  • このエントリーをはてなブックマークに追加

この記事は feedforce advent calendar 2016 18日目の記事です。

昨日は tsubぼくの情報収集方法 でした!この記事を読んで私も早速 のぼりーさんのクラウドインフラPodcast を購読しました!

こんにちは、未だに洗濯機を買ってないことを社内の人達に心配されている mizukmb です。私もコインランドリー生活には限界を感じているので、そろそろ買おうと思います。

さて、今回は私流の Git/GitHub 活用術についてお話しようと思います。

hhkb

HHKB にテプラを貼った話はまた今度にしようと思います。

自己紹介

  • @mizukmb
  • 2016年 新卒入社 Webエンジニア
  • ボドゲ部
  • 音ゲー部(自称)

1. Git: masterブランチは削除する

Git, GitHub を使い始めてよくあるのが 誤って master ブランチで作業して push してしまう ことです。私もよくやりました。個人や友人同士の趣味プロジェクトであれば笑って許せる話ですが、業務においてはそうはいきません。

意外にも(たぶん) GitHub 側には master ブランチをプロテクトする機能はなく、権限さえあれば、 git push -f origin master で push できてしまいます。リポジトリを fork したり、 git-hook 機能で push 時に警告を出すなど様々な手段がありますが、私は ローカルの master ブランチを削除して master push を防いでいます。

運用方法については 拙著 ローカルリポジトリのmasterブランチは別に無くても良い? - Qiita にて解説していますので、そちらをご覧ください。

こちらの効果としては、 master ブランチに push してしまうことを一切気にしなくても良くなるだけでなく、master が自分のコミットで汚れる心配もないのでいつでも清潔な状態の master ブランチを参照できます。デメリットとしては、リモート側の更新がある度に git fetch && git checkout origin/master しなければならないくらいでしょうか。fetch だけで済むようにしたいですね。

この運用をはじめて2~3年ほど経ちますが、未だに問題に感じたことはありません。何かあったら git checkout -b master などすれば良いだけですし。

追記: TwitterにてGitHubにブランチのプロテクト機能があるというコメント頂きました。情報提供ありがとうございます。

2. Git: lsと同じ感覚で git status する

CLI で何も入力のない状態で Enter キーを押下した時に、自動で lsgit status コマンドが実行されるように設定しています。

ls-gitstatus

コードは こちら です。こちらはとあるブログを参考にしたのですが、それがどのブログだったのか探せませんでした…ごめんなさい…。

メリットとしては、言うまでもなく git status が簡単に確認できることです。余計な差分が生まれてないかもすぐに確認できるので良いです。ただし、 rails new などの大量の新規ファイルを生成するコマンドなどに対しては悲惨な結果になるので注意。

git-status

何気ない Enter でめっちゃ行が埋まる。

3. Git: 対話的に git checkout する

少なくとも私は、自分で作ったブランチ名ですら忘れてしまい、 checkout の度に『なんてブランチ名だっけ…』と git branch を叩いたりしていました。そこで、 インタラクティブフィルタツールの peco と組み合わせて、ブランチをインクリメンタルサーチして checkout するシェルスクリプトを書きました。

こちらのコード、 masutakaリファクタリングしたコードをコメントされておりますので、合わせてそちらもご覧ください(コメントありがとうございます!)。

gcoi.gif

gcoi は私が適当につけたコマンド名です。

4. git commit 時にdiffを表示させる

commit のコメントを書く時に、差分を見ながら書きたいな〜って思う時ありますよね。 Git のバージョンが 2.8 以上であれば、以下のコマンドを実行することで commit 時にコードの差分を表示することができます。

$ git config --global commit.verbose true

参考: git commit -v by default - Stack Overflow

5. GitHub: PRのテンプレートを用意する

PRを作成する時にテンプレートを用いると何かと便利です。PRはそのまま作業ログとして後から見返すことがあるので、状況を細かく記述しておくのが良いです。

テンプレートは、自分自身がこのPRで達成すべき目的を見失わない、レビュアー・ほかのチームメンバと目的を共有できるといったメリットがあります。また、テンプレートを全て埋められなければ 今自分がやっていることの目的が理解しきれていない ということでもあるので、そういった意味でもテンプレートを用いることは有効です。

参考までに、私が普段使っているPRテンプレートを晒します。改善案募集中です。

## このPRのもくてき
- 何を解決するためのPRなのか書く

## TODO
- [  ] リスト形式でやること(やったこと)を書く
- [  ] WIPが外れるまでのタスクをリストアップする

## 確認方法
- レビューする人がどうすれば動作確認できるか書く
- スクショでも良い

## その他
- 他に書くことがある場合
- とくになし

What/How を記述し、目的をはっきりさせることを意識しています。

6. GitHub: オリジナルのLGTM画像を用意する

エンジニアたるもの、オリジナルのLGTM画像の1枚や2枚は持っておいて損はありません。私のオリジナルLGTM画像はこちら。

orginal-lgtm

学生時代に魔が差して描いた落書きです。

明日は

すーさんこと弊社 CTO hapicky によるPodcastとか読書会とかの話です!