実用Git第３版 備忘録４ コミットの書き換え

P199　履歴の書き換えについて 注意すべきこと：共有リポジトリに組み込まれたブランチの一部を改変、改ざん、改良してはならない。

P201　A-B-C-D-E-F-G  のコミットDに問題があり、取り消したい場合
　　　　git revert main~3
          Ａ-B-C-D-E-F-G-D'　　　D'はコミットDの逆（Dの効果を打ち消すようなコミット)

P202　git commit --amend　コミット後ログメッセージを修正できる。
　それ以外の活用方法として：
　　例：①誤ったコミット　②ファイルを再編集して、新たにコミット　もできるが、

　コミット履歴をきれいに残すため、①直接書き換え、必要に応じてファイルを追加、削除できる。②git addやgit rmでインデックスに変更を反映、③git commit --amendを実行
　　①speech.txt修正  git diffでインデックスと作業ディレクトリの差分チェック
　　②git add speech.txt   ③git commit --amend 必要ならコミットメッセージ編集
　　　git show-branch --more=5      git shouで確認
　　　　　　A-B-C　HEAD　　を　　A-B-C'　HEAD　　に変更したというイメージ

                                             ↓dev HEAD                                    ↓dev HEAD
P205　git reset           A-B-C-D                                                 A-B-C-D  

      オプションの影響       HEAD　　　　インデックス　　　　　作業ディレクトリ
         --soft　　　　　　　〇
         --mixed　　 　  　　〇　　　　　　　　〇
         --hard　　　  　　　〇　　　　　　　　〇　　　　　　　　　　　〇

--softの例：①file1コミット②file2をステージング③file1のコミットとfile2のステージングした変更をひとつにまとめたい④git reset --soft HEAD^ ⑤git commit -m 'file1 And file2'

  ※インデックスには影響与えてないので、ステージングはそのまま使えて、コミットだけでいいということ。

--mixedの例:①file3とfile4作成した　②コンテンツにもとづき、コミットの順序をきめたい③ git reset HEAD^ (--mixedはディフォルトなのでオプション指定なしでもOk）　④git add file4    git commit -m 'content from file4'  ⑤git add file3    git commit -m 'content from file3' 　⑥git add file1    git commit -m 'content from file1'  などのように

 ※作業ディレクトリには影響あたえないが、ステージングはリセットされるので、再度、ステージングを順序を変えて行うことができるということ。

--hardの場合は、作業ディレクトリもインデックスも含めリセットされるので、ファイルの作り直し、ステージングのやり直しをした上で、コミットすることになる。

　　

P214　git cherry-pick　　指定したコミットFをカレントブランチに加える　以下の場合はF’

   A-B-C-D-E-F-G-H  dev          A-B-C-D-E-F-G-H  dev

       ｜                                        ｜

       V-W-X-Y-Z   rel_2.3             V-W-X-Y-Z-F'   rel_2.3

     git checkout rel_2.3     のあと    git cherry-pick dev~2

P217　　reset,revertとcheckoutの関係

　　ブランチを移るとき：git checkout またはgit switch

      git resetはブランチ切り替えはしない：ブランチ名指定するとカレントブランチをリセットしてしまう　git rest --hardは既知の状態を復元することが目的

P218　他の開発者があなたの李ぴ時取りをクローンしたり、一部のコミットをフェッチしたりしているときは、リポジトリ内のコミット履歴を書き換えるようなコマンドを使うべきではない。代わりにgit revertを使う。git resetやgit commit --amendを使ってはならない。

P219 rebaseについて：書籍にはないが、簡単な例で試してみる

①topicブランチで　git rebase main　②mainブランチで git merge --no-ff topic

（--no-ffはfast-forwardなしで、そのほうがあとで管理しやすいとのこと）

③git log --graph　で確認できる

もし、①で競合が発生したら、②エディタで競合の原因(main_file)を編集し、競合を解決　③git add main_file　　git rebase --continue(P220)　　④mainブランチで git merge --no-ff topic

P221 rebaseを途中でやめたいとなったら git rebase --abort

P225  git rebase -i コミット　　とすると、指定したコミット以降のコミットが編集可

エディタで先頭のpickをsquashにすると、直前のコミットの結合され、新しいコミットメッセージのテンプレートができる。先頭の#は無視される。

実用Git第３版 備忘録３ マージ 差分 bisect

 P134 作業ディレクトリのファイルを書き換えたり、git addやgit rmでインデックスを書き換えると、リポジトリの作業ディレクトリやインデックスはダーティ状態になる。ダーティ状態でマージは簡単にはいななくなる。クリーンな状態にしてからマージが原則。

P169  git diff    作業ディレクトリとインデックスの差分

　　　　　　　　コミットする準備ができているかチェックできる
          git diff --cached commit　　インデックスと指定されたcommitとの差分
          git diff commit　　　作業ディレクトリと指定されたcommitとの差分

　　　　　　　　　　　　　git diff HEADなど
          git diff commit1 commit2　

P189  git bisect start        コミットが変わるたび  git bisect goodかbadを繰り返す。

　　　　　どのコミットから正常動作したか等チェックできる

実用Git第３版 備忘録２ ステージング

 P118 git commit --all   ステージングしてないものもすべてコミットできるが、新規のサブディレクトリとその中のファイルはコミットされない
P122　git rm data  コミットしたファイルを削除(インデックスと作業ディレクトリの両方から削除）
　　　復活したいなら  git checkout HEAD -- data   (--はファイル名であること明示）

P120　git commit -a -m trackedfile リポジトリすでにあり、追跡されているファイルを書き換えたときには、git addとgit commitの２つのステップを結合できる。しかし、ファイルを移動、削除した場合には、そうはならない。２つのステップを別々に実行する必要がある。　git rm somefile         git commit

P129  ほぼすべての.oは無視するが、vendor_filesサブディレクトリのdriver.oは追跡したい場合は、  上の階層のディレクトリの.gitignoreに*.oとして、vendor_filesサブディレクトリの.gitignoreに!driver.oというようにするとよい。

P130  git check-ignore my_package/anotherfile で、.gitignoreにひかっかるかどうか確認できる。
　git check-ignore -v my_page/anothrefileで、
　　　　.gitignore:3:my_package/   my_package/anotherfile
　　　というように、.gitignoreの３行目のmy_package/の設定に適用されているということがわかる。
      

実用Git 第３版 備忘録１ ブランチ

 P66　　新ブランチを作成するためのコマンドの基本的形式は次のとおりである。

 git branch branch-name  start-point

  start-pointを指定しなければ、ディフォルトで現在のアクティブブランチの先頭（HEAD）コミットが使われる。

P67　git branch ローカルのみ　 git branch -r リモートのみ  git branch -a ローカル、リモート両方

P73　コミットしていない変更があるときのチェックアウト

　　Please ,commit your changes or stash them before you can switch branches.

   　ブランチを切り替えるためには、先に変更をコミットするか、一時退避(stash)

　　stashしたあと、　git stash applyを切り替え先で行うとマージが必要

P74　ファイルの状態を復元

     git checkout dev~4 index.js  特定のファイルを４世代前のものに戻す

　　rm -rf server.js      git checkout server.js 　削除されたファイルを復元

      git restore [options] file という新コマンドも使える

P75　別のブランチへの変更マージ

  git checkout -m dev  

　　作業ディレクトリの現在の状態と切り替えようとしているブランチの状態に矛盾がある場合、作業ディレクトリで加えた変更を活かした形で新ブランチに切り替えたい場合に、ターゲットブランチへの切り替えと同時にマージを実行。３方向(下図のA,A1,A2の３方向という意味か？)マージであることに注意。

　　　A2　(dev)

　　　↓　

          A←A1（main:コミットしてない)

P77　マージされたブランチのベースブランチ情報:枝分かれの起点をさがすコマンド

   git merge-base original-branch  new-branch  で起点のコミットIDが表示

　　　ブランチの起点となった最初のコミットは明示的に示されていないので、そのコミット(起点）は、新しいブランチ(new-branch)が作成されたもとのブランチ名(original-branch)からアルゴリズムによって見つけられるようになっている。

      new-branch    

　　↓ 

      起点←original-branch       

P96 git log --graph  コミットグラフが枝分かれも入っていてみやすい

P101 gitkというツールをインストールしてみた。コミットグラフが表示されてわかりやすい。

detached HEAD 、Reject などよくあるミス対策をまとめてみた 備忘録

 https://kaityo256.github.io/github/advanced/index.html

を参考にさせていただいた。（以下抜粋）

１）detached HEADの対処

git switchとgit restoreは追加された機能。以前はgit checkoutが使われていたが、git checkoutに役目が多すぎたためにコマンドが分けられたとのこと。

$ git log --oneline
9b662ef (HEAD -> main) test

$ git checkout 9b662ef　　すると、以下の説明が出てくる
Note: switching to '9b662ef'.You are in 'detached HEAD' state.　　

  git switch -c <new-branch-name>
Or undo this operation with:  git switch -

ブランチを介さないでGitを操作するのは事故のもと。

git switchは直接コミットを指定することはできず、コミットハッシュとブランチ名を同時に指定する必要があるので、安全。

$ git switch -c newbranch 9b662ef　というように。

git checkoutの代わりにgit switchを使った方が良い。

（同様な理由でファイルの修正を元に戻すのもgit restoreを使った方が良い。）

※detached　HEAD　になったら「ブランチをつけてmainに戻る」が原則。

2)　Rejectの対処

　git push　で ! [rejected]     　すでに、originが変更されているのに気づかず、pushするとrejectされてしまう。

　git fetchで　ローカルのorigin/mainがリモートの作業を反映したコミットを指す。ローカルのmainと、origin/mainは、同じコミットから歴史が分岐した状態になる。

　あとはマージする。

　git merge origin/main　　衝突したら、適切に修正してgit add、git commit

　これで、リモートのmainと歴史を共有しているので、そのままgit pushができる。

　

クラウドについて

「クラウド人材」とはクラウド技術やクラウドサービスを設計・実装・運用する提供側の人材を意味する。AWSや Azureを活用したり、認定資格を取得したりすることではない。」とIPAの登氏が述べている。

https://japan.zdnet.com/article/35217768/ 

　日本は、クラウド人材を育成しようとしたけど、結果的に、クラウド人材できず、高額な使用料を外資系クラウドに払い続けることになってしまった。障害が発生してもブラックボックスなので解決不可能とのこと。

　最初に、ルールを決めてしまったもの勝ちみたいなところは、どうしてもあるのかもしれない。

reactを使ってみた

sudo npx create-react-app react-sample --template typescript

では、だめで、sudoなしだと、うまくいくようだった。

node関連のインストールを行うが、バージョンが合わないといろいろ設定に手間がかかるようだった。

なお、警告が出たので

npm WARN deprecated tar@2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.

npm install tar@6 -gtar　としたら、解決

Next.jsのほうは、細かい変更もあるらしく書籍の情報だと動かなかったりする。

たとえば、https://monotein.com/blog/nextjs-app-folder-new-things-list

のように、pagesフォルダがappフォルダに変わってルール違っていたりする。

現在進行形の技術なので、ネットの最新情報も大事なようだ。

　　pages/sample.tsx  >>>> app/sample/page.tsx  で/sampleのURLに対応

それから、getStaticProps 相応のものは不要らしい。コンポーネントの中に直接書いてもOkになったらしい。

　また、動的ページの場合　localhost:3000/posts/**ここの部分**

ならばapp/posts/[id]/page.tsxの中身は

　　export default function Test({ params }: { params: { id: string } }) {

  return (

    <div>

        <p>Test: {params.id}</p>

    </div>

  );

}としてやれば、**ここの部分**が、idに取り込まれ表示される。

https://zenn.dev/azukiazusa/articles/next-js-app-dir-tutorial

せっかく、React本買ったけど、古くて試すのがけっこう大変。が、この修正が

けっこう勉強になったりするのかもしれないが。。