1/8 学習メモ
＜目標＞
どこまでいけるかわからないけれどいってみよう！
＜結果/感想＞
＜ギモン＞
$ git tag -n apple first commit banana サル先生のGit
なぜ二つ？ソース
<課題>
＜メモ＞
SSL (secure socket layer)
- インターネットでの暗号通信を実現している
- 機能①データの暗号化
- 機能②通信相手が信頼できることの確認
TLS(Transport Layer Security)
SSLを発展させたもの、現在はSSL3.0とTLS1.0が使われている使われている
- 送ったデータが相手に届いたか、その都度確認しながら通信するやり方
- OSI参照モデルのトランスポート層にあたるプロトコルで、インターネット等で利用される。信頼性は高いが転送速度が低いという特徴がある
- それと対比されるものにUDP(User Datagram Protocl)がある、高速だけれど信頼性が低い。
- 共通鍵暗号は暗号化と復号に同じ鍵を用いる
- 公開鍵暗号は秘密鍵と公開鍵と鍵を用いる（あらかじめ両者がそれぞれ鍵を持っている）
- サーバはクライアントに対し、サーバーの公開鍵を入れたサーバーの証明書を送る。
- クライアントは公開鍵に共通鍵を入れて送り返す
レコードプロトコル(メッセージの構成)
- 両者間のメッセージは部分はレコードと呼ばれる
- ヘッダー(データのタイプ/バーション/データ長)とデータ((ハンドシェークのメッセージや暗号化データ)に分かれる 。
ハンドシェークプロトコル
- 暗号通信をするにあたって必要な情報をやりとりする際に使われるのがハンドシェーク・プロトコルである。個々のメッセージは，「ClientHello」や「ServerHello」といった種類（タイプ）が決まっており，クライアントとサーバーの両者が，メッセージの種類を区別できるようになっている。
SSLのやりとりは，クライアントがサーバーに，暗号通信で使う暗号方式などを提案することから始まる（図3-1の(1)）。するとサーバーは，提案のあった方式から適切なものを一つ選んで返答する（同(2)）。ここまでで，暗号通信時に使う暗号方式を決める。
次にサーバーは，クライアントにCertificateメッセージを使ってサーバー証明書を送る（同(3)）。証明書の情報を送り終えたら，そのことを知らせる（同(4)）。
クライアントは，(3)で入手したサーバー証明書からサーバーの公開鍵を取り出し，この公開鍵を使って暗号通信に使う共通鍵の基になる秘密の値（プレマスタ・シークレット）を暗号化して送信する。これがClientKeyExchangeメッセージである（同(5)）。このように，実際のSSL通信では，共通鍵を直接やりとりするのではなく，共通鍵の基となるプレマスタ・シークレットをやりとりして，そこからクライアントとサーバーがお互いに共通鍵を生成するしくみになっている。こうすることで，共通鍵が漏えいする可能性を少しでも低くしているわけだ。
サーバーは，この暗号化したデータを自身の秘密鍵で復号すると，プレマスタ・シークレットが出てくる。この時点で両者は，共通鍵の基となるプレマスタ・シークレットを共有できた。
Lesson2で見た証明書のやりとりが3番目のCertificateメッセージによって，共通鍵のやりとりが5番目のClientKeyExchangeメッセージによって実現されている。
この先クライアントは，これまで決めた暗号方式の採用を宣言し（同(6)），ハンドシェークの終了をサーバーに知らせる（同(7)）。これを受けたサーバーの動作もクライアントと同様だ。暗号方式の採用を宣言し（同(8)），ハンドシェークの終了をクライアントに知らせる（同(9)）。以上でハンドシェークは終了である。
これ以降クライアントとサーバーは，共有したプレマスタ・シークレットから共通鍵を生成し，その共通鍵を使って暗号通信を実施する。
- サーバーが認証局に発行してもらう
サーバー証明書には，サーバー運営者の組織名，認証局の組織名，証明書の有効期限，サーバーの公開鍵などの情報が書き込まれている。さらに，サーバー証明書には認証局の署名が付いている。署名とは，証明書の内容をハッシュした値を，認証局の秘密鍵で暗号化したデータである。
- 認証局にもレイヤがあり、認証局を認証する機関の大元をルート認証局という
TLS1.0/1.1は無効化 1.2を使用[
](https://ssl.sakura.ad.jp/column/tls-invalidation/
GIT
コミットを実行すると変更履歴を記録したコミットがレポジトリに作成される コミットメッセージの書き方
1行目 : コミットでの変更内容の要約 2行目 : 空行 3行目以降 : 変更した理由
- ワークツリー 作業をするでディレクトリ
- インデックス コミット前のファイルを登録する置き場所
- インデックスからコミットする
- インデックスを使い、ファイル全体ではなく一部をコミットできる
先ずはレポジトリを作り"git init"を実行
- 新規ファイルは追跡対象になっていない、インデックスして初めて追跡対象になる
- git addに.を指定するとすべてのファイルをインデックスにaddする
- コミットが終了するとステータスがクリーンになる
リモートリポジトリをクローンする
$ git clone <repository> <directory>
- リポジトリをそのまま落としてくる
- 別のリポジトリにコピーする
- pull 変更履歴をダウンロードしてローカルレポジトリに反映させる
$ git clone https://nulab.backlog.jp/git/BLG/tutorial.git tutorial2 Cloning into 'tutorial2'... Username: <メールアドレス> Password: <パスワード> remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done.
リモートリポジトリを登録する
$ git remote add <name> <url>
originという名前でリモートリポジトリを登録する。 gitはリポジトリ名を指定しなければ自動的にoriginが指定されるため。
$ git remote add origin https://[your_space_id].backlog.jp/git/[your_project_key]/tutorial.git
プッシュコマンド、refspecはブランチ
｀$ git push
$ git push -u origin master Username: <メールアドレス> Password: <パスワード> Counting objects: 3, done. Writing objects: 100% (3/3), 245 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To https://nulab.backlog.jp/git/BLG/tutorial.git * [new branch] master -> master
git pull
$ git pull <repository> <refspec>...
Merge
先に他人がリモートレポジトリをを変更した場合、自分がpushするとその他人の変更が消えてしまうために、pushは拒否される。 自分の変更ができるとこまでさかのぼってその変更を取り込むことをマージするという。マージした時点から編集を始められる。
conflict
<<<<<<< HEAD commit インデックスの状態を記録する ======= pull リモートリポジトリの内容を取得する >>>>>>> 4c0182374230cd6eaa93b30049ef2386264fe12a
=======上はローカルレポジトリ、下はリモートレポジトリ
ブランチ
- レポジトリを部門ごとに分岐させ、それぞれで作業を行い、あとでマージする。
- 最初のコミットでマスターブランチが作られる。
- 統合ブランチ＝リリースバージョン、根幹のブランチ。通常はマスターブランチを使用する
- トピックブランチ：部分に分けて開発を行う際に分けるブランチ
チェックアウト
- ブランチの切り替え
- HEADとは、現在使用しているブランチの先頭を表す名前です。デフォルトではmasterの先頭を表しています。HEADが移動することで、使用するブランチが変更されます。
stash
まだコミットしていない変更内容や新しく追加したファイルが、インデックスやワークツリーに残ったままで、他のブランチへのチェックアウトを行うと、その変更内容は元のブランチから、移動先のブランチに対して移動します。
ただし、移動先のブランチで、同じファイルが既に何らかの変更が行われている場合はチェックアウトに失敗します。このような場合は、変更内容を一度コミットするか、またはstashを使って一時的に変更内容を退避させてからチェックアウトしなければなりません。
stashとは、ファイルの変更内容を一時的に記録しておく領域です。stashを使うことで、ワークツリーとインデックス中でまだコミットされていない変更を一時的に退避させることができます。退避させた変更は後から取り出して、元のブランチや別のブランチに反映させることができます。
merge
mergeを使用すると、複数の履歴の流れを合流させることができます。
rebase
統合ブランチのコミットの先にトピックブランチのコミットを追加する。 そのとき発生するコンフリクトは解決する。
merge
変更内容の履歴はそのまま残るが、履歴が複雑になる。
rebase
$ git rebase master今いるブランチをmasterにrebaseする
履歴は単純になるが、元のコミットから変更内容が変更される。そのため、元のコミットを動かない状態にしてしまうことがある。
- トピックブランチに統合ブランチの最新のコードを取り込む場合はrebaseを使う
- 統合ブランチにトピックブランチを取り込む場合は、まずrebaseしてからmerge
fast-forward(早送り)マージ
- マージ先に変更がなくコンフリクトのないmerge
- メインブランチ
- フィーチャーブランチ(トピックブランチ)
- リリースブランチ
- ホットフィックスブランチ
$ git checkout -b
を作成し移動する。
コマンドの取り消し
$ git reset --hard HEAD~
rebaseの場合、競合箇所を修正した後はコミットではなく、rebaseコマンドに --continue オプションを指定して実行します。もし、rebase自体を取り消す場合は --abort オプションを指定します。
$ git add myfile.txt $ git rebase --continue Applying: pullの説明を追加
pullをせずにfetch
- pullをすると自動的にマージされてしまうのを回避す流のがfetch
- fetchすることでFETCH_HEADという名前のない暫定的なブランチが作られる。
- それを希望のマージ先にマージしていく。
- つまりpullとはfetch+merge
タグ
git tag <tagname>
- 軽量タグ
- 名前を付けられる
- 注釈付きタグ
$ git tag -a <tagname> - 名前を付けられる
- コメントを付けられる/-m オプション コミットメッセージ
- 署名を付けられる
$ git tag -am "サル先生のGit" banana
git tag -n コミットメッセージ付きタグ表示
$ git tag -n apple first commit banana サル先生のGit
タグ削除
git tag -d <tagname>コミット書き換え
revert
revertでは、指定したコミットの内容を打ち消すコミットを作り出すことができます。後述のrebase -iやresetでコミットを削除することもできますが、そのコミットが既に公開済みであった場合は勝手に削除できません。このような場合には、revertで内容を打ち消すコミットを作り出すことができます。reset
resetでは、要らなくなったコミットを捨てることができます。実行時に影響範囲によって異なるモードを指定することで、インデックスやワークツリーの内容も戻すかどうか指定できます。モード名 HEADの位置 インデックス ワークツリー soft 変更する 変更しない 変更しない mixed 変更する 変更する 変更しない hard 変更する 変更する 変更する
cherry-pickcherry-pickでは、別のブランチから指定したコミットをコピーして、現在のブランチに取り込む事ができます。rebase -irebaseにiオプションを指定すると、コミットの書き換え、入れ替え、削除、統合を行うことができます。squashこのオプションを指定してブランチをマージすると、そのブランチのコミット全てをまとめたコミットが追加されます。
ローカルリポジトリとリモートリボジトリを接続(git-it)
git remote add origin <URLFROMGITHUB>にgit-hubのリポジトリのURLを貼り付ける
Add remote connections git remote add
Set a URL to a remote git remote set-url Pull in changes git pull View remote connections git remote -v Push changes git push githubからクローン
git clone <URLFROMGITHUB>
git remote add upstream https://github.com/jlord/patchwork.git
