git pullのエラー解決 (覚書)

 error: Your local changes to the following files would be overwritten by merge: CMakeLists.txt.user Please commit your changes or stash them before you merge. Aborting

この場合、git stash > git pull > git stash pop　を試してみる

CMakeLists.txt.user は通常 IDE のユーザー固有設定ファイルなので、プロジェクトによってはバージョン管理に含めないこともあるとか（.gitignore に追加したほうがいい）

コンフリクトしたら
<<<<<<< Updated upstream
（リモートの変更）
=======
（自分の stash の変更）
>>>>>>> Stashed changes     となっているので、===や<< >>を削除し、どちらかを残す

git add CMakeLists.txt.user

git commit -m "Resolve merge conflict in CMakeLists.txt.user"

.gitignoreにCMakeList.txt.user追加したら反映させるために

git rm --cached CMakeLists.txt.user

git rm -r --cached .

git add .

git push

Git復習

cloneせずに、zipから展開してwinPCでQtをビルドしたりしたので、gitの整合性がとれずとまどう。（こういうときはcloneするのが基本かも）

今回のようにしてしまったら、修正には、ちょっと手間がかかる。

stash → 作業中の変更を一時退避して安全にする
fetch → リモートの最新履歴を取得
reset --hard → ローカルの土台をリモートに合わせる
stash pop → 退避していた変更を土台の上に戻す
commit → 作業を正式にコミット
push → 安全にリモートに反映

まだ、gitよくわかってないところも多いけれど、失敗しながら慣れていくしかないようだ。

Qtのクロスプラットフォームでの開発 覚書

 github経由で、winでもlinuxでもコードを開発できるようにするには

安全なクロスOS運用の基本手順
git fetch                # 最新のリモート状態を確認
git pull                 # ローカルブランチに統合（最新化）
# ↓ コード修正（Linux/Windowsどちらでも同じ）
できたらpush

🔹 注意点
改行コードや文字コードの吸収
Git: .gitattributes に * text=auto
Qt: Qt::endl / QTextStream を使う
pull前にfetchで確認

gitのリモートへのクローン（備忘録）

 githubにも、方法が表示されますが、念のため手順をまとめてみました。最近は、公開鍵も使うようになっているので。

・　mkdir myproject　　cd myproject　　　　　　git init
・　echo "# My Project" > README.md　　　　　　git add .
　　git commit -m "first commit"
・リモート側で空リポジトリ作成
　　　（例: GitHubで myproject を新規作成）

・　ssh-keygen -t ed25519 -C "your_email@example.com"（または -t rsa でもOK）＞公開鍵 (~/.ssh/id_ed25519.pub) を GitHub の[Settings] → [SSH and GPG keys] → New SSH key に登録（アカウントのほうのSettingsで）＞(~/.ssh/config)につぎのようにして443ポートを使うように指定、ルータのフィルタリングを通過させたい場合必要

Host github.com
  Hostname ssh.github.com
  Port 443
  User git

・ssh -T git@github.com　で接続確認

・git remote set-url origin git@github.com:ユーザー名/リポジトリ名.git

   によりパスワード不要になる。

・ローカルのブランチ名が master の場合は git branch -M main で統一

・git push -u origin main

※毎回のプッシュを簡単にするためスクリプトを作ったら、けっこう便利。
git add .
git commit -m "commit_$1"
git push -u origin main

gitPush.sh に第一引数としてコメントも入れられるよう、上記のスクリプトにした

実用Git第３版 備忘録５ リモートリポジトリ

 P258　git init -b main fluff  開発（ノンベア）リポジトリの作成

            git init --bare -b main fluff-bare  ベアリポジトリの作成（権威ある参照箇所）

--bareオプションを指定してgit cloneを実行すると、ベアリポジトリが作られる

P261　リモートの作成　　git remote           .git/configにリモートがある　git configで操作

P263　リポジトリのブランチの分類：　リモート追跡ブランチ（リモートリポジトリの追跡が目的）、ローカル追跡ブランチ（開発ブランチとリモート追跡ブランチの変更の両方を集める）、トピックブランチ（開発ブランチ）、リモートブランチ（リモートリポジトリにある）

git branch -a
 main　　　　　　　　　ローカル追跡ブランチ
 mylocal-branch　　　　トピックランチ（開発ブランチ）
remotes/origin/main     リモート追跡ブランチ

P264　　リモートは　URLとrefspec（refの対応づけを示す）の２つからなる

　　　　　　refspecの例： +refs/heads/*:refs/remotes/remote/*   (fetchで利用)

P274 git push origin main   

P277 git branch -a

        *main                                                      ローカル追跡ブランチ

          remotes/origin/HEAD -> orign/main　　リモートがアクティブなブランチだと考えているブランチをシンボル名で示す

          remotes/origin/main　　　　　　　　　リモート追跡ブランチ

P280  git　pull は、git fetchのあと、git merge(or rebase)

P284　図で見るリモートリポジトリ開発サイクル

　　　　　　

　　　オリジナルリポジトリ　　　　AーB　←main       

　　　　　　　　　　　　　　　　　　   　　　↓origin/main　①　　　　　　　　　　　　　　

　　　クローンリポジトリ　　　　　　　　ＡーＢ　←main ③　④　　　　　　　　　

①オリジナルリポジトリのmainブランチはクローンのorigin/mainという新しいリモート追跡ブランチに導入される

②新しいクローンレポジトリのなかで、origin/mainブランチはmain（オリジナルの？）のHEADコミットを参照するように初期化される。ここではBを参照。

③クローン内にmain（ローカル追跡ブランチ）が作られる。

④mainブランチは、オリジナルレポジトリのアクティブブランチのHEADであるorigin/HEADを参照するように初期化される。（Bを参照）

　クローン後、カレントブランチとしてmainブランチを選び、チェックアウト

クローンで、X,Yをコミットすると

　　　オリジナルリポジトリ　　　　　　　AーB　←main       　　

　　　　　　　　　　　　　　　　　　　　　　↓origin/main　　　

　　　クローンリポジトリ　　　　　　　　ＡーＢーXーY　←main 

オリジナルで、C,Dをコミットすると

　　　オリジナルリポジトリ　　　　　　　AーBーCーD　←main       　　

　　　　　　　　　　　　　　　　　　　　　　↓origin/main　　　

　　　クローンリポジトリ　　　　　　　　ＡーＢーXーY　←main 

　この状態を　履歴が分岐　あるいは　フォーク　したという

自分の履歴をプッシュしようとするとき、　rejectされる

 （git push -f　で強制的に上書きもできるが）

プッシュの前に　自分のリポジトリでマージが必要

　git fetchで、オリジナルを取り込む　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　CーD　←origin/main　　

　　　　　　　　　　　　　　　　　　　　　　｜　

　　　クローンリポジトリ　　　　　　　　ＡーＢーXーY　←main 

あとは　mainブランチに　origin/mainブランチをマージすると両者を統合できる

　　　git merge orign/main

コンフリクトが起きたら　git reset --hard ORIG_HEADでYにもどることも可

マージ出来たら　git push

　　　　　　　　　　　　　　　　　　　　　　　　C　ー　D　　　

　　　　　　　　　　　　　　　　　　　　　　　｜　　　　｜

　　　オリジナルリポジトリ　　　　　　　　ＡーＢーXーYーM　←main 

　　　　　　　　　　　　　　　　　　　　　　　C　ー　D　　　

　　　　　　　　　　　　　　　　　　　　　　｜　　　　｜

　　　クローンリポジトリ　　　　　　　　ＡーＢーXーYーM　←main 

　　　　　　　　　　　　　　　　　　　　　　　　　　　↑origin/main

実用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にすると、直前のコミットの結合され、新しいコミットメッセージのテンプレートができる。先頭の#は無視される。

P237 git stash list 一時退避されたコンテキストの表示
   git stash -m コメント  でインデックスと作業ディレクトリの内容全体を一時退避          git stash popでもどす
git stash apply + git stash drop =git stash pop

例:  ①file1とfile2を作成、add、commit ②file1に追加文字　③git stash -m 'Tinkerd file1'
④git commit --dry-run　仮コミットしてみると、コミットするものなしと表示、git stashでまったく、残っていない状態であることを示している？ 
⑤ file3を作成　⑥git stashしても失敗　新しい未追跡ファイルは-uが必要 　⑦ git stash -u -m 'add new untracked file3'  

# 変更を避けておく

$ git stash

利用例１： ブランチを切り替えて、他の作業をする＞元の作業ブランチに戻る＞スタッシュを今いるブランチに適用　　git stash apply

　　ブランチを切り替えるためだけに中途半端な状態をコミットしなくてよい

利用例２：コミット…と思ったらブランチ間違いに気づいた＞コミットしないままブランチの切り替えに成功すれば良いが、コンフリクトする場合など切り替えられないこともある

git checkout 　proper-branchでエラー＞git stash＞ git checkout proper-branch＞スタッシュを今いるブランチに適用　git stash apply

利用例３：コミットしてしまったとき＞直前のコミットを取り消して、コミット前の状態に戻す。インデックスは残すので--softで　 git reset --soft HEAD^　＞ git stash＞ git checkout proper-branch＞スタッシュを今いるブランチに適用する git stash apply

P246 参照ログで、git reset --hardで削除してしまったものを復活

ログで見えなくても、 git reflog　で表示できる。それをもとに、もどりたいところを指定して　 git reset --hard HEAD@{1}　＞ git log　で確認

実用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ができる。

　

gitの基本 備忘録

今後、自分で忘れたときに参照するために、備忘録としてまとめてみた。
１workingDirectory　２stagingArea（index）　３repository(local,remote)

１から２が、add　　２から３がcommit

最初に　git init　で作業ディレクトリ作成

git add .   git commit -m 'コメント'   これらを　まとめて git commit -am 'コメント'　ともできるようだ。　git commitで、名称を入力も可能
　　直前のコミットに含めたいとき git add .  のあと　git commit --amend コミットが増えない

git log　でコミット保存が確認できる　
　git log --onelineで１行表示
　git log -p 変更状況が確認できる
   git log --graph　グラフ化
   git log --stat 何か所変更したか確認

git status 　よくわからなくなったら、ここでコマンドを参照する
　　addもcommitもしてないと 
          ・git checkout -- <file>で変更をないことにもできる
　　　　・git diff　で確認できる
　　　　　　ただし、addしていると　git diff -cachedとする

git add .　下位ディレクトリも含めステージングエリアにあげる
削除、移動は git rm  git mvを使わないといけない

git reset --hard <hash>
git reset --hard ORIG_HEAD　もとの先頭にもどすことができる
　万が一、間違ってresetしたら
　git reflog　で操作履歴を表示し、それに基づいてgit reset --hard HEAD@{n}のように

git branch <ブランチ名>　　　　git checkout -b ブランチ名　でチェックアウトも一緒に可能
git branchで　ブランチのリスト git checkout ブランチ名　でブランチ切り替え
git branch -d ブランチ名　で削除

git merge難しいとき  git merge --abort

git revert <hash> でコミットの取り消し可能　コンフリクトが起きたら、ブランチのマージで対処した方法で解消可能
別のブランチから今いるブランチへ、必要なコミットだけをコピーできる

git cherry-pick [コミットID]

作業中のファイルを保存するには、まだコミットしていない状態で、

git stash save
スタッシュのリストを見る

git stash list
・スタッシュを復活させる
git stash apply stash@{0}
・スタッシュを削除する
git stash drop stash@{0}
・スタッシュの復活と削除を同時に行う
git stash pop stash@{0}

stashの使用例：間違って違うブランチで作業していた時

コミットせずブランチを切り替えようとするとエラーが発生する。そこでgit stashで

変更がいったんメモリに

そして、正しいブランチにり替え後に、git stash popでもってくることができる

git grep “検索したい文字列”

git grep “検索したい文字列” コミット識別子
・ファイル名のみ表示する
git grep -l “検索したい文字列”
行番号を表示させるよう設定。$ git config --global grep.lineNumber true

git clone https: ⁄ ⁄ github.com/[あなたのGitHub ID]/pull-request-practice.git
git remote add upstream https: ⁄ ⁄ github.com/elmas3/pull-request-practice.git
git remote -v
git remote rm upstream

git config -l でリモートの設定が確認できる

git clone <remote> <local>でリモートからクローン出来る

ある Git ブランチのコードをチェックアウトするには、
$ git switch <ブランチ名>
のように実行しますが、そのブランチの最新コードではなく、ある特定のバージョン（コミット ID）のソースコードを少しだけ覗いてみたいということがあります。 そのような場合は、ブランチ名の代わりにコミット ID を指定してチェックアウトすることができます。
コミット名を指定して git checkout を実行すると、どのローカルブランチもチェックアウトしていない detached HEAD という状態になります。例えば、以下のように git checkout すると、この状態になります。
git checkout 0d3ce61      # コミット ID を指定
git checkout HEAD^0       # 最新のコミットを指定
HEAD が detached された状態で git branch を実行すると、どのブランチにもいないことを示す (no branch) が表示されます。
git branch
* (no branch)
 main
 mybranch
detached HEAD 状態でも git commit などのコマンドを実行できますが、どのブランチにもいない状態なので、どのブランチの head も更新されません。 再びローカルブランチ名を指定してチェックアウトすると、detached HEAD で行っていた変更を破棄してブランチの最新状態に戻ることができます。
detached HEADの状態でコミットしてしまった場合：
①変更内容が不要な場合
　detached HEADの変更内容を破棄するには、次のコマンドを実行します。
git reset --hard @
　@は最新のコミットを指します。HEADと同じです（エイリアスです）。
②変更内容を引き継ぎたい場合
detached HEADで行ったコミットを引き継ぎたい場合は、ブランチを移動後に、対象のコミット番号を指定してmergeします。
　#特定のブランチにて（masterブランチなど）
　git merge <コミット番号>
　これで指定したコミットが、現在のブランチのコミットの中に取り込まれます。
③変更内容で新しブランチを作成したい場合
変更内容で新しいブランチを作成したい場合は、コミット番号を指定して新しいブランチを作成します。
git checkout -b <新しいブランチ名> <コミット番号>