Skip to content

Latest commit

 

History

History
199 lines (125 loc) · 9.37 KB

topics.md

File metadata and controls

199 lines (125 loc) · 9.37 KB
Raw

開発・業務に役立つトピック集

本ドキュメントは、カリキュラムに具体的には含まれていませんが、知っておいてほしいトピックをまとめたものです。特定のステップに含めることができなかった話題はここにまとめておきます。

NOTE: 機能の紹介ではなく、それをこういう風に良く使っていますというアプローチでまとめたいです。

git に関するトピック

gitの詳しい解説については

https://git-scm.com/book/ja/v1/

こちらが役に立つので参照してください。 以下のトピックはそれを補足する形でよく使用されるケースを紹介します。

git のハッシュ値について

gitでは、1つのコミットについて、1つの（ほぼ）ユニークなハッシュ値が付加されます。 これは git log コマンドを実行すると確認できます。

commit a1d859d085125016938a1c25862474a15973d740 (HEAD -> add_tips)
Author: Yuuki Tanaka <[email protected]>
Date:   Tue Feb 20 14:46:25 2018 +0900

xxxx

a1d859d... というのがハッシュ値です。主に以下の用途などでよく使うので覚えておきましょう。

  • 手元のコミットの状態と、GitHubの作業ブランチ上のコミットの状態が一致しているか確認するときに、ハッシュ値をみて担保する
  • 別のブランチのコミットを一部拝借したい場合、 git cherry-pick (ハッシュ値) で特定のコミットを手元のブランチに持ってくる
  • 特定のコミットの状態に戻りたい場合 git checkout (ハッシュ値) を指定して戻る

PRを出すときに master ブランチの最新の状態を取り込む

Pull Request(PR)を出す前に、自分の作業ブランチに PRする先(研修では master ブランチ)の最新の状態を反映しておくのが一般的です。

自分が作業をしている間に他のブランチが master ブランチに取り込まれるのはよくあることで、 その変更を取り込んでおかないと、コードがバッティングしていたり、お互いが影響しあったりしてアプリケーションの動作に影響があることがあります。

研修カリキュラム中でも、レビュー待ちの間に別のブランチで作業を進めるといったことがあり、同様のことが起こりうるので、そのときには master ブランチの最新の状態を作業ブランチに取り込む癖をつけましょう。

変更を取り込むには git rebase コマンド、もしくは git merge コマンドで実施します。

git rebase コマンドを用いた場合の実施例

$ git fetch origin
$ git rebase origin/master # ※ コードがバッティングした場合コンフリクトが発生します

git rebase -i でコミットを整理する

開発中には様々な理由で、まとまった機能を実装する前に中途半端にコミットしなければならないことがあったり、コミットした後で、細かいミスに気づいて手直しをするといったことはよくあります。

そういう時、gitのコミットログが細切れになり、非常に履歴がわかりづらいものになります。 コミットをまとまった単位で整理しておくと、履歴が追いやすくなったり、cherry-pick がしやすかったり、レビューがしやすくなったりと良いことが多いので、PRを出す前に整理する癖をつけましょう。 コミットを整理するには、git rebase -i コマンドを使います。

git rebase -i コマンドを使うと、コミットの前後を入れ替えたり、複数のコミットを１つにすること(squash)ができます。例えば次のようなコミット履歴があるとします。

  • Aの機能を実装したコミット -- (1)
  • Bの機能を実装したコミット -- (2)
  • Aに些末なミスがあり修正したコミット -- (3)

git rebase -i コマンドを利用するとコミットの前後を入れ替えられるので

  • Aの機能を実装したコミット -- (1)
  • Aに些末なミスがあり修正したコミット -- (3)
  • Bの機能を実装したコミット -- (2)

と入れ替えられます。更に複数のコミットを１つにすることができるので

  • Aの機能を実装したコミット -- (1, 3)
  • Bの機能を実装したコミット -- (2)

と整理することができます。

git の便利なクライアントツール

git の公式サイトに、コマンドを直接実行しなくてもよい便利な GUI ツール集があるので色々試してみると良いでしょう。

https://git-scm.com/download/gui/mac

GitHub に関するトピック

WIP で Pull Request を作成する

Pull Requestは、通常であれば実装作業が完了した時点で作成しますが、作業途中に WIP(Work In Progress) という形で早いうちに作成することがあります。

WIPでPRを出すことは次のような利点があります。

  • 他の開発者に進捗を示すことができる
  • 開発者の目に触れるところにコードを置くことで、意識の食い違いや実装コードのまずいところを早期に発見できる
  • WIPのPRを見てもらいながら開発の相談ができる

実際の開発でもよく利用されるので、研修でもWIPでPRを出すことを実践してみましょう。

出したPRがWIPであることを示すには、PRのタイトルの先頭に [WIP] など、WIPであると分かる形で記載しておきます。機能が完成して正式なPRとするときに、[WIP] をタイトルから外します。

Rails の開発環境に関するトピック

rails console を利用する

Rails は自身のフレームワークの中に rails console という対話的な実行環境(REPL)が同梱されています。Ruby で言うところの irb ですが、 rails console では Rails の環境を読み込んだ上で実行できるため、Railsで開発を行う際は、こちらを主に使用します。

用途としては、実装した機能の確認が挙げられます。モデルにメソッドを追加した場合などは、ブラウザで挙動を確認するより、 rails console で確認したほうが効率が良いことがよくあります。

Railsのアプリケーションツリーに移動して以下のように起動して使います。

$ rails c

pry を利用する

pry という Gem を利用すると、アプリケーションの実行中に好きな場所で対話的な実行環境(REPL)を開いて現在の変数の状態や実行結果を得ることができるようになります。

公式ドキュメント: https://github.com/pry/pry/wiki

Railsにおけるインストール方法

Gemfile に以下の一文を追加します。（開発時にだけ使用するため、development と test 環境でのみ導入します）

group :development, :test do
  gem 'pry-rails'
end

bundle install コマンドを実行すると使えるようになります。

使用方法

コードのうち、状況を確認したい部分に次のように binding.pry を記述します。

def foo
  ...
  binding.pry
  ...
end

アプリケーションを実行した時点で、 binding.pry を記述した部分に処理が到達すると、そこで REPL が立ち上がるので、宣言済みの変数の中身を見たり、メソッドを実行したりできます。

ローカルにある Gem の中身を見る

開発中にアプリケーションで使用している Gem の詳しい挙動を知る必要性があることはよくあります。 その際には自分のマシンにインストールされた Gem を見たり、 Gem の中で binding.pry を記載して詳細なデータの流れを見たりして把握することが多いです。 また、Gem のコードを読んで参考にすることで、コーディング能力を磨くのにも役に立つでしょう。

bundler には、Gemfile で管理されている Gem を取り扱うのに便利なコマンドが幾つか提供されています。

bundle show

bundle show コマンドを使うと Gem が配置されている path が得られます。

$ bundle show rails
/Users/yuuki/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rails-4.2.6

bundle open

bundle open コマンドを使うと Gem を指定のエディタで開くことができます。 環境変数 BUNDLER_EDITOR でお使いのエディタを指定します。

$ export BUNDLER_EDITOR=atom
$ bundle open rails

ここから、詳しく見たいコードを精査したり、binding.pry などでデバッグコードを入れて、挙動を詳しく見ることができます。

gem pristine

Gem の内部にデバッグコードを入れたとき、もとに戻し忘れることがよくあります。 そんなときには gem pristine コマンドを使うとインストールした時点のコードに戻すことができます。

$ gem pristine rails

全ての Gem を戻したいときは次のコマンドを使います。

$ gem pristine --all

bundle pristine コマンドを使うと Gemfile 内の Gem をもとの状態に戻せます。

$ bundle pristine