導入〜ご挨拶〜
こんにちは、ハルです
私事ですが先日、Git（Github)を学び直しました。
その際、メモとして書いたものを連携しようと思います。
※あくまで本人視点で記述しているので大衆向けではないです。
因みに、コメント（所感）も添えました。
復習、もしくは興味本位（こんなこともできるんだ）で見てもらえたら恐縮です。
1.Git_コマンド編
1.1. ワークツリーの変更を取り消す
#ワークツリーのファイル変更を取り消す
git checkout -- <ファイル名>
#ローカルリポジトリのディレクトリ変更を取り消す
git checkout -- <ディレクトリ名>
#全てのワークツリーの変更を取り消す
#git checkout -- .
【コメント】
ワークツリーでの作業は上記のコマンで取り消せます。
「コードを修正・変更したけど、上手くいかない。一旦、仕切り直ししたい！」って方にはピッタリですね。
ただし、一旦「add」してしまった場合は上記のやり方では取り消せません！
上記のコマンドは「ステージ領域にあるデータを取得して、ワークツリーの変更を取り消しする(ステージ領域とワークツリーの資産を同等にする）」ためです。なので、ステージ領域にあるデータを呼び戻したい時に使う、と頭の隅に置いておくといいかもしれません。
1.2. ステージの変更を取り消す
#ステージのファイル変更を取り消す
git reset HEAD <ファイル名>
#ステージのディレクトリ変更を取り消す
git reset HEAD <ディレクトリ名>
#全てのステージの変更を取り消す
git reset HEAD .
【コメント】
今度はステージ領域の変更取り消しですね。
こちらも「ワークツリーの取り消し」と同じで幾つか特徴があるので、注意しておきたいです。
- 1. リモートリポジトリ領域にあるデータを取得して、ステージ領域の変更を取り消しにする点
- 2. ステージ領域の変更取り消しだけで、ワークツリーの資産には影響がない点
→つまり、コミットしてしまったら変更取り消しはできません
→同時にワークツリーの変更も戻す必要があるなら、別対応が必要です
1.3. 直前のコミットの変更を取り消す（誤ってコミットしてしまった場合）
#コミットの変更を取り消す（pushする前）
git commit --amend
【コメント】
こちらも注意点がございます。特にチーム開発を行なっている場合です。
リモートリポジトリに「push」したコミットを上記コマンドで取り消してはいけません。
理由は、Github上でのバージョン（履歴の状態）が異なり、一部のメンバが変更を取り込めない(pull・merge・feach等)可能性があるからです。
もし、pushしてしまった場合は、変更を取り消そうとするのではなく、もう一度コミット前からやり直して下さい。
1.4. リモートリポジトリ（Github上）のデータをローカルリポジトリに取得する
git fetch <リモート名>
ex) git fetch origin
【コメント】
リモートリポジトリの最新のデータをローカルリポジトリに持ってくるイメージです。
実際は「リモートブランチ」で持ってくるため、上記コマンド実行後、以下のコマンド駆使するといいのではないかなと思います。
#リモートブランチを含め、全てのブランチを確認する
git branch -a
#内容を確認するべくリモートブランチに切り替える
git checkout <リモートブランチ名>
fetchの良いところは以下の点です。
・とりあえずリモートリポジトリの内容を確認したいだけ、mergeまではしたくない。
1.5. リモート（github）から情報を取得し、マージまでを一括で行う
git pull <リモート名><ブランチ名>
ex) git pull origin master
【コメント】
「pull」コマンドは下記コマンドと同等です。二つのコマンドを兼ね合わせたものが「pull」コマンドになります。
git fetch <リモート名>
git merge <ブランチ名>
ここで議題となるのは、「pull」 VS 「fetch & merge」です。
あくまで主観ですが、
Githubの操作に慣れていない場合は、「fetch & merge」 を
Githubの操作に慣れている場合は、「pull」 を使用すればいいと思います。
理由としては、「pull」をすると、
確認不足によって他のブランチの情報と混同してしまう可能性があるためです。そうするとコンフリクトが起こりやすくなります。
なので、
「fetch」で一度リモートリポジトリのデータを取得し、diffコマンド等を駆使して取り込み分（変更分）を確認していく。
問題ないことを確認してから「merge」コマンドを打つのが一番安全かなと。
1.6. マージ（他の人の変更内容を取り込むこと）したい
git merge <ブランチ名>
git merge <リモート名\ブランチ名)
ex) git merge origin\master
【コメント】
個人的にはマージの種類を知っておくといいのではないかと思うので連携します。簡略化してるので、詳細は別のサイトで調べていただけたら幸いです。※図とかあるサイトがあるのでそちらを見ていただけるとイメージが湧くと思います。
【マージの種類】
- 1.Fast Foward:早送りになるマージ
- 2.Auto Merge: 基本的なマージ
- 3.conflict:コンフリクト
→ブランチのポインタを前に進めるだけ
→枝分かれして開発していた場合
→マージコミットという新しいコミットを作る
→同じファイルの同じ行に対して異なる編集を行なった場合
★コンフリクトは、もう少し付け加えます。
【コンフリクトの際の解決方法】
→ファイルの内容を書き換える（最終的に変更したい記述に書き換える）
※「<<』「==」「>>」の記述を元にして不要箇所を削除すること
※どのファイルがコンフリクトしたのか知りたい場合は「git status」で確認すること
【コンフリクトの回避案（主観と調査含む）】
1.複数人で同じファイルを変更しないこと
2.pullやmergeする前に、ローカルとリモートの差異を予めなくしておく（commitやstashを打っておく）
※stash・・・コミットしていない変更を退避することができるコマンド
3.pullする際は、適したブランチに移動してからpullすること（テキトーに行うと勝手にmargeされ、コンフリクトが起こりやすい）
初心者はここで躓きやすいと思いますが、コンフリクトが出た場合というのは、
同じファイルの同じ行に対して異なる編集を行なった場合、です。
つまり、二つのブランチのうち一つのブランチを選び、その対象行を対となっているファイルと同等の記述にしてしまえば解決できるはずです。そんな難しい話ではなく、慌てずコマンド上のメッセージを確認して貰えれば大丈夫かと思います。
1.7. どのコミットがどこのブランチを指しているか確認したい
git log --oneline --decorate
【コメント】
便利（履歴が見やすかった）なので、メモしました。
「さっきのコミットってどのブランチにやった？」とか上司に言われたら、上記のコマンドを打ち込んでみて下さい。
1.8. ブランチを切り替える
git checkout <既存ブランチ>
git checkout -b <既存ブランチ>
※ブランチの作成と切り替えを一緒にやってくれる
【コメント】
基礎中の基礎、ですがこのオプション（-b)の存在を知りませんでした...。
はい、所詮この程度のエンジニアです。伸びしろあります。
1.9. ブランチを視覚的に確認する
git log --graph
【コメント】
これ、ちょっと感動しました。
ログを可視化できる（データをコマンドで可視化できる）って最高ですね。ねぇ、SE（システムエンジニア）の皆さん。
1.10. 作業が途中でコミットしたくないけど、別のブランチで作業しないといけない。その際、一旦作業を避難したい。
・一時避難
git stash
※ワークツリーでもなく、ステージでもなくstashという領域で一時避難できる
#避難した作業を確認する
git stash list
#避難した作業を復元する
git stash apply
#ステージの状況も復元する
git stash apply --index
#特定の作業を復元する
git stash apply [スタッシュ名]
#最新の避難した作業を削除する
git stash drop
【コメント】
これも結構便利かなと思います。
緊急で対応することが必要になった場合に最適すぎませんか？
チームの為に、すぐ対応できますよね？！
もっとも、僕は個人開発なんですね。。。チーム開発してみたい。。。
2. Git_ノウハウ編
2.1. バージョン（リモートリポジトリ・Github上で)管理しないファイルを選出する
→.gitignoreにてバージョン管理しないファイルを記述する
以下、gitignoreファイルの書き方
#ファイルをGithub上に上げないようにする
<ファイル名>
#ルートディレクトリをGithub上に上げないようにする
<ルートディレクトリ>
ex) /root.html
#ディレクトリ以下をGithub上に上げないようにする
<ディレクトリ名>/
ex) dir/
#/以外の文字列にマッチ「*」したものをGithub上に上げないようにする
/*/*.css
【コメント】
個人的には、今回1番学べて良かったことです。
2021年12月辺り、某企業がGithub上に顧客情報を上げてしまったことが大きな問題となった思います。
反面教師にする、とまではもちろん言いません（人間間違えある生き物です）。しかし、僕らも同じ道を辿ってしまう可能性があるので気をつけたいですね。
最後〜締め〜
約1日半でGit(Github)を学び直しました。
補足・不備等ございましたら、教えていただければ幸いです。