■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[レビュー・マージ担当者] レビューの結果、対応自体が不要となるなど、プルリクエスト自体が必要ない場合はクローズ
[Click for image]

新しい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行目が切れがちで注意

■ノーパンクタイヤ

4年前にも考えてた、、2020年3月に再考してるだけ、しかも殆ど同じ結論

重い、クッション性能が悪い、スポーク折れ易い　がパンクしない
ネットで見ると空気がやはり最高らしい、空気圧を正常にしていれば普通パンクしないらしいし
ムースは安くやってみる価値ありかも

ｓシンコー(shinko) パンクレスチューブ
https://www.amazon.co.jp/dp/B06XWTS7DR/?coliid=I1U44FJYPK81CL&colid=21U8GJP0VOHY6&psc=1&ref_=lv_ov_lig_dp_it
↓
やり方は
↓
e-core
https://www.amazon.co.jp/dp/B00MHJT9U4/?coliid=I9R84TPZQ5BH6&colid=21U8GJP0VOHY6&psc=1&ref_=lv_ov_lig_dp_it&th=1
ムースは2cm長めにカット、入れるときは石鹸水で滑らせる
太さにより入らない、脱輪するがあるので太さ選びは慎重に、タイヤ肉厚も考慮、やり方が不味ければリム落ちする

■他には
Tannus　中空ポリマー成型したタイヤをピン止め
https://csndiary.wordpress.com/2017/06/29/tannus/
中空構造タイヤ
https://www.amazon.co.jp/dp/B07JMGXD2L/?coliid=I194XNNO7XEAKH&colid=21U8GJP0VOHY6&psc=1&ref_=lv_ov_lig_dp_it
型善
http://www.katazen.co.jp/e-core　eコア：ムース
http://www.katazen.co.jp/e-tube　eチューブ：中空ウレタン
http://www.katazen.co.jp/afg　ゲル注入
↑
元ネタ、ココがほとんどやってる
↑
アサヒＴ－チューブ
http://www.asahicycle.co.jp/product/protectia/
フリーゲル
http://www.no-air-touring.com/about.html

↓↓↓

■しかし空気式が性能に優れているので問題が起きたときに対処でもいいかも
ムース注入：　EVERS(エバーズ) 自転車パンク修理剤 100ml 10秒注入 空気補填 PN-3
https://www.amazon.co.jp/dp/B00KYMFTB4/?coliid=I1TPJ5FJ8CI0OL&colid=21U8GJP0VOHY6&psc=1&ref_=lv_ov_lig_dp_it
貼るだけ：　パナレーサー パンク修理 イージーパッチキット RK-EASY
https://www.amazon.co.jp/dp/B000AQYT8I/ref=psdc_15334761_t2_B00KYMFTB4

---------------------

■2016-01-02　にしかも何かやってた

ムース/ウレタン系、クッション性や重さ、脱輪、経年劣化等の問題：街乗ならOKだな
http://hamamuratakuo.blog61.fc2.com/blog-entry-915.html
http://55net1.com/wp/post-314/
↓

発砲ウレタン
http://www.monotaro.com/p/4108/2343/?gclid=CL7GzYWEscsCFYwHvAodPRICmA&utm_medium=cpc&utm_source=Adwords&cm_mmc=Adwords-_-cpc-_-PLA-_-41082343&ef_id=VY-Y1QAAAaoBz58O:20160308115508:s
↓
タイヤ穴開けられるの嫌なので試した。ウレタンを詰めたが、ビードストッパが無いためタイヤがリム落ちした（脱輪）。失敗。そーいやオートバイはビードストッパ2つやったな。
ホイルナット15mm。ワックスはちゃんと事前に塗る。

---------------------

自転車タイヤのチューブ、アウチ。監視カメラ付けよ。20インチ

Panaracerタイヤチューブ 20x1.50~1.75　英式バルブ 0TH20-15E-NP 170g
701円で去年買ったが1年も経たずに駄目。日本製はダメかも。→しかしやはり横を安全ピンでヤラレてましたな、トレッドでなかった。日本製ではなく日本が駄目なのでは。

TIOGA TIT12700 20×1.50-1.75 英式チューブ 130g
やったらどうや、909円（本体475円）。重さどおり少し薄いな。

---------------------

サイドウォールが補強されているというタイヤだが十分に柔らかいな、MTBに比べてだが。なおビードは硬い模様。ロゴは良いが、タイオガ使いたいな

---------------------

■バルブの種類
英式バルブ：日本で最もポピュラーなバルブ、ママチャリや車いすなど
米式バルブ：車やオートバイ、マウンテンバイクに、頑丈、圧調整可
仏式バルブ：自転車のロードバイクが多い、高圧、軽量

■空気入れ
英式バルブ用のポンプはヘッドに押さえにクリップが必要で大きくなる
小さいポンプは大体が米/仏バルブ用
英→米式バルブ変換も使ってみたが、ポンプ時にバルブの根元に負担が
あり、チューブがパンクしそう
→携帯に大きいがホースが出る英式用ポンプが安全
→小さいのはポンピングがしんどい、小さいのは浮き輪用としる

■CYCPLUS電動エアーポンプ(Max 150psi=10.3bar=10.5kgf/cm2)
https://www.amazon.co.jp/gp/product/B085T88VNL/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
1) 米式(MTB)のチャックなので、英式(ママチャリ)や仏式(ロード)の場合はアダプターをバルブに着けてからチャックを付ける
2) 長押しパワーオン
3) 空気圧単位設定U
4) 空気圧設定＋ー
5) パワーボタンで空気入れスタート
　※誤差が大きく4.5kgf位入れる？

ママチャリの標準空気圧3kgf/cm2
　psi換算だと42.6699psi
　bar換算だと2.941995bar
　KPa換算だと294.1995KPa

HIPHOP踏み絵的なアレ再会、trap、師弟制の牽制も効いてるし、誰もが有名になれる時代、NE似ー合わねんだー

初日にプランニングミーティングを行い、直近(2週間等)のタスクを計画
そして、毎日デイリースクラムを実施し、最終日にレトロスペクションミーティングで締めて
スプリントの1サイクルとなる

ミーティングでは、タスク管理システムないしは、
ホワイトボードに張られたタスクやバックログリスト（場合によってはガントチャート）などの
タスクを一覧できるツールを用いる

 ///プランニングミーティング
 プロダクトバックログから優先順位に従って選択したストーリーをタスクにブレークダウン
 ミーティング前
 　1．タスクを決定する
 ミーティング時
 　2．前スプリントのタスク完了を確認する
 　3．メンバーの予定作業時間を確認する
 　4．スプリントのゴールを共有する
 　5．タスクを説明し工数を見積もる
 ミーティング後
 　6．タスクを割り当てる

 ///デイリースクラム
昨日何をしたか？
今日何をするか？
進捗を妨げている問題は何か？

 ///レトロスペクションミーティング
 何をしたかについて、1人数分から十数分説明する
 何ができないか、どのような課題が残っているかに言及する


↓↓↓↓↓↓アジャイルから明確にスクラム

■スクラム
https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
///対話の価値（左が要らないとは言っていない）
プロセスやツール　＜　個人と対話
包括的なドキュメント　＜　動くソフトウェア
契約交渉　＜　顧客との対話
計画に従う　＜　変化への対応

透明性：スクラムチームの現状や問題点を見える化すること
検査：見える化により問題点を見つけること
適応：スクラムチームに問題があった場合に、改善策を考えて対処すること

個人はスクラムチームのゴールの達成を確約しなければならない
メンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない
スクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開する
メンバーはお互いを能力のある独立した個人として尊敬しなければいけない

 ///プロダクトオーナー(PO)
- プロダクトバックログアイテム(PBI)の管理
- リリース計画策定
- 市場調査
- ステークホルダとの対話
- 開発チームとの対話
- 予算管理
- スプリントレビューで"DONEの定義"にしたがって受け入れ判断をする
注意点：POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。

 ///スクラムマスター（SM）
- 妨害リストの管理
- 妨害の除去
- POのサポート
- 開発チームのサポート
注意点：チームが自己組織化するために、SMはメンバーに直接的な指示（タスク割り当てなど）や管理（進捗管理など）をしてはいけない。スクラムにはPMは存在しない。

 ///開発チーム
- 開発、インクリメント（成果物）を完成
- プロダクトバックログの追加
- 妨害リストの追加
注意点：開発チームは自己組織化されており、外部から仕事の進め方やタスクを指示されるようなことがあってはならない。1つの開発チームは3-9人で構成されなければならない。それより少ないと機能横断的でなくなる可能性が高くなるためNG。多すぎると調整が大変になってしまうためNG。多すぎる場合は別のスクラムチームをもう1つ作るべき。開発チーム内で年齢や役職、会社の違いがあったとしても全員フラットな関係でなければならない。開発チームに専門能力の高いメンバーがいて、その分野ではその人に頼りがちだけど、そこで問題が起きたとしてもそれはそのメンバーだけの責任でなく開発メンバー全員の責任であることに注意する。

 ///ユーザーストーリー形式　
「〜として、〜したい。それは、〜だからだ。」を書きます。これは、INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testableの頭文字をとったもの)を満たす必要があります。プロダクトバックログのDoneの定義も定義

 ///スプリントバックログ
開発チームにより作成される。スプリント期間中での修正、追加、削除も可能である。スプリントバックログの管理を行えるのは開発チームだけである。規模や工数はバラバラで問題ないが、1つのスプリントバックログアイテムの見積もりは1日以下の大きさに分割すること。スプリントバックログアイテムは"未着手"、"着手中"、"完了"などのいずれかのステータスがラベル付けされており、そのステータスが可視化されている必要がある。JIRAでも付箋とホワイトボードによるアナログ方式でもどちらでも問題ない。自己組織化されているので、誰かに割り当てられるものではなく自ら挙手する。設計、コーディング、テストコードの作成だけでなく、結合テストなどの実施、CI環境改良、ノウハウを残すなどもスプリントバックログとして分割するべきである。

 ///妨害リスト
スクラムチーム内外で、妨害になっていることを優先度順にリスト化したものである。どのロールの人でも追加できるが、妨害リストの管理の責任者はSMである。いつでも追加可能だが、特にデイリースクラムやスプリントレトロスペクティブで課題（妨害）の共有が行われやすい。

 ///スプリント
1ヶ月以内の固定した開発期間を何度も繰り返す。1週間、2週間、1ヶ月のいずれかが一般的。スプリント期間内に完了しなかったプロダクトバックログアイテムがあったとしても、スプリントを延長してはいけない。スプリントの中止はよっぽどのことが無い限り、行われるべきでないが、もしものときは実行権限を持つのはPOだけである。

 ///スプリント0
自己紹介、スクラム理論の勉強会（認識合わせ必須）、当面のプロダクトバックログの作成と共有、必要技術スキルの勉強会、開発環境構築などを行うスプリント開始前の準備期間のこと。必要期間はチームにより異なる。

 ///リリーススプリント
インクリメントの統合テストや通常スプリントで残ったタスクを実施してリリースを行うための特別なスプリント。 原則、このスプリントは存在しません。スプリント毎にリリース可能なものを作成するので、リリーススプリントが無いことが理想だが、そうでない場合に用意される。リリーススプリントはPOがリリース準備が整ったと判断するまで続く。

 ///イベント
開発チームでイベント以外のミーティングができるだけ行われないようにする。全てのイベントはタイムボックス化されている（何分とか、何時間までとかが決まっている）。もし、タイムボックスを超えてしまった場合、議論をそこで打ち切る必要はないが、タイムボックスを越してしまったという事実は妨害リストに追加したり、スプリントレトロスペクティブで話し合う必要がある。

 ///スプリントプランニング
第一部は全てのロールが参加する。ただし、第二部はPOは連絡がつく状態であれば参加しなくてもよい。第一部では、ベロシティをもとに今回のスプリントで対応できそうな範囲でプロダクトバックログを開発チームが選択する。（POが選択してはいけない）
プロダクトバックログはリファインメントによってすでに見積もりがされている状態のはずだが、リファインメント後に新規追加されたプロダクトバックログアイテム（つまり見積もりがまだされていないもの）が含まれている場合は、この場でリファインメントを実施する。第二部では、開発チームは選択したプロダクトバックログアイテムをスプリントバックログに分割する。これにより、POとSMにどのようにプロダクトバックログアイテムを消化できるかを伝えられる状態になる。分割したスプリントバックログに時間数を見積もり、その総計が1スプリントでのチームが開発できる時間をオーバーした場合は優先度の低いプロダクトバックログから外していく。逆に余裕がある場合なプロダクトバックログを追加する。POの予想より多すぎたり少なすぎたりする場合は、開発チームとPOは話し合う。開発チームは選択したプロダクトバックログアイテムを完了することに全力を注がなければならないが、完了することを約束するわけでない。なぜならば、見積もり時にはわからなかった技術的に困難な事象が発生することはよくあるからである。無謀な長期の残業は行わない。

 ///デイリースクラム
- いつ？⇒毎日同じ時間（一般的には朝）
- どこで？⇒どこでもいいがいつも同じ場所
- 誰が？⇒開発メンバー。SMは必要に応じて参加する。POは見学（発言は基本的にNG）してもよい。
- 目的は？⇒開発チームの検査
- どれくらい？⇒最大15分
昨日やったこと、今日やること、あれば課題（妨害）の共有。課題は共有に留めること。管理職の見学は避けたい。なぜならば、共有でなく管理職への報告になりがちで自己組織化が損なわれやすいのと、課題共有がしにくい雰囲気になりやすいからである。もし管理職にエスカレーションするべき課題があるならば、デイリースクラム後に報告すること。

 ///プロダクトバックログリファインメント
- いつ？⇒スプリント期間中であればいつでも良い。
- 誰が？⇒全てのロール
- 目的は？⇒プロダクトバックログの透明性の獲得
- どれくらい？⇒最大1日(8h)
POはプロダクトバックログの説明（前回からの変更分、追加分、削除分、詳細決定部分、順序変更部分など）を行う。リファインメントの対象は、次のスプリントあるいはさらにその次のスプリントで開発対象となりそうなくらいの範囲となる。優先度低いプロダクトバックログの説明までは行う必要はない。本当に実施するかも不透明だし変更も発生しやすいため。開発チームはプロダクトバックログへの意見（追加アイディアや順序変更や質問など）、新しいプロダクトバックログアイテムの見積もり、必要であれば再見積もりを行う。

 ///プランニングポーカー
プロダクトバックログの見積もりには"プランニングポーカー"と呼ばれる手法が一般的に使われる。プ開発チーム全員がフィボナッチ数列（0, 0.5, 1, 2, 3, 5, 8, 13,...∞）の値が書かれたカードを持ち、プロダクトバックログアイテムごとに「いっせーのせ！」でカード（見積もり）を提示する。この見積もりは単位のない"相対見積もり"である。見積もりの値が似たような値で均等に分散したとき（例えば5が3人で8が3人の場合）は、悲観的に考えて大きい値（ここでは8）をストーリポイントとして計算したほうがよい。

 ///スプリントレビュー
- いつ？⇒スプリントの終わり
- 誰が？⇒全てのロールとPOが招待した重要な関係者（ステークホルダーなど）
- 目的は？⇒インクリメントの検査とプロダクトバックログの適応
- どれくらい？⇒最大2時間（スプリント2週間の場合）
開発チームはインクリメントのデモを実施して、質問に答える。また、完了できなかったプロダクトバックログがあれば説明する。開発チームはデモをやることと受け入れに通ることばかり考えがちだが、大切なのはスプリントレビューを通して、よりよいプロダクトを得るための手がかりを見つけることである。デモはそのための手段であって目的ではないことに注意しよう。また、デモの説明スライドは作るべきでない。そこに労力が割かれがちだからだ。POはDONEの定義に従い、インクリメントが受け入れ可能かを判断する。

 ///スプリントレトロスペクティブ
- いつ？⇒スプリントレビュー後かつ次のスプリントが開始される前
- 誰が？⇒SMと開発チーム。POは参加してもよいが必須でない。
- 目的は？⇒スクラムチームの検査と適応
- どれくらい？⇒最大1.5時間（1スプリント2週間の場合）
スプリントで人・プロセス・ツールの観点から問題がなかったか、もっと成果を出すためにできることがないかを議論し、次回のスプリント以降の改善策を考える。手法として、KPT（Keep, Problem, Tryを出し合うこと）がよく使われる。

 ///ベロシティ
ベロシティとは、そのスプリントで開発したプロダクトバックログのストーリーポイントの合計である。スクラムチームはベロシティを高めて安定させることを目指す。そもそもストーリーポイントがいい加減な値。フィボナッチ数列の値しかだせないし、開発者は技術的な不安点があるからとりあえず大きな値をしばしば出しがちである。さらに、スプリントの日数は祝日、メンバの休暇などでスプリント毎に異なるものである。

スクラムではテスト専門チームの存在を許していない。スプリントの中で徹底的にバグを発見して潰すべきなのである。

■スクラムガイド　Ken Schwaber & Jeff Sutherland
2020-Scrum-Guide-Japanese.pdf (scrumguides.org)

■マネジメント向け　アジャイルの利点
https://www.ryuzee.com/contents/blog/13147

■カンバン
ToDo、進捗、ワークフロー整理、振り返り、で活用できれば
カンバンの基本のキ - Qiita
※なおトヨタのカンバン方式は意味自体はJust in timeの意、中で使われていた伝達法もTodoリストと違う、生産と運搬のタグみたいなもの

■JIRA
コンポーネントはプロジェクトを分割（トップダウン）
エピックはストーリーを一定のジャンルでグループ化（ボトムアップ）
タスクはスプリントの期間で終わり作業が内容が分かるタイトルに
ラベルがあれば時間集計できるので作業ラベル