■Git
https://backlog.com/ja/git-tutorial/intro/01/
コマンドを使わずに理解するGit - Qiita
Gitを使いこなしたい！〜仕組みとコマンド24選〜 - Qiita
[初心者向け]GitとGitHubの使い方を徹底解説 - Qiita

Gitのローカルリポジトリには下記がある
リモートブランチ (リポジトリのorigin ブランチのmaster)
=== ↕ ===
ローカルリポジトリ(上記の4つが含まれる)
┣リモート追跡ブランチ (リモートのコピーをローカルに置いている、git fetch、ブランチのorigin/master)
┣ローカルブランチ (git merge/pull、ブランチのmaster)
┣インデックス(コミットデータ git commit)
┗ワーキングツリー (実データ)
ブランチの概要 #初心者 - Qiita
最もポピュラーなリモートリポジトリ名の 「origin」 にあるmaster
ローカルリポにあるリモート追跡ブランチでは「origin/master」
ローカルブランチでは「master」
　origin master はリモートのoriginリポのmasterブランチを○○するという意味
　origin/master はローカルリポにあるリモート追跡ブランチを○○するという意味

Gitクライアント、Sourcetree/TortoiseGit etc
ローカルリポジトリとリモートリポジトリを作りソース管理、通常別途で運用サーバにデプロイ
　ローカルのリモート追跡ブランチ（リモートリポジトリのコピーをfetch）は
　originという名がつきorigin/ブランチ名、リモート/ローカルのデフォブランチは両方通常はmaster
　チェックアウトするとローカルの作業ソースの内容がその版に切り替わる
ワークツリー（作業）とインデックス（中間）を持ちローカル作業をindexにaddしcommit
バグ修正や機能追加などの異なる意味を持つ変更は、できるだけ分けてコミット
コメント　1行目 : 変更内容の要約　2行目 : 空行　3行目以降 : 変更した理由

cloneで、リモートリポジトリの内容を丸々ローカルリポジトリとしてDL
Pullで、リモートリポジトリから最新の変更履歴をローカルリポジトリにDL

Staged changes(index)に入れる　→ コメントを付記しCommitする
PushしリモートリポジトリにUPする（fast-forwardマージ）

///ブランチ運用モデル　https://backlog.com/ja/git-tutorial/stepup/05/
master（デフォ）
hotfix
release
develop
feature
　masterとdvelopの２つがメインブランチで大きな流れ
　releaseブランチでリリースの調整、ブランチ名にrelease-をprefix
　緊急修正の場合hotfixブランチで調整、hotfix-をprefix
　featureブランチで機能追加しdevに纏める
※もしUAT/QAサーバがあるならmaster/developに加えてもう一本QAブランチがあってもいい

使用（ワークツリー）のブランチを切り替えるにはチェックアウト
HEADとは現在使用しているブランチの先頭を表す(更新の先頭のイメージ)

stashでコミットしていない変更を退避させ、今すぐやりたい作業をしてから、退避させていた変更を取戻して作業を再開することができる（変更があればcommitするまでブランチを切り替えができない）

mergeは複数のブランチを統合し両方の変更を取り込んだマージコミットが作成されます。masterブランチの先頭はそのコミットに移動。non fast-forwardを行うとブランチがそのまま残る

rebaseはmasterブランチの前に別ブランチの内容を付与する。先頭はmasterブランチのままなので、mergeもする。トピックブランチに統合ブランチの最新のコードを取り込む場合はrebaseを使う。iオプションでコミット書換、入替、削除、統合の制御可 git pull --rebase
git pull と git pull –rebase の違いって？図を交えて説明します！ – KRAY Inc.
git pull --rebaseをpushする前にやろうという話。 - Qiita
自分の作業中に元のブランチに変更がかかった場合、その変更を取り込んでPushする必要がある＞マージかリベース (リベースの方がツリーがきれい)
master ブランチ用のfeat/20240727a の場合
　git pull --rebase origin master
　　リモートリポジトリ (origin) から指定されたブランチ (master) の最新の変更をもとにリベース
　git pull-rebase
　　カレントの作業ブランチがビハインドなのでPushできないためリベース
　git push
stgプランチ用のfeat/20240727a-stg の場合(stgブランチから切った作業ブランチ、masterから切った作業ブランチをマージしている)
　git pull-rebase origin staging は不要で上記のリベース分をマージする
　git merge feat/20240727a
　git push
ちなみに下記はデフォルトのまま git pull-rebase等のオプションで操作するのが良さそう
　git config pull.rebase false #merge (the default strategy)
　git config pull rebase true #rebase
　git config pull.ff only #fast-forward only
Gitのマージ(pull)方式には、fast-forward & non-fast-forwardの2種類
　ffの早送りは自分の作業ブランチでの走行中に他の修正がなく先頭になる
　デフォルトだと merge なのか fast-forward なのか実行時に判明する

pullを実行してから次のpushをするまでの間に、ほかの人がpushをしてリモートリポジトリを更新してしまっていた場合、マージを行なって他の履歴での変更を取り込むまで自分のpushは拒否されます（競合）マージは自動統合を行うが同じ箇所の場合はエラー。解決をして自分でコミットする必要がある

fetchは単にリモートリポジトリの内容を確認したいだけの時。ローカルに統合したい時はFETCH_HEADをマージするか、改めてpullを実行します

軽量タグと注釈付きタグの2種類。軽量タグはローカルで一時的に使用。タグで過去に戻せる

amend：直前のコミットを修正
revert：指定したコミットを打ち消すコミット
reset：コミットを捨てる
　変更したインデックスの状態を元に戻す(mixed)
　最近のコミットを完全に無かったことにする(hard)
　コミットだけを無かったことにする(soft)
cherry-pick：指定のコミットを現在のブランチに取り込む
mergeのsquashオプション：該当ブランチの全コミットを一つのコミットに纏めて統合

（競合は修正してaddし直したいが、、、）
fetchでエラーがあれば git reset --hard HEAD　で作業を取り消し
pullでエラーがあれば git merge --abort　と git reset --hard HEAD　でマージと作業取り消し
githubでマージエラーがあれば git checkout kuso-sagyo > git pull origin master > 競合解消作業 > git commit > git push origin HEAD

プルリクエスト　https://backlog.com/ja/git-tutorial/pull-request/03/
機能追加や改修など作業内容をレビュー・マージ担当者やその他関係者に通知する
　プッシュされたコミットは自動的にプルリクエスト上に反映
　プルリクエストは一覧され未完了のプルリクエストを確認しレビュー・マージ担当者は漏れなく処理可
　ソースコードの変更箇所をわかりやすく表示、コメントのやり取り可
1[開発者] 作業対象のソースを clone または pull
2[開発者] 作業用のブランチを作成
3[開発者] 機能追加、改修といった開発作業
4[開発者] 作業が完了したら push
5[開発者] プルリクエストを作成
6[レビュー・マージ担当者] 通知されたプルリクエストから変更を確認しレビュー
7[レビュー・マージ担当者] レビュー結果を判断し必要ならば開発者にフィードバック
8[レビュー・マージ担当者] レビューの結果、問題がない場合はマージ
9[レビュー・マージ担当者] レビューの結果、対応自体が不要となるなど、プルリクエスト自体が必要ない場合はクローズ

新しいverのSourcetreeではインストールができなかった　ver 2.6.10.0ならOK
https://www.sourcetreeapp.com/download-archives
　IEは上手く動かず　Chromeを使う　こちらでもインスコはできなかったが
　SSH鍵をputtyで　https://webkaru.net/linux/putty-ssh-login-public-key/
　データフォルダに.gitフォルダがあるので別のGITクライアントでもデータフォルダをDDするだけ
　文字化けはKB4074906では直らなかった、UTF8⇔Shift-jisでも直らん？

Virtualbox等のLinux環境でインストールが良いかも？
sudo apt-get install git　だったかと

gitのバージョンを上げる
プロキシを引き継ぎながら最新GITを取れるように ppaをリポジトリに追加
sudo -E add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt upgrade
git --version
====================
git init --bare --shared　空のリモートリポジトリ（ワークツリーのない開発メンバー全員で使う共有のリポジトリ）を作成
　git remote add origin https://github.com/YY/XX.git　リモートリポジトリに名前設定：git remote add [追加リモートリポジトリ名] [追加する場所リポジトリ]
　git remote -v　リモートリポジトリの確認

git init　各人使用したいローカルディレクトリに移動しリポジトリ(dir)の.gitを作成
git status　状態確認

git clone https://github.com/YYYYYY/XXXXX.git　リモートリポジトリのクローンをローカルに作成
　※作成した場所にcdし実行、リポジトリのフォルダもできるのでローカルの/home/おまはん/repoで実行でよい
　git clone ssh://user@hostname/path/to/repos　GitHub用(鍵登録しssh)

git branch　移動できるブランチとカレントを表示
　git branch -a　ブランチの一覧を見る(リモート側？)
git checkout master　ローカルの使用ブランチを切替

git pull origin master　リモートの該当ブランチをローカルの使用中のブランチに（git pull=fetch+merge）
　git fetch origin master　リモートのデータをリモート追跡ブランチに取り込む（変更点を確認
　git merge origin/master　リモート追跡ブランチにある変更点を取り込む
　【Git基礎】git push origin masterのmasterはローカル/リモートどっちのこと？ #Git - Qiita
　　git fetch origin master はリモート側のマスターブランチを差す
　　git push origin master はローカル側のマスターブランチを差す
　　　ソース:行き先　が本来だが行き先が省略されている

git checkout -b hotfix　ブランチhotfixへ移動(-bをつける事でカレントから新規にブランチを作成し移動)
　git branch hotfix　ブランチhotfixを作成（カレントから？
　git checkout hotfix　ローカルの使用ブランチを切り替え
　※hotfixで修正する場合

git checkout a.txt　特定ファイルの変更を取り消す
git checkout .　add前の未追跡編集ファイルの取り消し、作業を取消し別ブランチ切替ができるように
git clean -df .　add前の未追跡新規ファイルの取り消し
git reset HEAD .　addを取り消し
gitでいろいろ取り消したい #Git - Qiita

git add a.txt　削除したファイルをaddでリポジトリから削除
git rm a.txt　リポジトリから削除しディレクトリからも削除
git rm --cached a.txt　リポジトリから削除するがディレクトリには残す
　rm a.txt　ディレクトリから削除、リポジトリには残す

git add -n .　アドの対象を表示
　git add .　カレントdir以下の全てをIndex追加(危ない)
　git add *.py　ワイルドカード
　git add a.txt　ファイル追加
　git add dirA　ディレクトリ追加
　git add -A　変更のあったすべてgit add --all

git reset .　addを取消す

git diff --cached ステージング(index追加)の内容確認

git commit　ローカルレポにindexをコミット、エディターが開く、iインサートモードで編集、ESC:wqで保存
　git commit -a -m "comment"　-aは変更点がある登録された全ファイル

git log　コマンドでコミットの履歴
git show　コミットした内容自体を確認
git reset --soft HEAD^　コミットの取り消し

git cherry-pick _commit_id_　他ブランチでコミットした内容をカレントブランチに適応

　※コミットが済んでいないファイルが残っている状態で git checkout の別ブランチ作成や git merge でmasterにマージしない事
　git reset --hard HEAD^　直前のコミットを取消(hardはcommit logが残らず、indexやworktreeもオプで戻せる、綺麗だが競合？)
　git reset --hard HEAD~2　数字で複数コミット取消
　git stash　退避／git stash list　退避リスト

git revert コミットNo.　直前のコミットを取消す再コミットでチーム開発向き(戻したcommit logが残る)
　→commit文を書かされるので保存してgit push
　誤ってmasterで修正をしてpushしてしてしまったときにはこれ
　　git logでコミットIDをしらべ、git revert <commitID>、git pushでmasterにpushしてしまう

git branch -vv　上流ブランチの名前を確認
git config --get remote.origin.url　リモートのリポジトリURLの確認

　git pull --rebase origin master　push前にリモートのmasterの更新を取り込んでおけばコミットが綺麗になる

git push　リモートに同ブランチがあれば通るがなければ下の--set-upstreamでリモートに作る
　git push --set-upstream origin hotfix　push時にリモートに該当ブランチを作成

git push リポジトリ名 ローカルブランチ名:リモートブランチ名　が本来
　リモートリポジトリのアクセス先がoriginという名前で省略設定されている
　　git push origin 20250101aaa:20250101aaa -> git push
　これ以外の場合は通常github等のリポジトリ側でPR先を変えるといいと思われるが、、
git pushの取り消しはgithub上でブランチを削除すればよいのではと

リモートでPull Requestを作成
　レビュアーはPull Reqeustを確認し問題なければリモートにマージする
　hotfix等はPull Requestをmasterにするが同時にその1度のpushをdevelopにもPull Requestする/マージも
　プルリクエストでコンフリクトしたときの対処方法（備忘録） - Laravel学習帳 (laraweb.net)

サーバーにデプロイ
　git checkout master　マスターブランチに移動
　git pull　マスターからデータを取る
　デプロイ作業（サーバにアップロード/terraform apply）

戻し（リバートバック）用にPRを事前準備をしたい
　空のaddやcommitはできない
　githubのコミットグラフで不要なコミット上でRevertボタンを押すとPRが作成される
　戻す可能性がある場合はmasterにマージせず作業ブランチでApply（下記リモートからデータ取得参照）
　　ダメならmasterでApplyし直す、あるいはRevertボタンを押す

リモートからデータを取ってくる
git branch -r　リモート追跡ブランチの一覧(pullしとけば出る)
git fetch origin darekanounko　リモートにあるブランチを取得
git checkout darekanounko　これで切り替えができる
　なければ同名で作ってpull?　git checkout -b darekanounko > git pull　これはダメ

git initの取消し
　rm -rf .git　でgit initした場所の.gitファイルを削除
gitの作り直し(最悪これで回復)
　rm -rf .git　でgit initした場所の.gitファイルを削除し、改めて git clone

git branch -d hotfix/unco072　hotfixブランチを削除 -dはマージ済みのもの、-Dで何でも削除
git push origin :hotfix/unco072　hotfixブランチをリモートから削除

git branch --merged　マージしたブランチ一覧
git branch --merged | egrep -v "\*|master|develop"　マージしたブランチmaster/dev以外
git branch --merged | egrep -v "\*|master|develop" | xargs git branch -D　それらを削除
git remote prune origin　リモートで消されたブランチをローカル反映 prune余分な枝を落とす
git branch --format "%(refname:short) %(upstream:track)"　ブランチ名とトラック状態を取得
git branch --format "%(refname:short) %(upstream:track)" | grep "\[gone\]"　削除された[gone]のみ取得
git branch --format "%(refname:short) %(upstream:track)" | grep "\[gone\]" | awk '{print $1}' | xargs -IXXX git branch -D XXX　それらはリモートで削除されており削除
git stash clear　スタッシュを消す
git gc　ガーベージコレクション
　よく使う お掃除系 git 便利コマンド集 (foresta.me)

コンフリクト
コンフリクトはgithubのPRのマージボタンがあるあたりで見れる
masterから修正ブランチを切り出しているのでstgブランチにマージしようとするとコンフリクトする
（masterには未だマージされていないが、stgには既にマージされているPR）
例えば
<<<< feat/kuso
kuso2 = dead
====
kuso = smells
>>>> stg
github上のresolve conflictで更新を掛けるとfeat/kusoPRに反映され、DEV/STGだけでなく本番へも変更が掛かってしまうため、DEV/STGから切りなおしfeatを合体させコンフリクト解消する
git checkout master
git pull
git switch stg
git pull
git switch -c feat/kuso-stg
git merge feat/kuso
コンフリクトを手修正
git add/commit/push (addがなくても強引にpushすればよい?)
githubでstgへ向けてPRを作成
元のstgへのfeat/kusoPRは却下する

git pull　で下記エラー
error: cannot lock ref 'refs/tags/v1.3.38': unable to resolve reference 'refs/tags/v1.3.38': reference broken
→cat .git/refs/tags/v1.3.38　.git内のことで対象を見る、GUIフォルダでも大体空
→rm .git/refs/tags/v1.3.38
→RMすると大概git pullができるようになっている
reference brokenでgit pullできなくなったときの対策 - Qiita

他の対応方法として
→rm -rf おまはんのリポジトリのフォルダ　フォルダごと消す
→git clone https://やり直しなはれ　クローンやり直す
→git checkout master > git pull > git checkout 飛んだbranch　（事前にgit pushで保存しとく）

not something we can merge　のエラー
ブランチ名のスペル入力間違い、あるいはローカルにないブランチでmaster pull>該当ブランチにcheckoutしpull等が必要

.gitignoreという設定ファイルにデフォルトで対象外とするファイルを設定
.git/config を見るとどのURLにpushするか分かる
リポジトリが不要になったときは.git dirを削除する。管理ファイル(ワークツリーにないファイル)が削除されワークツリーのファイルはそのまま影響がない
　ローカルリポジトリで複数のブランチがある場合、必要なブランチをチェックアウト後ワークツリーのファイルを別途保存してから削除することを勧める
リポジトリを作成し直したい場合は.git dirを削除してから改めてgit initを実行

https://www.atmarkit.co.jp/ait/articles/2003/12/news010.html　init
https://www.atmarkit.co.jp/ait/articles/2003/05/news006.html　clone
https://www.atmarkit.co.jp/ait/articles/2003/06/news019.html　pull
https://www.atmarkit.co.jp/ait/articles/2003/13/news031.html　add
https://www.atmarkit.co.jp/ait/articles/2003/19/news018.html　commit
　git: git stashの使い方 - Qiita

https://www.atmarkit.co.jp/ait/articles/2005/21/news023.html　push
https://www.atmarkit.co.jp/ait/articles/2005/22/news028.html　push衝突

https://www.atmarkit.co.jp/ait/articles/2004/24/news028.html　checkout
https://www.atmarkit.co.jp/ait/articles/2004/30/news017.html　checkout2

https://www.atmarkit.co.jp/ait/articles/2006/11/news025.html　revert
https://www.atmarkit.co.jp/ait/articles/2007/01/news015.html　revert2
https://www.atmarkit.co.jp/ait/articles/2007/10/news010.html　revert3
https://www.atmarkit.co.jp/ait/articles/2007/27/news013.html　reset
　Git revertとresetについて - Qiita

https://www.atmarkit.co.jp/ait/articles/2004/09/news018.html　log
https://www.atmarkit.co.jp/ait/articles/2004/16/news025.html　log2
https://www.atmarkit.co.jp/ait/articles/2004/17/news021.html　show
https://www.atmarkit.co.jp/ait/articles/2004/23/news034.html　show2
https://www.atmarkit.co.jp/ait/articles/2005/01/news024.html　tag
https://www.atmarkit.co.jp/ait/articles/2005/07/news009.html　tag2

https://www.atmarkit.co.jp/ait/articles/2005/08/news017.html　remote
https://www.atmarkit.co.jp/ait/articles/2005/14/news025.html　remote2

https://www.atmarkit.co.jp/ait/articles/2006/04/news022.html rm
https://www.atmarkit.co.jp/ait/articles/2006/05/news021.html rm2
https://www.atmarkit.co.jp/ait/articles/2006/12/news017.html mv

■ツール
git :: bash プロンプトにブランチ名と作業ツリーの状態を表示する [Tipsというかメモ] (root-n.com)
home/.bashrcに追記、1行目が切れがちで注意