特定のブランチのファイルを現在の作業ブランチにマージする方法
特定のブランチのファイルを現在の作業ブランチにマージする方法
あるブランチのファイルを現在の作業ブランチに移動させたいケースの対応方法を記載
例）materブランチのhoge.textを現在の作業ブランチに移動（コピー）させる
git checkout origin/master app/views/hoge/hoge.text
個人開発のおすすめ無料素材
Railsのメリット、デメリット
メリット
■ 開発速度が速い
RaislはRubyを使ったフルスタックWEBフレームワーク（DBを扱うActiveRecordが優秀、、メールを送る仕組みがデフォルトである、ジョブを実行できる）で、Rails Wayな書き方をすることで開発スピードを上げることが出来る。
Rails Wayについてはこちらの記事が参考になる Only My Rails Way
■ フルスタックフレームワーク RaulsはフルスタックフレームワークでWEB開発に必要な機能を大枠全て兼ね備えています。
例） - DBを扱うActiveRecord - メールを送る仕組み - ジョブを実行できる仕組み - ストレージ管理の仕組み
デメリット
■ ActiveRecordを利用すればSQLを知らないのにSQLが書ける
ActiveRecord(O/Rマッパー)を利用すると、SQLを知らなくてもSQLを書くことができます。
ただ、難しい処理の場合実際に発行されるクエリがわかりにくい、ActiveRecordから逸脱したことをやろうとすると面倒といったデメリットもあります。
■ 実行速度が遅い
スクリプト型プログラミング言語のRubyでは、Rubyコマンドが読み込んだプログラムを逐次解析して処理を実行します。 そのためコンピュータで直接実行できるプログラムに変換するコンパイル型に比べると、処理速度が遅いです。
結論、Railsは利用すべき？
結論はAPIモードとしてRailsを利用するケースが一番良い。
Railsはフルスタックフレームワークなので、もちろんViewを持っていてHTML出力も可能ですがフロントフレームワーク（Vue.js, React）と相性が良くない。
なので、フロントとバックエンドは完全に分けて利用するのがよい。
どんな企業がRailsを採用すべき？
Railsの最大のメリットは、開発スピードが速く高速でPDCAを回すことが可能なことです。
そう言った特徴を考えると、スタートアップ企業にとっては一番良いフレームワークなのかなと考えます。
参考
DB設計をするときに気をつけていること
データベースはシステムの基盤です。
DB設計に失敗するとアプリケーションの実装が複雑になる、などの辛い思いをします。
また、後から修正するのは実装影響が大きいため容易ではありません。
DB設計する上で自分が普段気をつけている箇所を記載します。
1, 検索するカラムにはINDEXを貼るようにする。（JOINするテーブルが２つ程度なら問題ありませんが、JOINの回数が増えると急激に重くなるの）
2, 後から必要になりそうなデータ（ユーザー情報）削除は物理削除ではなく、論理削除にする
3, booleanの場合はnull許容しない、またdefult値を必ず設定する
4, 自分だけではなく他人が見てわかりやすいカラム名称をつける
5, ユーザー（利用者）の購入履歴などのユーザーが後で見返したい情報は履歴テーブルに保存する
6, 開発者が後のバグなどを調査しやすいようにログテーブルを作成する
7, Json形式での保存はできる限り避ける（JSONデータ型は汎用性が高く便利だが、保存内容が不透明、SQL検索しづらいなどのデメリットが多い）
8, booleanのカラムはひと目でわかるようにする（is can has_ の様なprefixを付ける）
9, 正規化する
参考
DBエンジニア必見 => 名著「失敗から学ぶRDBの正しい歩き方」のまとめ - Qiita
【初心者向け】データベースのテーブル設計で僕が意識している6つのこと - Qiita
gitコミットをまとめる方法
gitコミットをまとめる方法
コミットメッセージを修正する場合
コミットID_4 (HEAD -> master)コミットメッセージ_4 コミットID_3 コミットメッセージ_3 コミットID_2 コミットメッセージ_2 コミットID_1 コミットメッセージ_1
1, git rebase -i <コミット ID>
コミットID_2 〜 コミットID_4 をまとめる場合は コミットID_1
git rebase -i HEAD^^^
HEAD^^^^で3つ分のコミットを編集します。
2, Edit モードで rebase 指示書を修正する
r コミットID_2 コミットメッセージ_2 f コミットID_3 コミットメッセージ_3 f コミットID_4 コミットメッセージ_4 # Rebase xxxxx..yyyyy onto zzzzzz # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
3. コミットメッセージの修正
Edit モードを :wq でセーブして抜けるとコミットメッセージの修正が求められるので修正する
ミスったときの対象方法
error: cannot 'fixup' without a previous commit You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'. Or you can abort the rebase with 'git rebase --abort'.
こうなった時は、git rebase --abortで元に戻せます
参考リンク
基本これみればOK
Gitのコミットメッセージを後から変更する方法
ケース１「直前にコミットしたメッセージを変更する」
あ、コミットメッセージ名をtypoしてしまった！などの時に利用できる。
1. コミット履歴を確認して、直前のコミットしたメッセージ内容を確認
git log --onelineでコミット履歴を確認して、メッセージ内容を再確認する
2. git commit --amendでコミットメッセージ修正
git commit --amendでメッセージ修正できます。
例）git commit --amend -m "cssを修正"とすると直前のコミットメッセージをcssを修正と変更できます。
3. コミットログを見て内容が書き変わっているか最終確認
git log --onelineで再度直前のメッセージを確認してみよう。
直前のコミットメッセージが"cssを修正"`に変更されていればOK
参考リンク
ActiveRecord::Type::Booleanでフラグ条件判定する便利な方法
has_option_thumbnail == 'true' みたいな条件判定をした場合、has_option_thumbnail == 'TRUE'のような場合ではfalseと判定されてしまいます。
この対策としてhas_option_thumbnail == 'true' || has_option_thumbnail == 'TRUE'にすればOKなんですが、なんかダサい。
■ Active Model Type Booleanで条件判定する
Active Model Type Booleanを利用すればスマートに条件判定できます。
ActiveRecord::Type::Boolean.new.cast('true' ) -> true ActiveRecord::Type::Boolean.new.cast('TRUE' ) -> true
参考リンク：
