シンプルにこのチートから選ぶといい
https://www.tam-tam.co.jp/tipsnote/program/post16686.html

基本は、Railsチュートリアルのこの箇所
https://railstutorial.jp/chapters/beginning?version=6.0#code-default_root_route

Railsチュートリアル

コミットメッセージは現在形かつ命令形で書くようにしましょう29 。
Gitのモデルは、（単一のパッチではなく）一連のパッチとしてコミットされます。
そのため、コミットメッセージを書くときには、そのコミットが「何をしたのか」と過去形の履歴スタイルで書くよりも「何をする」ためのものなのかを現在形かつ命令形で書く方が、後から見返したときにわかりやすくなります。
さらに、現在形かつ命令形で書いておけば、Gitコマンド自身によって生成されるコミットメッセージとも時制が整合します。詳しくは『開発基礎編 Git』の 「Gitにコミットするとは」をご覧ください。

事象 : ２つめのコミットをリセットしようとしたら失敗した

# 1. プシュっていないコミットが２つあって、２つともコミットを取り消したい
$ git log origin/master..master
Merge: 45... 89...
Author: macOS <ponsuke@example.com>
Date:   Fri Jan 22 21:26:17 2021 +0900

    Merge branch 'master' of https://github.com/{ユーザ}/{リポジトリ} into master

commit 45...
Author: macOS <ponsuke@example.com>
Date:   Fri Jan 22 20:35:04 2021 +0900

    こみっとこめんと

# 2. １つ取り消して・・・
$ git reset --soft HEAD^

# 3. もう１つも取り消そうとしたら
$ git log origin/master..master
commit 45... (HEAD -> master)
Author: macOS <ponsuke@example.com>
Date:   Fri Jan 22 20:35:04 2021 +0900

    こみっとこめんと

# 4. 怒られた
$ git reset --soft HEAD^
fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

原因 : HEAD^のってどれのことやねん！という状態

「えっ？一個前のコミット・・・」

# HEADを確認したら・・・
$ git reflog
45ea498 (HEAD -> master) HEAD@{0}: reset: moving to HEAD^
d5f1e7f HEAD@{1}: pull --allow-unrelated-histories: Merge made by the 'recursive' strategy.
45ea498 (HEAD -> master) HEAD@{2}: commit (initial): こみっとこめんと

対応 : HEADを使わないでどこまでリセットしたいかちゃんと伝える

# 1. originまで戻してね
$ git reset --soft origin/master

# 2. プシュしてないコミットは無くなりました。
$ git log origin/master..master
$

複数のコミットはいっきに取り消しましょう、面倒です。

コミットを指定するときに、~(チルダ)と^(キャレット)を使ってあるコミットからの相対位置で指定することもできます。この時に、よく使われるのがHEADです。~(チルダ)を後ろに付け加えることで何世代前の親かを指定することができます。^(キャレット)は、ブランチのマージで親が複数ある場合に、何番目の親かを指定することができます。
ブランチの切り替え｜サル先生のGit入門【プロジェクト管理ツールBacklog】

事象 : マージコミットの発生するプルで怒られた

1. プルを忘れて
2. ローカルを変更してコミットして
3. プッシュして怒られたから
4. プルったらエラー

# プルったらエラー
$ git pull
fatal: refusing to merge unrelated histories

# プルの挙動はマージする
$ git config pull.rebase
false

原因 : オプションなしに無関係なブランチはマージできないから

「--allow-unrelated-histories」について

ちゃんと調べてみたところ
Git 2.9から mergeコマンドとpullコマンドでは，--allow-unrelated-historiesを指定しない限り，無関係なヒストリを持つ２つのブランチをマージすることはできなくなった。
とありました。
初めてGitHubリポジトリにpushしたらrejectedエラーになったときの対応メモ - Qiita

対応 : --allow-unrelated-historiesオプションをつけてプルる

# めでたくマージコミットつきプル
$ git pull --allow-unrelated-histories
Merge made by the 'recursive' strategy.
 eclipse/MyPreferences.epf | 605 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 605 insertions(+)
 create mode 100644 eclipse/MyPreferences.epf

事象 : プルったらなんか警告された

• 環境
  • macOS Big Sur バージョン11.1
  • git version 2.28.0

$ git pull
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

原因 : リモートに変更があってプルったときにどうするか決めていないから

git pullを実行したとき、Git はまず git fetch を実行し、そのあとに current branch に対して 事前に git fetch で取得したヘッドをマージするように git merge を実行します。

このとき、Git の設定ファイルの中で pull.rebase が true もしくは false と明示的に設定されているか、 実行時に --rebase などのオプションが指定されていれば、リモートブランチとの差があったときにはそれらに従って差分が解決されます。
Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - esm アジャイル事業部 開発者ブログ

対応 : 提示された選択肢から好きなのを選ぶ

選択肢	意味
git config pull.rebase false	fast-forwardする。できなかったらマージしてコミットを作る(プッシュは自分でする)。
git config pull.rebase true	rebaseする
git config pull.ff only	fast-forwardする。できなかったらエラーにする。

fast-forwardって何？って時はBacklogさるがわかりやすいです。

このbugfixブランチをmasterブランチにマージする時、masterブランチの状態が以前から変更されていなければ、非常に簡単にマージを行うことができます。 bugfixブランチの履歴はmasterブランチの履歴をすべて含んでいるため、masterブランチは単純に移動するだけでbugfixブランチの内容を取り込むことができます。なお、このようなマージをfast-forward(早送り)マージと呼びます 。
ブランチの統合｜サル先生のGit入門【プロジェクト管理ツールBacklog】

# リポジトリごとにやるのは面倒くさいのでGlobalで好みを設定した
$ git config --global pull.rebase false

初心者なのでgitでやらかすことが多いです。
やらかした時の対応をよくやるレベル・ケース別にまとめました。

よくやるレベル1：けっこう頻繁にやるやつ

頻繁にやらかすので割と慣れてきた感のある対応です。

ケース１：間違えてgit addしてしまった

git reset HEAD .

複数ファイルあるうち特定ファイルのステージング（add）のみ取り消したい場合は、カレントのところをパスにする
ちなみにHEADは最新のコミットハッシュのエイリアス
git push origin HEAD とかするけど最新のHEADをプッシュすることだったんですね

ケース2：間違えてgit commitしてしまった

大体addと共に歴史から抹消したいので下記を使う

git reset　HEAD .

あれ、ケース１と同じじゃん、と思いますが、同じです
コミットしたもののうち特定のファイルのaddだけ取り消す、等の場合はオプション指定で場合分けをするみたいです（やったことない）

ケース3：git commitする内容を間違えた

git commit --amend

現在のワーキングツリーの内容を上書きします

ケース4:間違えてgit pushしてしまった

まずはローカルのインデックスの状態をHEADに戻し、その状態をプッシュする
プッシュする際はエラー回避のためオプションをつける

git reset --hard HEAD
git push -f origin HEAD

よくやる、と言いつつ、ケース4についてはまだ1度も対処を実践できていない、、

よくやるレベル２：たまにやらかして少しひるむやつ

これを乗り越えて少しずつgitに慣れてきました。
（乗り越えられなくて数時間分の作業が消えたこともあった）

ケース1:ブランチを間違えてプッシュしてしまった

正しいブランチに作業した内容を反映したい、ローカルブランチでのコミットまでは正しいブランチで作業している想定
間違えてプッシュした先の修正は不要なパターン

//push先を指定
git branch --set-upstream-to=origin/feature/fix_deprecation
git push

ケース2:プッシュしたらファイルのサイズが大きくエラーになってしまった、さらにそれに気付かないままローカルで作業を行っていた

もう一度コミットからやり直す必要があるけど、ローカルで行っていた作業が含まれない状態でのコミットが必要、プッシュまで終わったらローカルで行っていた作業を元に戻してそれもプッシュしたい、と言う状況です

作業の流れとしては下記で最初考えていたけど

1.今のワーキングツリーを退避：git stash
2.リポジトリの巻き戻し：git reset --soft HEAD^
3.git reset HEAD サイズが大きいファイルのパス
4.該当ファイルを.gitignoreに記載 <-記載するとファイルがコミット対象ではなくなるが実は不要な手順
5.再びコミット
6.再びプッシュ
7.退避したスタッシュを適用：git stash apply
8.再びコミット
9.再びプッシュ

4.は不要、理由は3.でそもそもステージングから外しているから
もし4.を実施した場合、6.までは上手くいくけど、7.でスタッシュを元に戻すときに.gitignoreの状態が違うことで競合してしまいエラーになります。
また、８.を行う前にaddが必要か悩んだけど、git stash applyを行うとadd済みの状態になるため不要なのがポイント

よくやるレベル３：滅多に起こらない災害レベル（人災）

ケース1:gitの挙動が何もかもおかしい

何しても、何もしなくても、git関連の挙動が全て通常では考えられない状態になったことがありました
謂わゆる「リポジトリが壊れた」状態だと思うのですが、壊れるのには理由がある、、
ということで起こった事象の整理から原因の調査、その結果行った対応までまとめたのが下記になります

https://qiita.com/mby/items/80a79b3a65e28d1c782c
本当にこの時はgit扱うの無理だと思った（原因gitじゃなかった）

イントロダクション

メモしておきたいことを適当に羅列しております、、、
大変自己中かつ素人の記事ですので、暖かくみていただきたい！
何か間違いがありましたらぜひコメントください！

git init

ローカルリポジトリ作成

リモートブランチ取得!!

vscodeの左下をクリック！今回はターミナル上ではなく、vscodeの機能からの変更を載せる！

のようにリモートのブランチ集が出てくるので、希望するブランチを選択し、ローカルへと上書き！！

そこからいつも通り、git checkout -b 'ブランチ名'で完成！！
あとターミナル（CLI）でgit branch -rでリモートのブランチ集が出てくるよ！

コマンドですると

git checkout -b ローカルブランチ名/リモートブランチ名でいけるよ

ついでに-bは新しいブランチを作り、チェックアウトしてくれる！

リモートリポジトリ設定

git remote add origin リモートリポジトリ名
git remote set-url origin リモートリポジトリ名

addは新しくリモートリポジトリを設定
set-urlの方は既存のリモートリポジトリからの変更

リモートリポジトリ確認方法 git remote -v

ファイル編集リセット

git checkout -- ファイル名orディレクトリ名・・・特定のファイル、ディレクトリの変更をリセット
git checkout --・・・全てのファイルの変更をリセット

コミットやり直し

git commit amend・・・直前のコミットのやり直し

.gitignoreファイル

直接パス指定すると指定したファイル、ディレクトリがgit管理下になくなる

gitmojiが最高に良かった件

いつもgithubにcommitする際こちら( https://qiita.com/itosho/items/9565c6ad2ffc24c09364 )を参考にしておりましたが、最近gitmojiというものがあるとの情報を入手しました。

公式サイト→https://gitmoji.dev/
gitmojiのGitHub→https://github.com/carloscuesta/gitmoji-cli

さて、正直上記のサイトを見て頂ければ終わりなのですが実際に使っていきましょう。

gitmojiインストール

yarn add gitmoji-cli

使い方

git commitの代わりにgitmoji -cコマンドを打つのみ。

かなり簡単ですね。
実際にgitmoji -cコマンドを打つと、

  ?  - Improve structure / format of the code.
  ⚡️   - Improve performance. 
  ?  - Remove code or files. 
  ?  - Fix a bug. 
  ?  - Critical hotfix. 
  ✨  - Introduce new features. 
  ?  - Add or update documentation. 
  ?  - Deploy stuff. 
  ?  - Add or update the UI and style files. 
  ?  - Begin a project. 
  ✅  - Add or update tests. 
  ?  - Fix security issues. 
  ?  - Release / Version tags. 
  ?  - Fix compiler / linter warnings. 
  ?  - Work in progress. 
  ?  - Fix CI Build. 
  ⬇️  - Downgrade dependencies. 
  ⬆️  - Upgrade dependencies. 
  ?  - Pin dependencies to specific versions.
  ?  - Add or update CI build system. 
  ?  - Add or update analytics or track code. 
  ♻️  - Refactor code. 
  ＋  - Add a dependency. 
  -  - Remove a dependency. 
  ?  - Add or update configuration files. 
  ?  - Add or update development scripts. 
  ?  - Internationalization and localization. 
  ✏️  - Fix typos. 
  ?  - Write bad code that needs to be improved. 
  ⏪  - Revert changes. 
  ?  - Merge branches. 
  ?  - Add or update compiled files or packages. 
  ?  - Update code due to external API changes. 
  ?  - Move or rename resources (e.g.: files,paths, routes). 
  ?  - Add or update license. 
  ?  - Introduce breaking changes. 
  ?  - Add or update assets. 
  ♿️  - Improve accessibility. 
  ?  - Add or update comments in source code. 
  ?  - Write code drunkenly. 
  ?  - Add or update text and literals. 
  ?  - Perform database related changes. 
  ?  - Add or update logs. 
  ?  - Remove logs. 
  ?  - Add or update contributor(s). 
  ?  - Improve user experience / usability. 
  ?  - Make architectural changes. 
  ?  - Work on responsive design. 
  ?  - Mock things. 
  ?  - Add or update an easter egg. 
  ?  - Add or update a .gitignore file. 
  ?  - Add or update snapshots. 
  ⚗   - Perform experiments. 
  ?  - Improve SEO. 
  ?️  - Add or update types. 
  ?  - Add or update seed files. 
  ?  - Add, update, or remove feature flags. 
  ?  - Catch errors. 
  ?  - Add or update animations and transitions. 
  ?  - Deprecate code that needs to be cleanedup. 
  ?  - Work on code related to authorization,roles and permissions. 
  ?  - Simple fix for a non-critical issue. 
  ?  - Data exploration/inspection.

これだけ出てきます　笑(実際はスクロールなので非常に見づらいです。)

ただ、文字が入るだけでだいぶリポジトリが見やすくなりそうですね！

また、gitmoji add -sとコマンドを打てば「add」に関するものを検索してくれます。
('-s'はsearchのsです。また、ここで注意なのは「add」という単語でなく一つ一つ'a','d','d'として文字として検索する為、この３文字が含まれているものも検索されてしまいます。)

コマンド検索がいちいち面倒

gitmoji

とコマンドを打つと、

Usage
    $ gitmoji
  Options
    --commit, -c    Interactively commit using the prompts
    --config, -g    Setup gitmoji-cli preferences.
    --init, -i      Initialize gitmoji as a commit hook
    --list, -l      List all the available gitmojis
    --remove, -r    Remove a previously initialized commit hook
    --search, -s    Search gitmojis
    --update, -u    Sync emoji list with the repo
    --version, -v   Print gitmoji-cli installed version
  Examples
    $ gitmoji -l
    $ gitmoji bug linter -s

とこんな感じですぐにコマンド一覧を確認することができます。

ざっとgitmojiについての紹介でした！
最後までご覧頂き有難うございます！

Mac-Windows間で開発環境をころころ変える。

Nuxtのdev時、Prettier に CRLFを使うなと怒られたけどeslint --fixする前にgitの設定を見直す

git config --global core.autocrlf input

改行lfのまま読み込んで、commit時に改行lfにしてくれる。

VS Codeの人は改行lfに設定してしまおう

Gitについての、流れをまとめてみました。

リポジトリとは

Gitでファイルを管理する場所
- ローカルリポジトリ
- リモートリポジトリ（publicリポジトリとprivateリポジトリ）

Gitコマンドと流れ

①リモートリポジトリ→ローカルリポジトリへダウンロード

• git clone （新規）
• git pull origin （上書き）

②gitの管理

• git status（状態の確認）
  
  ・赤文字：gitで管理していないファイル
  ・緑文字：gitの管理化にあるファイル（ステージング）

• git add ファイル名
  gitでファイルを管理させる際に使用（ステージングする際に使用）
  ※git add .　と最後にファイル名ではなくドットをつける事により全てのファイルをステージング

• git commit -m "コミットメッセージ"
  gitに保存する

• git log
  コミット履歴の確認

③ローカルリポジトリ→リモートリポジトリへアップロード

• git push origin
• git push origin develop（developブランチへアップロード） ※originはリモートサーバーのこと

ブランチ

ブランチを切る

• git checkout -b develop master（マスターからdevelopブランチを切るという意味）

ブランチの切替

• git checkout master（マスターブランチへ切替）
• git checkout ブランチ名（作業するブランチへ切替）

ブランチの確認

• git branch
• git branch -a（-aがつくとリモートも含めた全てのブランチを表示）

マージ

• git merge develop（developブランチをマスターへマージ） ※マージしたいブランチ（マスター）で行う

プルリクエスト（GitHubを使ったマージ前の確認）

作成したブランチをマスターにマージしてもらいたいという依頼のこと
1. AさんがGitHubでプルリクエストを作成（Create Pull Request）
2. Bさんが内容を確認しレビューを行う（Files changed箇所で変更画面の確認・コメントを記述ができる）
3. 最終的に問題なければ、マージボタンを押す事によりマージができる

同じブランチで作業する場合（共同開発）

AさんとBさんのローカルリポジトリで別々のコミット履歴が出来上がる。
Aさんが先にプッシュ
次にBさんがプッシュするとエラーが発生する

プッシュの前にリモートの状態をローカルにマージしておく必要がある（下の①もしくは②の内容）
① git fetch origin/develop
※このコマンドが実行されるとVIエディタが開かれるので、「:wq」と入力しEnterキーを押すことで、マージが行われる

② git pull develop
※「pull」は「fetch＋merge」を一つのコマンドにまとめたもの

コンフリクト

編集している箇所が同じで競合状態にある事
1. Aさんが編集しプッシュ
2. Bさんが同じ箇所を編集していてPullするとコンフリクトが発生
3. コンフリクトを解消してからコミットしてプッシュする

git rebase（mergeとの違い）

• merge
  コミット履歴が時系列のまま
• rebase
  Aさんのコミット履歴の後にBさんのコミット履歴を持ってくる（一直線のコミットツリーになる） git fetch origin git rebase origin/develop develop git push origin -f ※rebaseの場合、-fが必要で強制的にプッシュする事になる

git reset と git stash

• git reset --hard HEAD
  今編集中の内容を全てリセットして、最終コミットのところまで戻す

• git stash
  コミットしていない内容をいったん全て削除

• git stash pop
  内容を元に戻す
  ※違うブランチで作業していて、ブランチを切り替える必要がある際に使える

はじめに

これは学習用のメモになります。

プルリクエストとは？

自分が変更したコードをリポジトリに取り込んでもらえるよう依頼する機能。(チーム開発で使用)

プルリクエストの手順(開発フロー：GitHub Flow)

ローカル
①masterブランチを最新に更新
②ブランチを作成
③ファイルを変更
④変更をコミット
⑤GitHubへプッシュ
GitHub（リモートリポジトリ)
⑥プルリクエストを送る
⑦コードレビュー
⑧プルリクエストをマージ
⑥ブランチを削除

GitHub Flowを実践する際のポイント（チーム開発）

• masterブランチは常にデプロイできる状態に保つ
• 新開発はmasterブランチから新しいブランチを作成してスタートする
• 作成した新しいブランチ上で作業しコミットする
• 定期的にPushする
• masterにマージするためにプルリクエストを使う
• 必ずレビューを受ける
• masterブランチにマージしたらすぐにデプロイする←テストとデプロイ作業は自動化

目的

• $ git logコマンドで各コミットで修正したソースを表示する方法をメモ的にまとめる

方法

• 下記コマンドを実行する。

  $ git log -p
  

• 下記方法と組み合わせると特定のコミットで修正したソースを表示する事ができる。

  • Git $ git log の表示の先頭コミットを指定する

• 下記のように記載する。

  $ git log -p コミットID
  

この記事を読んで理解できること

・GitとGitHubの違い
・Gitのファイル保存領域と役割
・Gitコマンドとその意味
・リモートリポジトリを作成し、GitHubにpushするまでの流れ
・【おまけ】Gitのショートカット(エイリアス)の設定方法

Gitの全てを網羅している訳ではありませんが、Git白帯の方には多くの学びがある内容で構成しています。
あまり深く踏み込まず、とりあえず抑えて起きたい要点をまとめましたので、ぜひ最後までお読み下さい。

初心者からすれば「なんじゃこれ！？」の連続

はじめてGitに触れたのは半年程前。
リモートやらワーキングツリーやらコミットやらプッシュやら全てのGit用語に対して「なんじゃこれ！」と総ツッコミを入れていた当時を思い出しながら、当時の自分の「なんじゃこれ！？」を少しでも減らすことができるような自分想いな記事をここに書き記します。（因みにGitのインストール等は既に出来ていると想定して話は進んでいきます。QiitaにGit関連の良質な記事が沢山ありますので、そちらを参照してください！）

それでは「GitとGitHubの違い」の解説から始めます。

GitとGitHubの違い

Gitとは？

既にご存知かも知れませんが、Gitはプログラムのソースコードなどの変更履歴を記録・追跡するためのバージョン管理システムのことです。バージョン管理システムには分散型と中央集中型がありますが、Gitは分散型です。（中央集中型についてはここでは触れません。）

難しい話は抜きにして、書いたコード（ファイル）を変更・管理するためのシステムを「バージョン管理システム」と理解してください。分散型の大切な概念として「ブランチ」というものがあります。後ほど出てきますので、先程と同様に現時点では言葉だけ覚えておいてください。

GitHubとは？

Gitを使っている人たち（開発者）が、さらにGitを便利に使うためのWebサービスのこと。GitのHub（中心）となってGitが集まってくるのでGitHub！この辺は分かりやすいですね。GitHub上でソースコードを管理することで、その他大勢の開発者と一緒にコードのレビューを行ったり、プロジェクトの管理をしながらソフトウェアの開発が進められることができるので、世界中で使われています。

Gitは4つの領域で構成されている

ワークツリー
ステージング
ローカルリポジトリ
リモートリポジトリ
※リポジトリ＝ファイルや変更履歴などを置いておく場所。レポジトリとも呼ばれる。

初めはとてつもなくややこしいですが、後々「良くできたシステムやで！」と便利さに感動する日が必ず来るはずです。

以前勉強して上記の言葉を知って理解しているなら、次の説明を飛ばして次の段落にスキップしていただいた方が良いです。
仮に全然わからなくても何も問題ありません。はじめから知っている人なんていませんし、現段階では頭の片隅に置いておけばとりあえずは大丈夫です！！

Gitの流れと4つの領域を簡単に解説

ワークツリー→ステージングエリア→ローカルリポジトリ→リモートリポジトリ

この流れで自分のPC内のファイルを移動しつつ、終点のリモートリポジトリ（自分のPC外。Web上）にデータを共有する。
（リモートリポジトリ以外は自分のPC内なので、最悪ミスってもなんとかなる範囲です。笑）

ワークツリー（自分のPC内）：

自分のPC内にあるGit管理下置かれた作業領域。
「add」コマンドを実行することでステージングエリアに移動する。

ステージングエリア（まだ自分のPC内）：

ローカルリポジトリに「コミット」するファイルを一時的に置いておくための領域。ワークツリーとローカルリポジトリの中間に位置する。
この領域があることで、保存するor修正のためワークツリーへ戻すなど選択することができます。いきなり保存されないので安心できる領域です。
「commit」することでローカルリポジトリに移動する。

ローカルリポジトリ（まだ自分のPC内。あと一歩でGitHubへ）：

ローカル環境でバージョン管理するために配置する。
「push」することでリモートリポジトリに移動（共有）できる。

リモートリポジトリ（自分のPC外。GitHubに到着）：

複数人が各自配置したローカルリポジトリをまとめている領域。
リモートリポジトリはWeb上にあるので、複数人でコードを共有・管理できる。

Gitコマンドとその意味

Gitコマンドをいきなり網羅する必要はないので、初期段階でとりあえずは覚えておきたい！コマンドを抜粋、併せてコマンドの意味を解説します。

add(アッド)：ワークツリー→ステージングへ

# 特定のファイルを指定ファイルを保存
$ git add <ファイル名>

# 全てのファイルを保存
$ git add .

commit(コミット)：ステージング→ローカルリポジトリへ

# 変更内容を確認しながらコミットメッセージを追記。
$ git commit -v  

# ファイルの変更内容を追記
$ git commit -m "コミットメッセージ"

push(プッシュ)：ローカルリポジトリ→リモートリポジトリへ

# リモートリポジトリのmasterブランチに、ローカルリポジトリのmasterブランチの変更内容を保存
$ git push origin master

# originとはリモートリポジトリのアクセス先に対してGitがデフォルトでつける名前のこと。

originとは？
リモートのアクセス先の名称です。
GitHubを利用する前には、リモートリポジトリにプロジェクトを作成します。その時にアクセス先としてgit remote origin <githubのURL>とoriginを指定するのが慣例となっているので、慣れるまでは深く考えずpushの時はoriginを指定すると覚えてください。

branch(ブランチ)とは？
履歴の流れを分岐(ブランチ)して記録するための仕組み。
分岐させることで、分身を作ることができるので、他のブランチに影響を与えず、分身の数だけ複数の変更を進められる。
例えて言うと、ブランチとはパーツのようなもので、各自がパーツを成長させて最後に本体（mainブランチ）に合体させるとパワーアップしてるみたいな感じです。

status(ステータス)

# ファイルのステータスを確認（内容を通常表示）
$ git status

# ファイルのステータスを確認（内容を短縮して表示）
$ git status　-s

diff(ディフ)

# ワークツリーとステージングの差分
$ git diff

# ワークツリーとHEADの前回コミットからの差分
$ git diff HEAD

# ステージングとHEADの差分(stagedとcachedはどちらも同じ結果になる)
$ git diff --staged
$ git diff --cached

# 修正したファイル一覧を表示
$ git diff --name-only

HEADは今いるブランチの最新コミットを示しています。
仮に今、ブランチAとブランチBがあるとしてブランチAにいるならHEADは「ブランチA」を指す。
ブランチAからブランチBに移動した場合、HEADは「ブランチB」を指す。

log(ログ)

# commitした変更内容を確認
$ git log

# 変更履歴を1行でコンパクトに表示
$ git log --oneline

# ファイルの変更差分を表示。Qで終了。
$ git log -p <ファイル名>

# 直近のコミット数を制限して表示
$ git log -n <コミット数>

branch(ブランチ)

# 表示系
# ローカルブランチ一覧を表示
$ git branch

# リモートブランチ一覧を表示
$ git branch -r

# リモート/ローカル全てのブランチ一覧を表示
$ git branch -a

# 操作系
# 新しくbranchを作成
$ git branch <ブランチ名>

# branch<ブランチ名>を削除。完全にマージされていない場合はエラーになる。
$ git branch -d <branch>

# branch<ブランチ名>を削除。完全にマージされていない場合でも、強制的に削除する。
$ git branch -D <branch>

# 現在のブランチ名を<branch_B>に変更
$ git branch -m <branch_B>

checkout(チェックアウト)

# 今いるブランチから<branch>に切り替える
$ git checkout <branch>

# <branch>を新しく作成して<branch>切り替える
$ git checkout -b <branch>

# 書き換えたものを、最新のコミット状態に戻す
$ git checkout --<ファイル名>  

# 書き換えたものを、最新のコミット状態に戻す
$ git checkout --<ディレクトリ名>  

# 全変更を取り消す  
$ git checkout --.

clone(クローン)

# リポジトリをコピーする
$ git clone <クローンしたいリポジトリ>

#　タグやブランチを指定してコピーする
$ git clone -b <クローンしたいブランチ名> <クローンしたいリポジトリ> 

remote(リモート)

# リモートリポジトリを作成
$ git remote add origin <リモートリポジトリURL>

# リモートリポジトリを削除
$ git remote rm origin

まだまだ理解しないといけないコマンドはありますが、一先ずは上記のコマンドの理解を深めて慣れないGit環境や操作になれるようにしましょう。掘り下げればキリがないので見たことないコマンドやわからないコマンドに遭遇した時は、その都度「ググり」ってじっくり吸収することをおすすめします。

信頼できるGit公式サイトのリンクを貼っておきます。
「Git Pro」という解説本を無料で読めますので、困ったらまず「Git Pro」を見ると良いですよ！（日本語対応）

リモートリポジトリ作成〜pushするまでの流れ

# 1. ローカル上（自分のPC内）の任意の場所に作業フォルダを作成  
$ mkdir <ディレクトリ名>

# 2. 作業フォルダに移動
$ cd <ディレクトリ名>

# 3. .gitフォルダ（隠れフォルダ）を作成
$ git ini #ini = initialの略称   

# 4. リモートリポジトリを作成
$ git remote add origin <リモートリポジトリURL>

# 5. ファイルをワークツリーからステージに移動 
$ git add . 　又は　　$ git add <ファイル名>

# 6. コミット前にファイルのステータスを確認する。(必須ではない。コミット前にステータスを一応確認したい)
$ git status

# 7. ファイルをステージングエリアからローカルリポジトリに移動
$ git commit -v  又は　　$ git commit -m "コミット内容をコメントとして書く" 

# 8. masterという名前のブランチを作成
$ git push origin master 

# 9. origin masterを楽にpushする(次回以降git push origin masterと入力しなくても、git pushだけで済む。)
$ git push -u origin master

　　
以上がローカル環境で作成したフォルダをリモートリポジトリにpushするまでの一連の流れです。

【おまけ】Gitのショートカット(エイリアス)の設定方法

$ git config --global alias.st　status

本来ならstatusと入力していたものが、stだけで済むことになります。例えば git stだけでgit statusと同じ内容を実行できるようになるので良く使うコマンドをエイリアスすると効果的です！そして、僕自身も下記のようにエイリアス登録していますが短縮できるのでめっちゃ便利です。

例：commit →　ci
　　checkout →　co
　　branch →　br
　　status　 →　st

最後に一言

これでGit基礎以上です。
少しでもあなたの「なんじゃこりゃ！」を減らすことができたなら嬉しいです。
最後までお読み頂き有難うございました！

参考にさせて頂きました！

・Git
・サル先生のGit入門
・Git超絶まとめ @masashi127さん

有益な情報を有難うございました！

誤ってgit rm -r --cached . を実行した場合は、git reset HEAD .を実行する。

https://www.it-swarm-ja.tech/ja/git/git-rm-r-cached%E3%82%92%E5%85%83%E3%81%AB%E6%88%BB%E3%81%97%E3%81%BE%E3%81%99/1047980271/

今回は、「Git」「Github」の使い方についてまとめます。
おそらく僕と同じく困っている方もいると思うので参考なればと。

※使用するためにセッティングが必要だと思いますが、今回、そちらは書いておりません。
あくまで事前設定を終えた後からの話になります。

GitとGitHubについて

gitとは

ソースコードのバージョン管理を行うツールになります。
「いつ・誰が・どこを」等を記録し、管理する事ができるツールになります。
主に、共同開発時にこれがあるだけで管理がいやすくなるそうです。（まだ経験がないですw）

管理の方法としては、下記の2種類かと。
・ローカルリポジトリ　　自分のパソコン上に記録・保管
・リモートリポジトリ　　専用のサーバーで管理し、複数人で共有

GitHubとは

Gitを利用した、開発者を支援するWebサービスです。

なので、GitとGitHubは、一緒に使うことが想定されますので、
使い方は覚えておくべきかと思います、（自分自身にも言い聞かせてます。）

次は、使い方を簡潔にまとめたいと思います。

gitの超シンプルな使い方

文字でまとめると、個人的にはこのような流れでした。

「手順一覧」
1.ターミナルを開く
2.ディレクトリとファイルを作成
3.ローカル作成
4.GitHubでリポジトリ作成
5.作成/変更履歴をローカルに記録
6.ローカルとリモートの紐付け
7.GitHub（リモート）にアップロード

※作業時は、4〜5を繰り返す。

次は、もう少し詳しく、分解して表にまとめると、、、、、

No.	操作場所	手順	方法
1	PC	ターミナルを開く	PCで検索して開く
2	ターミナル	ディレクトリ作成	% mkdir ______
3	ターミナル	ファイル作成	% touch _____
4	ターミナル	ローカル作成	% git init
5	GitHub	GitHubでリポジトリ作成	リモートリポジトリ作成＋URLゲット
6	ターミナル	①作成/変更履歴をローカルに記録	% git add ____(ファイル名)
7	ターミナル	②作成/変更履歴をローカルに記録	% git commit -m "____"
8	ターミナル＆GitHub	紐付け（コネクト）	% git remote add origin (※リモートリポジトリURL) ※5でゲットしたURL
9	ターミナル	ブランチ変更	% git branch -M main
10	ターミナル	リモートへアップロード	% git push origin main

以上を行うと、GitHubにファイルがアップロードされているかと思います。

その後、作業を行うかと思うので、
その際は、6,7,10を実行すると反映できるかと思います。

No.	操作場所	手順	方法
6	ターミナル	①作成/変更履歴をローカルに記録	% git add ____(ファイル名)
7	ターミナル	②作成/変更履歴をローカルに記録	% git commit -m "____"
10	ターミナル	リモートへアップロード	% git push origin main

以上、たにーでした。

参考文献

1. いまさら聞けないGitとGitHubの違いって何？

GnuPGをインストール

$ brew install gnupg

以下のURLの手順に従う

https://docs.github.com/ja/free-pro-team@latest/github/authenticating-to-github/generating-a-new-gpg-key

・GPGキーペアを作成 (emailはGitHubアカウントのemail)
・GitHubアカウントへのGPGキーの登録
・Gitに署名キーを伝える
・macOSの場合pinentry-macが必要になる

$ brew install pinentry-mac
You can now set this as your pinentry program like

~/.gnupg/gpg-agent.conf
    pinentry-program /usr/local/bin/pinentry-mac

$ echo "pinentry-program /usr/local/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
$ killall gpg-agent

・タグに署名する

$ git tag -s <tag-name>
$ git tag -s v1.13.6

・タグをpush

$ git push origin <tag-name>