gitの基本的な流れ

ローカル（VSコード）のmainブランチから別のブランチを作成し移動・作業を行い、git push origin branch-nameでリモート（Github）の branch-name ブランチにpushし、リモートのmainブランチへmerge判断をGithubで行う

origin = リモート（GithubのURL）のこと
ローカルのbranch-nameと異なるリモートブランチ名にしたいならgit push origin branch-name:test のようにする

以上、個人開発ではあまりブランチを作らないが本格的な開発の場合は「機能単位で頻繁にブランチを作成 & マージ後にそのブランチを削除」という流れを繰り返す

ローカルでgitを始める：PCを変えた時など

PCにgitをインストール：sudo apt install git
GithubのusernameとemailをPCに紐付ける

git config --global user.name "your-username"
git config --global user.email "your-email@example.com"

リモートリポジトリをpull

git init
git remote add origin リモートのURL
npm i

ローカル / ステージングエリア / リモート

add：

git add . でファイルが「ワーキングディレクトリ（作業領域）」から「ステージングエリア」へコミット対象として変更を一時登録
- 一時登録の履歴（ = ステージングエリアに登録された変更）はgit status で確認できる

commit ：

git commit -m "" は「ステージングエリア（変更）」の内容を「ローカルリポジトリ」に記録（コミット）する
- commitの履歴を確認するにはgit log

push ：

git push で「リモート」（Github）へ反映
- git push -u origin developのようにすると git push origin develop と毎回の打つ必要が無く、git push だけで済む
- -u は --set-upstream の略

git pull = git fetch + merge：

リモート（Github）のコードの方が進んでいる場合、ローカルにその変更を取り込みたい
git fetchはリモートの最新の情報（だけ）を取得するコマンドで、ローカルの内容はが変わることは無い。git mergeと続けることでリモートの内容がローカルに反映される
git pull は上記を一行で済ませる

git log

git log：

commitId
Author: 
Date:

閉じるにはQキー
上に行くほど新しいコミット
Enterキーをトグルすることで過去のコミットに遡る
- コミット数が多い場合、最終的に(END)に行き着く
詳細情報が必要無い場合、 --onlineを追加

過去のコミットに戻る

git checkout

git checkout <commitId>：

git logのcommitIdをペースト
git branch をすると HEAD (detached at xxx) のような表示
この状態（detached at xxx）は、現在ブランチに属していないことを意味するので元のブランチに戻った時にHEADのコミットにはたどり着けない
- HEAD：現在チェックアウトしている場所（現在の作業ポイント）

過去のコミットに戻った理由が「そこから作業を再開したい」だった場合、新しいブランチを作るとHEADが映るので、そこからコミットをする
git checkout main 等をすると最新の状態に戻る

git restore

git restore .

まだステージ（add）していない変更を取り消す

git restore --staged .

ステージング（git add .）した後の場合

*monorepoのadd

git add . をmonorepoの各アプリ内で行ってもダメ。そのフォルダしかステージングされない。

monorepoの各アプリ内でプロジェクト全体をステージングするには、git --all or git -A を使う。

ローカルbranchの作成 / 削除

git branch ブランチ名   //作成
git checkout ブランチ名   //移動

１つのコマンドで行う：

git checkout -b ブランチ名

ローカルbranchの削除：

git branch -d ブランチ名

*注意：どこからブランチを作成するか

どのブランチからブランチを作成するか気をつける必要がある

理由：

ブランチは派生元のブランチが作業の基準になる為（ベースにしたブランチの状態を引き継ぐ）

git stash

git stash ：

commitをせずに（したくない状況）で他のブランチに移動する際に使う
本来、移動先ブランチに同じファイルがあり未コミットの変更が衝突する場合、ブランチ移動はエラーになる。（ 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値

git tag

アプリを刷新するときは「アプリ名-archive」のようなGithubリポジトリを作って保存していた。しかしmonorepoだと１つだけ切り出すような事ができないのでgit tagを使う

git tag test-v1

VSコード内で上記を実行
Githubリポジトリを見ると、Tagという欄にコマンド実行時点でのソースコードが保存されている。
Tagの横に「Release」というのがあるので、作成したTagを選択してメモ書きを残す。

coflict

conflict が起こるのは、merge先のbranchでも作業が終わったbranchでも、同じファイルに対して変更を行っている場合

<<<<<<< HEAD
from development
=======
feature
>>>>>>> feature

どちらの変更を取り込むか決める
conflict を解消しmerge が完了したとしても、merge されなかった方のブランチは古い状態のまま残る。
つまりmergeされなかったブランチからは conflictの原因が消えていないので、merge後にそのブランチで作業を続けたいなら、conflictで取り込まれた方のブランチの内容を merge して同期する必要がある

Github Pages

*注意：Github Pages機能はPrivateリポジトリだと使えない

手順：

リポジトリをPublicで作ったら Setting/Pages/Branch でmainを選択
VSコードからpush
Setting/Pages にいくとURLが出来ている

Github Actions

Github Actionsは何かの処理を “トリガーに応じて” 自動で実行できる仕組みなので、やれることはいくらでもある

ユースケースの例：

CI/CD：Vercel等が行ってくれていること（mergeやpushがトリガーになりエラーチェックやデプロイを行う）
cron：定期実行。この際、アプリのAPIルートや外部の関数を実行できる。Github_Secretsを認証に使うことも出来る

Github Actionsの使い方：

.github/workflows/ フォルダが必要。ローカルで作っても構わない
Github Actionsで走らせたい内容は.yaml or .yml に YAMLの文法に従って書く
- *注意：YAMLファイルはインデントにセンシティブ

Issues

アプリのTodoやメモは READMEやローカルのメモアプリに書くのではなく、各リポジトリのIssuesに書いた方が良い

リモートの `.env`ファイル

問題：

.gitignoreで.env を書き忘れてGithubにpushした場合、その後 .gitignoreに.env を書いても .env はリポジトリ（リモート）に残ったまま

理由：

.gitignore は「今後 Git に追加しない」というルールを決めるだけであって、
すでにコミット済みのファイルには影響しない

対応：

Github側で .env を選択して手動で「Delete Fie / Commit changes」をする

.gitignore：上位に置く場合の勘違いしていた点

.gitignore：monorepoなど

// △

**/node_modules

**/.env

**/ を書くことで「下層フォルダ」の node_modulesや.env をGithubにpushしないようにしていた。
しかし、スラッシュを書かないで .envにすると、下位フォルダにも自動で反映されるので **/は不要。*スラッシュを書くとそのフォルダ（上位フォルダ）のみ

// ◯

node_modules

.env

Github-Desktop

https://github.com/shiftkey/desktop

Ubutnuの場合：

「package feed」を実行した後にinstallコマンドを実行する
package feedは shiftkey だとエラーになり、mwt だと正常に Github-Desktop がインストールできた

README

オープンソースリポジトリのREADME.mdファイルは「画像、絵文字、テーブル」がふんだんに使われている

Badge

READMEの上部に複数のカラフルな「Badge」が置かれていることがある
これは https://shields.io/badges から生成/取得している
リポジトリの情報（バージョンやライセンス）を読み取り、動的な表示をすることもできる

https://shields.io/badges/static-badge でデモ操作ができる

![Static Badge](https://img.shields.io/badge/test-blue)

testという文字が白く書かれた青いバッジ
/test-blue の部分：/content（表示したい文字）-color（バッジの色）
- *-colorの部分がないと404になる

ロゴ付きのバッジ：

https://img.shields.io/badge/Youtube-white?logo=youtube&logoColor=red

Youtubeのロゴと文字が並ぶ白い背景のバッジ
logo用のqueryは https://simpleicons.org/ で確認できる

htmlタグ

GithubのREADME.mdは、.md内でhtmlタグが使える（htmlタグとして解釈される）。XSS防止の為、安全なタグに限られる。

要素/テキストの中央寄せ：

<div align="center"></div>
<p align="center"></p>

展開：

<details>
  <summary>open</summary>
  <p>rrwerw</p>
</details>

画像：

<a href="https://example.com">
  <img src="https://img.shields.io/badge/Docs-blue" />
</a>

テーブル：

<table align="center">
  <tr>
    <th>YY</th>
    <th>XX</th>
  </tr>
  <tr>
    <td>テスト</td>
    <td>🚧</td>
  </tr>
</table>

絵文字：*Ubuntuだと使いづらい

Windowsキー + .(ドット)
e という文字が表示される
Spaceキー
（カテゴリ毎の）emojiピッカーが現れる

Github / git：