学習記録 7日目
7日目の学習記録をまとめていきます。
学習計画
- Udemy講座 もう怖くないGit!チーム開発で必要なGitを完全マスター CHAPTER 7-10
- Linux標準教科書 4, 5章
- リーダブルコード 12章
- オブジェクト指向設計実践ガイド 1章
学習内容
Udemy講座 もう怖くないGit!チーム開発で必要なGitを完全マスター CHAPTER 7-11
- プルリクエストとは自分の変更したコードをリポジトリに取り込んでもらえるよう依頼する機能。
- git push後にプルリクエストを送信。コードレビューを行い問題なければプルリクエストをマージする。その後ブランチを削除する。
- ブランチのプルリクエストを作成するにはGitHubのPull requestタブ上のNew pull requestから行う。
- レビューの受け取りもPull Requestタブから行う。
- Files cahngedタブで変更の詳細を確認出来る。
- レビューが完了したらReview changesボタンからApproveラジオボタンを選択しSubmit reviewボタンを押す。
- レビューされたらMerge pull requestボタンを押しConfirm Mergeボタンを押す。マージしたためブランチは不要になるのでDelete Mergeボタンを押す。
- GitHub Flowとはmasterブランチからブランチを作成し、ブランチをpush後、プルリクエスト、レビュー、マージをする手順のこと。
- masterブランチは常にデプロイ出来る状態にすること。
- 新しい開発はmasterブランチから新しいブランチを作成すること。
- 作成した新しいブランチ上で作業を行いコミットしていく。
- 定期的にpushすることで他チームに現状が分かるようにする。
- masterにマージする前に必ずプルリクエストすること。
- masterブランチにマージしたらすぐにデプロイを行う。テストとデプロイ作業は自動化する。
- リモートリポジトリから変更を取り込む方法としてmerge以外にリベースがある。リベースを使用するには以下のコマンドを使用する。
$ git rebase <ブランチ名>
- リベースをすると親コミットが指定したブランチへ変更される。指定したブランチのコミットを取り込むことが出来る。
- GitHubにプッシュしたコミットをリベースしないこと。これをしてしまうとpushができなくなる。
- プッシュしていないローカルの変更にはリベースを使い、プッシュした後はマージを使う。GitHub上のブランチの分岐はプルリクエストでマージする。
- git push -fは絶対使用してはいけない。(強制プッシュ)
- マージのメリット・デメリット
- メリット: コンフリクトの解決が比較的簡単
- デメリット: マージコミットがたくさんあると履歴が複雑化する
- リベースのメリット・デメリット
- メリット: 履歴をきれいに保つことができる
- デメリット: コンフリクトの解決がマージに比べて若干面倒(コンフリクトが各コミット毎に発生する
- 作業の履歴を残したいならマージを使用する。
- プルにはマージ型とリベース型がある。
- プルのマージ型は通常のプルである。マージコミットが残るため、マージしたという記録を残したい時に使う。
$ git pull <リモート名> <ブランチ名>
- プルのマージ型はマージコミットが残らない。GitHubの内容を取得したいだけの時は--rebaseを使う。
- マージコミットは何かを変更した時に残すもの。変更がない場合は--reabseを使用する。
$ git pull --rebase <リモート名> <ブランチ名>
- デフォルトでリベース型にするには以下のコマンドを使用する。
$ git config --global pull.rebase true // masterブランチでgit pullする時だけマージ型 $ git config --global branch.master.rebase true
- HEAD~n でn番目の親コミットを指定
- HEAD^2 でマージした場合の2番目のコミットを指定
- 複数のコミットをリベースで書き換えるにはgit rebase -iコマンドを使用する。
$ git rebase -I HEAD^3 // コミットエディタが立ち上がるので修正したいコミットをpickからeditに書き換える $ git commit --amend // ステージからリポジトリへ上げ直す // ファイルの変更がある場合は変更してからaddを行う。 $ git rebase --continue
- コミットエディタ上でコミットの順番を変えたり削除したりすることでコミットの操作が可能。
- コミットエディタ上でpickをsquashにすると直前のコミットと統合され1つのコミットにまとまる。
- コミットを分割するにはコミットエディタ上でpickをeditにして、以下のコマンドを入力。
// editにしたコミットをステージングしていない状態にする $ git reset HEAD^ // 以降変更内容をそれぞれaddしcommitしていく // それぞれのコミットが完了したら $ git rebase --continue
- コミットを参照しやすくするためにタグを付ける事ができる。タグはリリースポイントによく使われる。
- タグを一覧表示するためには以下のコマンドを使用する。
$ git tag // patternを指定する $ git tag -l "pattern"
- タグには注釈付きタグと軽量タグの2種類がある。
- 注釈付きタグを作成するには以下のコマンドを使用する。注釈付きタグは自動で署名を付けられる。
$ git tag -a <タグ名> -m "<メッセージ>"
- 軽量版タグを作成するには以下のコマンドを使用する。軽量版タグはタグ名しか情報がない。
$ git tag <タグ名>
- tagは現在のコミットにタグを付けているが以前のコミットにタグ付けも可能。
$ git tag <タグ名> <コミット名>
- コミット名はgit logで確認出来る。
- タグのデータを表示するには以下のコマンド入力する。
$ git show <タグ名>
- git pushではタグが送信されない。リモートにタグを送信するためには以下のコマンドを使用する。
$ git push <リモート名> <タグ名> // タグを一斉送信 $ git push <リモート名> tags
- コミットはしたくないが別のブランチで作業しなければならない場合、stashコマンドで作業を一時避難させる。
$ git stash
- 避難した作業の一覧を表示するには以下のコマンドを使用する。
$ git stash list
- 避難した作業を復元するには以下のコマンドを使用する。
$ git stash apply // ステージの状況も復元するには $ git stash apply --index // 特定の作業を復元する $ git stash apply <スタッシュ名>
- 避難した作業を削除するには以下のコマンドを使用する。
// 最新の作業を削除 $ git stash drop // 特定の作業を削除 $ git stash drop <スタッシュ名> // 全作業を削除 $ git stash clear
Linux標準教科書 4章
- コンソールに標準出力された文字列はリダイレクトを用いることでファイルに書き込むことが可能。リダイレクトは>を使って表す。
$ ls > ls-output
- catコマンドとリダイレクトを用いることでファイルの作成が可能。
$ cat > cat-output Hello, World!! // Ctrl+Dで終了
- コマンドとコマンドをパイプ「|」でつなげることで標準出力にたいしてコマンドを連続で実行出来る。
$ ls -l /user/bin | less // lessはページング表示
$ ls | grep -e html$ index.html home.html ...
Linux標準教科書 5章
- ファイルの先頭や末尾など一部を閲覧するにはhead, tailコマンドを使用する。デフォルトの表示行数は10行。パイプ可能。
// オプションは-n -cがある $ head -n <行数> <ファイル名> $ tail -c <バイト数> <ファイル名>
- tailには-fオプションがある。使用すると変更のリアルタイム反映が可能になる。
- ファイルの中身をソートするには以下のコマンド使用する。破壊的ではない。
$ cat > score yoshinori kuwazu 85 keiichi oka 70 toru minemura 100 // 昇順 $ sort score keiichi oka 70 toru minemura 100 yoshinori kuwazu 85 // 降順 $ sort -r score yoshinori kuwazu 85 toru minemura 100 keiichi oka 70 // 列指定でソート。但し辞書式ソートのため数値の一文字目で判定される。 $ sort -k 3 score toru minemura 100 keiichi oka 70 yoshinori kuwazu 85 // 数値としてソートするには-nオプションを使用。 $ sort -n -k 3 score keiichi oka 70 yoshinori kuwazu 85 toru minemura 100
- 行の重複を削除するにはuniqコマンドを用いる。破壊的ではない。
$ cat > uniq-sample AAA BBB CCC CCC DDD $ uniq uniq-sample AAA BBB CCC DDD
- 文字列の置き換えはtrコマンドを使用する。破壊的ではない。
$ cat > translate Android iPhone Windows Phone $ cat translate | tr on ON ANdrOid iPhONe Windows PhONe // 出力結果の保存 $ cat translate | tr on ON > translate2 $ cat translate2 ANdrOid iPhONe Windows PhONe
- ファイルの差分を調べるにはdiffコマンドを用いる。
$ echo "test test" > file1 $ echo "test text" > file2 $ echo "newline" >> file2 $ diff file1 file2 1c1,2 < test test --- > test text > new line $ diff -u file1 file2 --- file1 2020-10-12 15:19:13.000000000 +0900 +++ file2 2020-10-12 15:19:30.000000000 +0900 @@ -1 +1,2 @@ -test test +test text +new line
- -uオプションが非常に分かりやすいと感じた。file1に対して「test test」の行がマイナスされ「test text」が追加された。次の行は「new line」が追加されている。+と-で見やすい。
リーダブルコード 12章
オブジェクト指向設計実践ガイド 1章
- オブジェクトはそれぞれが自身の振る舞いを持ち、互いに作用し合う。
- アプリケーションに完成はない。アプリケーションは追加で変更が加えられていく。その際重要となってくるのが設計である。変更が容易に行える設計であるべきだ。
- オブジェクト指向のアプリケーションは部品から構成される。部品(オブジェクト)が相互作用し合い(メッセージを送り合い)、全体の振る舞いが生まれる。
- 正しいメッセージを正しいオブジェクトに届けるためには、メッセージの送り手が受け手のことを知っている必要がある。この知識がオブジェクト間の依存関係を作りだす。オブジェクト指向とはこの依存関係を管理することである。
- オブジェクトが知識を持ちすぎるとそのオブジェクトを変更した際オブジェクト以外の部分にも変更が影響しプログラム全体を修正しなければならなくなる。
- オブジェクト指向の設計原則としてSOLID(単一責任, オープン・クローズド, リスコフの置換, インターフェース分離, 依存性逆転), DRY(Don't Repeat Yourself), デメテルの法則がある。
- 原則に加えオブジェクト指向にはパターンがある。パターンを用いれば一般的に共通する問題に対し同じ名前を付け同じ手法で解決することが出来る。
- 設計原則とパターンに乗っ取り設計を行った結果、美しいコードになるかはプログラマの設計の経験次第である。
- 設計を上手く出来なくてもアプリケーションは作れる。だが、変更していくうちに変更が困難なアプリケーションになってしまう。
- オブジェクト指向プログラミングに対し非オブジェクト指向プログラミングのことを手続き型プログラミングという。(そのような言語のことを手続き型言語という。)
- 手続き型言語は指定されたデータ型や振る舞い以外の新しいデータ型や振る舞いを作成することが出来ない。データと振る舞い間には隔たりがあり完全に別物である。
- オブジェクト指向言語、例えばRubyはデータ型や振る舞いをまとめてオブジェクトとして扱っている。オブジェクトは振る舞いを持っているしデータも持っている。オブジェクトは互いにメッセージを送り合うことで互いの振る舞いを実行する。
- オブジェクト指向言語はまったく新しい型を考案することが可能。