Github / git：
2026年6月27日基本的な流れ
ローカル（VSコード）のmainブランチから別のブランチを作成し移動/作業を行い、
git push -u origin branch-nameでリモート（Github）のbranch-nameブランチにpushし、リモートのmainブランチへmerge（判断）する。mergeが行われたらローカルでmainブランチに切り替え、リモートのmainブランチ（ = 最新の内容）をpullし、一連の流れを繰り返す。
origin= リモート（GithubのURL）のことローカルの
branch-nameと異なるリモートブランチ名にしたいならgit push origin branch-name:testのようにする。リモートのmainブランチは直接触れることが無いようにする。これが起こるシナリオは直接リモートのmainブランチにpushする場合のみ。
ローカルのmainブランチはあくまでリモートのmainブランチ = 最新の状態のコピーなので、ローカルの状態がごちゃごちゃになることは恐れなくて良い。
gitのインストール
PCにgitをインストール：
sudo apt install gitGithubのusernameとemailをPCに紐付ける
git config --global user.name "your-username"
git config --global user.email "your-email@example.com"ローカル / ステージングエリア / リモート
add：
git add .でファイルが「ワーキングディレクトリ（作業領域）」から「ステージングエリア」へ コミット対象として変更を一時登録一時登録の履歴（ = ステージングエリアに登録された変更）は
git statusで確認できる。
commit ：
git commit -m "message"は「ステージングエリア（変更）」の内容を「ローカルリポジトリ」に記録（コミット）するcommitの履歴を確認するには
git log
push ：
git pushで「リモート（Github）」へ反映git push -u origin branch-nameとすると、以降のpushコマンドはgit pushだけで済む-uは--set-upstreamの略
git pull： = git fetch + merge
git fetchはリモートの最新の情報（だけ）を取得するコマンドで、ローカルの内容が変わることは無い。git mergeと続けることでリモートの内容がローカルに反映される。git pullは上記を一行で済ませるコマンド
過去のコミットに戻る：checkout
git checkout <commitId>：
git logからcommitIdを取得checkoutコマンド実行後に
git branchをするとHEAD (detached at xxx)のような表示になっている。この状態（detached at xxx）は現在ブランチに属していないことを意味するので、元のブランチに戻った時に
HEAD (detached at xxx)で行ったcommitにはたどり着けないため、過去のコミットに戻った理由が「そこから作業を再開したい」だった場合、HEAD (detached at xxx)から新しいブランチを作る。
ローカルbranchの作成 / 削除
git branch ブランチ名 //作成
git checkout ブランチ名 //移動１つのコマンドで行う：
git checkout -b ブランチ名ローカルbranchの削除：
git branch -d ブランチ名*どこからブランチを作成するか：
ブランチは派生元のブランチの状態を引き継ぐため、どのブランチからブランチを作成するか気をつける。
git stash
git stash ：
移動先ブランチに同じファイルがあり未コミットの変更が衝突する場合、ブランチ移動はエラーになる（Please commit your changes or stash them before you switch branches ）が、
git stashをした後だとエラーにならない。git stashは未コミットの変更を「一時退避」するコマンド（ = ブランチ移動が拒否される理由を取り除く）
コマンド：
git stash list：stashリストの表示git stash apply stash@{n}: 避難させた変更点を復元。{n}はindex値
stashの注意点：
新規作成した未追跡のファイル（一度もaddやcommitしていないファイル）は退避されない。
git stash -uを使用
Tag / Release
GithubリポジトリのTagタブから「Create new release」を選択するとTagとReleaseの作成ができる。
Tagはその時点のsnapshotに名前 / Releaseはその時点の説明・アプリの配布
github-cliから作成：
// タグの作成は自動で行われ、対話型でreleaseの内容（title / notes）の入力をする。
gh release create v1.1.0
// notesが自動で生成される。
gh release create v1.2.0 --title "v1.2.0" --generate-notes
// assetsをuploadしたい場合
gh release create v1.1.0 ./dist/app.deb ./dist/app.exe ./dist/app.AppImageReleaseはGithubの機能、TagはGitの機能
TagとReleaseはセットで考えた方がわかりやすいのでGithub-cliで作成するのが良い。
ただしTagの作成をトリガーにしてGithub ActionsでReleaseを作成するようなこともある。
gitコマンドでtagの作成：
git tag v1.1.0
git push origin v1.1.0coflict
conflict が起こるのはmerge先のbranchでも作業が終わったbranchでも同じファイルに対して変更を行っている場合
<<<<<<< HEAD
from development
=======
feature
>>>>>>> featureどちらの変更を取り込むか決める。
conflict を解消しmerge が完了したとしてもmergeされなかった方のブランチは古い状態のままなので、mergeされなかったブランチからはconflictの原因が消えていない。そのためmerge後にそのブランチで作業を続けたいならconflictで取り込まれた方のブランチの内容をmergeして同期する。
Github Pages
Privateリポジトリだと使えない
リポジトリをPublicで作ったら Setting/Pages/Branch でmainを選択
VSコードからpush
Setting/Pages にいくとURLが出来ている
Github Actions
ユースケース：
CI/CD：
mergeやpushをトリガーにしてエラーチェックやデプロイを行う。
VercelやCloudflareにデプロイしている場合、リポジトリにpushをするとVercelやCloudflareが用意している環境でビルドが成功したかチェックを行なった結果が表示される（CI）。mainへmergeのチェックを入れるとアプリが本番環境にデプロイされる（CD）。
cron：
APIや外部の関数を定期実行
Github Secretsを作成しAuthorizationヘッダーに使うとセキュリティを担保できる。
Github Actionsの使い方：
.github/workflows/フォルダが必要。ローカルで作っても構わないGithub Actionsで走らせたい内容は
.yamlor.ymlに YAML文法に従って書く*YAMLファイルはインデントを正確にしないとエラーになる。
以下は型やビルドエラーをチェックするCIの最小例。エラーがあるとプルリクエスト段階でわかる。
name: CI
on:
pull_request:
jobs:
ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: "npm"
- run: npm ci
- run: npm run lint
- run: npx tsc --noEmit
- run: npm run build.gitignore
node_modules/
.envスラッシュを書かなければどの階層にも再帰的にマッチする。スラッシュがある場合は.gitignoreがあるフォルダのルートにマッチする。
フォルダ末尾のスラッシュ（
node_modules/）は「フォルダである」と明示的にするための慣習
.gitignoreに書き忘れた場合の追跡解除：
# 特定のファイルの追跡を解除する場合
git rm --cached .env
# フォルダごと追跡を解除する場合
git rm -r --cached prisma/generated.gitignoreの配置場所：
.gitフォルダがあるルートの.gitigonoreしか機能しないわけではない。
monorepoでは各app、package内に.gitignoreを置いた方が管理しやすい。