初学者のGitメモ

初学者なりにインプットしたGitの知識をまとめていきます。
------------------------------
Gitとは？
--

フォルダ、ファイルを管理し、すべてのファイルの変更履歴を保持してくれる「バージョン管理プログラム」である。

Gitってなんのためにあるの？
-------------------

・開発中にエラーが起きた際に戻るため。
・チームのエラーコードを修正するため。
・メンバーの作業を記録するため。

めちゃめちゃ便利であるためエンジニアとしてGitの知識は必要である。



Gitの分散管理バージョンシステム
--------------------------
Gitは分散管理バージョンシステム（DVCS）であるため、自分のPCにてローカルファイルで作業することも、複数のPCで作業することも、主となるサーバーを持っていないため複数のサーバーを介しても作業できます。

よく出てくるリポジトリってなんだ？
--------
リポジトリとはファイルやフォルダの変更履歴を保存する貯蔵庫のようなもの。
最終的にリポジトリは統合され、リポジトリを持つPCのすべてのローカルリポジトリと同期する。リポジトリは簡単にクローンできるのでバックアップも可能。

よく聞くGitHubってなんだ？
---------
コードのホスティングサービス
コードの履歴をオンライン上で保管してくれるもの。これによりコードを複数人で簡単に共有できるようになった。
プルリクエスト（自分のコードの変更を管理者に申請すること）で複数人開発が可能にもなった。
世界中のチームがGitHub上で開発している。


Gitの設定には３種類ある
-------
git config --local　現在のリポジトリの設定（自分がローカルで変更したリポジトリの設定）
git config --global　現在のPCユーザー全てのリポジトリの全ての設定。（該当のユーザーの全てのリポジトリの設定）
git config --system システム内の設定（全ユーザーの全リポジトリの設定）

よく聞くブランチってなんだ？
-----
履歴のツリーのイメージ。
履歴の流れを分岐して記録したもの。それぞれローカル環境にて分離しているので複数のファイルの変更を並行してすすめることができる。Gitを初めて初期化した時はマスターブランチと呼ばれるデフォルトの初期ブランチになる。
分岐することで複数の機能を開発する仕組みを実現するためにコミットIDを記録したポインタこそがブランチ


Gitはどのように履歴をバックアップしているのか？
-----
Gitはコミットするごとにファイルがどのように見えるかをスナップショットとしてゲットし、バックアップを取っている。そもそもコミット（Commit ）とは中の全てのファイルのスナップショット（バックアップ）を取ることを指す。（コミットでバージョンを記録していると理解すればOK)
スナップショットで保存することは差分で保存することより早く記録することができる。
コミットは連結しているのでたどることによって以前の状態に戻ることができる。

gitのブランチ補足
--
上記のコミットのポインタになるのがブランチである。
履歴のツリーであるブランチを参照して現在作業しているリポジトリ（HEADという）を過去のものに変更すればスナップショットとして保存される。それにより、その時点から再度開発を進められる。
Masterブランチは最新のブランチのことを指す



そんな過去に戻れるなんて魔法じゃない？
---
gitはコミットする際にファイルの中身や構造をチェックサムに通す（チェックサムとはデータを検証したりエラーを検出したりするために使われる数字や記号の羅列のこと）
だからユニークなハッシュ化された名前がcommit(スナップショット）に付けられて、いつでも戻れるようになる。また,
.gitの隠しファイルにはコミットやブランチの履歴が全て書かれる。

超基本コマンド
----
lsコマンド　　ディレクトリの内容を表示
mkdirコマンド　ディレクトリの作成
cpコマンド　ディレクトリの移動
ｍｖコマンド　ファイルの移動とファイル名の変更
catコマンド　ファイルの中身を表示する

ローカルレポジトリの詳細
---
ローカルレポジトリには三段階にエリアがある。
リポジトリ（HEAD）→（記録されたスナップショットを置いとくエリア）厳密に言えば「圧縮ファイル、コミット、ツリー」を保存している
ステージ→コミット（スナップショットを取る）を準備するエリア（git commitでスナップショットを記録してリポジトリエリアへ）一部の変更を記録するためにステージという準備エリアが存在する。
ワークツリー（作業ディレクトリ）　→ファイルを変更しているエリア（git　addでステージに移行）

コマンド
----
①git-init　　gitリポジトリが初期化され、.gitフォルダが作成される。
②git-status gitの状態の確認（現在作業しているディレクトリやコミットの履歴も確認できる）
③git add(filename) 変更したファイルをステージにあげる　(例　git add index.html)すべての場合はgit add -A
④git rm(filename)  対象のファイルを追跡から削除する。（ワークツリーとリポジトリから消すこと）
⑤git commit -m {message}　ステージングにあるファイルをコミットする（メッセージ付き）→これを実行すると上述のチェックサムが発動し、暗号化されたユニークなキーがコミット（スナップショット）に付与される。
＋＠
git -checkout　変更を取り消す
git clone クローンを作成する
git diff ワークツリーとステージノ差分
git diff -staged ツリー①、コミット１とステージの差分
git log コミットの履歴を見れる
git mv ファイルの移動を記録する
git remote add origin https://... オリジンというショートカットでURｌのリモートリポジトリを追加する。
git push (-u) origin master リモートリポジトリ（ギットハブにプッシュする）(-u)をつけると今後　git pushでおわる。
git config --global alias〇〇　メソッド　エイリアスで省略設定をできるようにする。
git　remote-v リモートリポジトリの詳細
git remote show origin リモート情報の参照
git remote rename 旧名　新名




作業ディレクトリ内のファイルの状態4種類
----
①追跡していないもの(Untracked)
②追跡している未修正のもの（unmodified）
③追跡している修正済みのもの（modified）、
④ステージング済み（staged）

よく聞くgitignoreってなんだ？
---
管理しないファイルをGitの管理から外すファイル。
こういったファイルは管理しないよ！
ファイル名をそのまま記載、ルートディレクトリを指定、　ディレクトリ以外を指定,*カードを指定



履歴のチェックアウト
----
ファイルの変更を取り消す
git checkout --ファイル名  　　　ステージの状態をワークツリーに反映させて変更を取り消す
git checkout --ディレクトリ名　ステージした変更を取り消す（ローカルでは消えないことが重要）
git reset HEAD ファイル名、ディレクトリ名でステージから指定した変更を消す。
ステージ文でしか消えない。

直前のコミットをやり直す
---
リモートリポジトリにプッシュしたコミットはやり直しだめ。
git commit --amend 直前のコミットを取り消す


リモートリポジトリから情報を取得する
--
git fetch (リモート名）　ローカルレポジトリに情報をくれる。ただワークツリーには情報はないから注意。
ワークツリーに移動するためにはgit mergeする必要がある

リモートリポジトリから情報をとってくるのを一気にしてくれる
git pull リモート名　master


ブランチに関して
----
git branch -a 全てのブランチを表示する
git branch ブランチ名　ブランチの作成
git checkout ブランチ名　ブランチを切り替える
マージとは他の人の変更内容を取り込む作業のこと　
git merge (リポジトリ名）　作業中のブランチに該当のものをマージする
git merge origin /master 作業中のブランチにマージする
マージコミットは親コミットを複数個持っている。
git branch -dブランチ名　ブランチを削除する　masterにマージしていなければ警告が出る
git branch -mブランチ名　ブランチ名の変更
git switch 新しいブランチに変更する
branchがないHEADのことをbranchHEADという。それにならないように気をつける。

コンフリクトに関して
-----
コンフリクトは同じファイルの同じ行に対して異なる編集を行った時。
複数人で同じファイルを変更しない。
pull mergeする前に変更中の状態をなくしておく。（Commitやｓtashをしておく）
git pullする時はpullするブランチに移動してからpullする
コンフリクトしても慌てない。

プルリクエストの手順
----
①　masterブランチを最新に更新
②ブランチを作成
③ファイルを変更
④　変更をコミット
⑤　githubへプッシュ
⑥プルリクエストを送る
⑦コードレビュー
⑧プルリクエストをマージ
⑨マージしたブランチを削除


GithubFlowとは
----
Github社のワークフロー
①マスターブランチからブランチを作成
②ファイルを変更し、コミット
③同名のブランチをGitHubへプッシュ
④　プルリクエストを送る
⑤コードレビューして、マスターブランチにマージする
⑥マスターブランチをデプロイする
注意点
マスターブランチは常にデプロイ状態を保つ
新開発はマスターブランチから新しいブランチを作成してスタート
作成した新しいブランチで作業しコミット
定期的にプッシュする
マスターにマージするためにプルリクエストを使う。
マスターブランチにマージしたらすぐにデプロイする
テストとデプロイ作業は自動化

マージとリベースの違い
--
mergeはブランチを合流、rebaseはブランチの根本の場所を変える・付け替えるイメージ



ファーストフォワードとノンファーストフォワードの違い
---
マージの種類のこと
①ファーストフォワード..つまり早送りのマージ　マスターブランチにどんどんコミットしていき新しいコミットを生成していくイメージ　コンフリクトが発生する。マージされるｂranchのHEADをそのままマスターとして先端に移動させる。
②ノンファーストフォワード..早送らないマージ　マスターとコミットが枝分かれになっているため必ずしもマスターはコミットしたものにならない。コンフリクトが発生しない
マージしたコミットが残るか残らないの違い。



おまけ
----

gitにはマージ戦略がいくつもあるらしい。上級者向けらしいが興味あったら調べよう