ターミナルで対象ディレクトリに移動。
【まず初期化】
git init
補足＜git initで作成されたフォルダを確認したい場合。
Finderで対象ディレクトリで
⌘ + shift + . で隠しファイルが出る ＞
＜必要なら＞
⑵ファイル名の変更 （add 前）
git mv 旧ファイル名 新ファイル名
（更にステージにも追加される＝addした意）
（以下３つを行っても同じ結果）
mv 旧ファイル名 新ファイル名
git rm 旧ファイル
git add 新ファイル
（３）add前：ファイルの変更内容を取り消す
git checkout --ファイル名
git checkout --ディレクトリ名
全変更を取り消す git checkout -- .
（エディタにて戻っているか確認可）
【git add . 】
初回補足：git statusすると以下でる。（ステージに上げられたので次はコミット,かuse "git rm --cached。。。）
git status → On branch master No commits yet Changes to be committed:
(use "git rm --cached ..." to unstage)
＜必要なら＞
add後【削除したい場合】
git rm ファイル名
git rm -r ディレクトリ名
↓
deleteの動作をステージに上げる。＝addする
＜必要なら＞
（４）add後：変更を取り消す
(ステージ上だけ取り消す＝ローカルは影響ない。ローカル上も取り消したいなら、（４）の後（３）を実行する。
git reset HEAD ファイル名
git reset HEAD ディレクトリ名
全変更を取り消す git reset HEAD .
＊（最新のコミット内容にリセットされる意）
＝ （３）かエディタを修正後、add
【git commit】
git status → nothing to commit, working tree cleanが通常
＜必要なら＞
【コミット後、削除したい場合】
git rm ファイル名
git rm -r ディレクトリ名
（ワークツリーからも削除される＝commitの取り消しではなくaddも無かったことに）
ローカルに（ワークツリー）には残したい（gitの管理はしたく無い場合）
git rm --cached ファイル名
＊再add commit
＊git status
nothing to commit, working tree clean ならok
＜必要なら＞
＊コミット直後の場合のみ
【直前！のコミットを修正amendしたい】 add後のステージングの内容を元にやり直す。
＊メッセージの修正、コミットし忘れなど
⑴エディタを修正してから、
⑵git add.
⑶git commit --amend
（メッセージエディタがでる）
確認方法：git log -p -n 1 *Qでターミナル抜ける
(-p 1行表示 -n 1 最新の１コミットを表示）
(4)git push origin （＊ブランチ名）
＊push後は共同開発者（がすでに取得しているかも）に迷惑なので行わない
修正したい場合は、新たにgit commit を通常通り行う。
【コミット削除】
$ git revert HEAD 直前
$ git revert コミットid git logで確認
【複数コミットを修正したい】 commitしたが、削除、分割してcommitしたい等。
⑴git rebase -i(nteractive) コミットid
(git rebase -i HEAD~2 )なら直前2個のコミットをやり直す
⑵commitエディタの やり直したいpick を editに書き直す。
commitをまとめたい場合は editではなく squashを（つまり最低でも２箇所）書き直す。
＜分割してcommitしたい：editにし、git reset HEAD~（何番目かの数字）
＊git resetはcommitを取消してステージング前に戻すコマンド。
なので、行いたい分割のadd、commit行う。
。行いたい分割のadd、commitを必要分繰り返す。⑸のコマンドへ＞
削除したいなら消す。（後、lsで確認）入れ替えたいなら、入れ替える。終了する。
(＊git logとは逆で、最新が一番下。)
＊git log --onelineでcommit履歴を確認。
editにした箇所はエディタで内容を修正できる。
⑶ファイル修正後、
⑷git commit --amend ＊やり直すため（ commitメッセージでる）
⑸git rebase --continue ＊リベース完了
順次pickかeditを判断し自動で進む
⑹git push origin （＊ブランチ名） ＊ブランチあげておく
【リモートリポジトリを（新規）追加】
GitHub(にてリポジトリ作成後） にてpushしたいリポジトリurlをコピー
確認方法：git remote ←名前が表示,
:git remote -v ←urlが出る
詳細：git remote show (origin)
①新規：git remote add origin（もしくは作成したい名） http://（url)
（originという名前でurlリモートリポジトリを初回登録しておくpush前に行うと後々②が楽になる。）
origin = git config --list で確認
⑴追加の場合：git remote add リポジトリ名 http://（url)
＊push前に 機密情報等（.gitignore）最終確認
②git push リモート名 ブランチ名
(git push origin master)
⑵ git push -u リポジトリ名 master
＜現在＊masterの場合＞masterの内容が（リポジトリ名））にpushされる。
GitHub にて確認。
☆pushした場合、（パスワード等 git管理したく無いデータ）は取り消してもコミット？履歴が残る為、レポジトリを削除するしか無い。pushしたら基本終わり。と私はする。
###ここから複数人開発必須###
< チーム開発流れ >
①ワークツリーでmasterブランチを最新の状態確認する。
git branch （ 確認後、checkoutでmasterに移動する。）
git pull origin master →コンフリクトが起きたら対応
git status → リベースが起きた場合警告出る
②ブランチを作成.且つ移動
git checkout -b 新ブランチ名
③ファイルの編集
④git commit （ローカルリポジトリに記録）
⑤git push origin （普通今いる）開発ブランチ名
⑥GitHub にログインし、プルリクエストを送る
（GitHub対象リポジトリに移動。）
⑴pull request タブをクリック
⑵new pull reques クリック [ベースをmaster コンペアを自分の開発ブランチ]
⑶create pull request クリック メッセージ編集し、create pull request
⑷コードレビュー依頼の作成
メッセージ横の Reviewerクリックして依頼者を選択 (mailが行く）
⑦（チームからのLGTM）
自分がReviewerの場合：内容確認。
Fires changes クリック 内容確認。変更箇所の左に＋ボタンでコメント可能。
問題ない場合：Review changesクリック。
・comment (各ルールによる。コメントのみの意思)
・Approve ( 承認の意 )
・Request changes (修正が必要)
でsubmit
**⑧補足（チームからのLGTM後）Conversationタブで **
✔︎ Changes approved （承認された）
✔︎ This branch has no conflicts with the base branch （merge可能の意。このブランチにはベースブランチとの競合はない）
⑨GitHubのmasterブランチにmerge(統合）
GitHub上Conversationタブから
[Merge pull request ] をクリック
[confirm merge ] （確認クリックアクションがでる）をクリック
Pull request successfully merged and closedと出る。
右の delete branch で↓
⑩GitHub上のブランチを削除
＊GitHub上に自動削除設定もある。
ーーーーーーーーーーー
ここからは↑↑↑チーム開発流れ①を繰り返す内容
merge後を自分のローカルに落とす。
git checkout master
git pull origin master
＊＊⑩ターミナル上のブランチを削除＊＊
git branch -d(elete) 削除するブランチ名
開発ブランチを作成・移動。。。
。。。続く。。。
<<以下 詳細>>
【リモートから情報を取得】 慣れていない人推奨fetch
【リモートから情報を取得 ❶pull する】 ＝ （リモートから情報を取得し、mergeまでを）一気に行う
注意点：今いるブランチにmerge されるので、謎にブランチmix mergeになるので注意。コンフリクトの原因にもなる。確認する。
重要：（HEADを） pullしたいブランチ名に移動してから、
[git pull リモート名 pullしたいブランチ名] を実行する。
git pull リモート名 ブランチ名 *省略可能：git pullでよい
（git pull origin master)
【リモートから情報を取得 ❷fetch する】 fetch：（ステージの上）ローカルリポジトリに取得され、ワークツリーには反映しない。（するにはmerge）
①リモートリポジトリGitHubの情報を最新に更新されている状態で
②git fetch リモート名
(git fetch origin)
③git merge origin/master ←fetchは/必要
*これでoriginリポジトリのmasterブランチの情報を自分ワークツリーに統合merge（取り込む）される
メッセージエディタ立ち上げる
ブランチの分岐
【作業ブランチを作成する】 ＊HEADがmasterとする
git branch ブランチ名 ←まだ作成だけでHEADがmasterのまま。移動はしていない
＊ブランチ一覧を表示：git branch ←[自分のいるブランチに＊がついている]
*リモートリポジトリ側も全て表示：git branch -a
確認：git log --oneline --decorate どのブランチがどのコミットを指しているか確認できる
【作業ブランチを切り替える】
git checkout 切り替えたい先ブランチ名
【作業ブランチを作成する】＋【作業ブランチを切り替える】を一度に行う】
git checkout -b（ranch) 作成したいブランチ名
ここから他者の変更を取り込むmerge流れ
push前に変更の統合をする。 ＊merge = mergeCommitの意 = push前
【他者の変更を取り込む①merge】
＊複数のブランチを切って各自pushして行く為 → 各ブランチの変更を統合mergeする必要がある。自分の開発を終えたらmerge.
git merge ブランチ名
か
git merge リモート名/ブランチ名 （fetchの場合）
例： git merge origin/master ←"origin（GitHub）にあるmasterブランチ"を今いる自分のブランチにmerge統合する意味
【他者の変更を取り込む②rebase】
git rebase ブランチ名
＊mergeと異なり、ブランチ名のコミットを親要素として取り入れながら自分のブランチを履歴を簡潔に記録する。
例：HEAD=自分の作業ブランチ＝masterとする。commitする
pppブランチでもcommi☆tした。
（自分はmasterで）masterにpppを取り込みたい。
⑴git checkout ppp
⑵git rebase master
git log --oneline
で確認すると↓
これでmasterにpppを取り込んだ。commi☆tは新たにmasterとしてのコミットにrebase作成し直され１つの親要素に取りこまれた＝履歴を一線にした。（mergeの場合は親要素コミットが２つある）
mergeしても新たなmergeCommitが作られない。⑵でmasterとpppは同じコミットを指している状態となる。＝ファストフォワードが起きた。
⑶git checkout master
masterに戻り、masterでもpppの内容を取り込む↓
⑷git merge ppp
⑸git push origin master
⑹pppブランチは既にmasterに取り込んだ為、(git branch -d ppp )削除する
＊ファストフォワードの注意：どこまでがどのブランチの作業かわからなくなる
＊GitHubにpushしたcommitをrebaseはNG。rebase作成し直されてGitHubコミットと異なってしまう＝commit出来ない。＝ git push -f(強制プッシュは絶対NG）
普通に、修正後、新たにadd,commitコミットをする。
git mergeして、 もしも”CONFLICT...コンフリクトフォルダ名” と出たら...
【もしコンフリクトしたら】
＊同じ変更をしている場合どちらのブランチを優先するかgitは判断しない為、コンフリクに対する作業必要。
①git status にてコンフリクトファイルを探す。
②エディタのコンフリクトファイルに入ると以下の様になっているはず。
＜＜＜HEAD
（被り内容）
＝＝＝
（被り内容）
＞＞＞ コンフリクト中のブランチ名
解決方法：
↑を ❶最終的に実行したい内容に修正し直して、
[<
❷一応git status
both modified:と（コンフリクトの意）がでるはず
❸git add コンフリクトのファイル名
❹git commit ＊既存メッセージの1行下に ”コンフリクトの解消” を残すと良い。
これで解決。
☆基本、複数人で同じファイルを変更しない。
☆pull,merge の前に変更中の状態を無くしておく。＝ commitかstashしておく。
自分が変更中のファイルがpull,mergeのファイルに含まれていると、結果もちろんコンフリクトとなる。
【git push origin 自分の開発ブランチ名 】
###その他###
【一時退避 stash】
☆commitしないが一旦保存しておく。（合わせて他ブランチで作業するときなど）
git stash (save略可) ＊ワークツリーとステージに変更がなかった扱いとなる。
⑴ （ファイルの変更後、一応 git status）
⑵git stash
stash中の一覧確認：git stash list (Qで終了）
⑶stashを復元apply
❶git stash apply ←最新のstash作業をワークツリーに復元（add前）
❷git stash apply --index ←ステージに追加の状態に復元
（listを元にスタッシュ名を調べ）指定してstashを復元
git stash apply stash@{スタッシュ名} （＊0から順に番号つく）
⑷stashを削除drop
（git stash listを元に↓）
❶git stash drop ←最新stashを削除
❷git stash drop stash@{スタッシュ名} ←指定してstashを削除
❸git stash clear ←stashの作業を全削除
⑸一応git status
（もしファイルの変更内容を取り消すなら git checkout --ファイル名）
【ブランチ名を変更】
今いるブランチでブランチ名を変更する。（必要なら git checkout で移動）
git branch -m(ove) 新たなブランチ名
【ブランチ名の削除】 ＊一応masterにgit checkout で移動して、
git branch -d(elete) 削除するブランチ名
*masterブランチにmergeしていない変更があると削除されない仕組みである。
それでも強制削除したい： git branch -D 削除するブランチ名
【リモート名を変更】
まず何があるか確認： git remote
git remote rename 旧リモート名 新リモート名
【リモート名を削除】
git remote rm リモート名
確認： git remote
以下再表示
⑵ファイル名の変更 （add 前）
git mv 旧ファイル名 新ファイル名
（更にステージにも追加される＝addした意）
（以下３つを行っても同じ結果）
mv 旧ファイル名 新ファイル名
git rm 旧ファイル
git add 新ファイル
（３）add前：ファイルの変更内容を取り消す
git checkout --ファイル名
git checkout --ディレクトリ名
全変更を取り消す git checkout -- .
（エディタにて戻っているか確認する）
（４）add後：変更を取り消す
(ステージ上だけ取り消す＝ローカルは影響ない。ローカル上も取り消したいなら、（４）の後（３）を実行する。
git reset HEAD ファイル名
git reset HEAD ディレクトリ名
全変更を取り消す git reset HEAD .
（最新のコミット内容にリセットされる意）
（３）かエディタを修正後、add
＜補足＞
.git （何か） -- フォルダ名
ハイフンが2個なのはブランチ名とフォルダ名等がもし同名だった場合にgitが判断できる為のルール。
.HEAD 自分がいるブランチの事を指す
.git log --oneline 自分のいるブランチのコミット履歴１行で表示。上が最新。
.修正後ファイル内を確認したい場合は、catコマンドで。
.作業の履歴を残したい場合merge（コンフリクト解消しやすい）（pushした後はmerge)。
履歴をきれいに残したい場合rebasek（コンフリクト解消しにくい）（pushした前rebasek)。
コンフリクト懸念な修正はmerge。
・git config (--global) -l 設定確認
（$ git config --g pull.rebase true設定済）
・commitにタグをつける場合：①通常タグ git tag -a タグ名 (＋必要なら -m "メッセージエディタ立ち上がる"）
②簡易版タグ：git tag タグ名
過去のcommitにタグ付けしたい場合：git tag タグ名 過去のcommit名
タグ名の一覧： git tag -l "タグ名"
タグのデータ詳細表示：git show タグ名
＊リリースポイントにタグをつけるとバグの際等わかりやすい。
＊タグはローカルのみ作られて、GitHubnに送られない。送るコマンド作業必要↓
⑴個別GitHubに送付：git push リモート名 タグ名
⑵ローカルにあるがGitHubにないタグを一斉に送付：git push origin --tags
タグをGitHubにて確認：releasesnにクリック。tagsで確認可能。
補足２
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details
$ git pull origin master を