「わかばちゃんと学ぶ Git使い方入門」がコマンドを全く使わずにSourceTree(GUI)だけでgitの概念を説明してて良かった。備忘録的に、git用語・概念を書き出してみた

「わかばちゃんと学ぶ Git使い方入門」がコマンドを全く使わずにSourceTree(GUI)だけでgitの概念を説明してて良かった。備忘録的に、git用語・概念を書き出してみた

ちょっとお高いのが玉にキズ。gitコマンド編はネットで見れるみたい。
【連載】マンガでわかるGit ~コマンド編~

1, リポジトリ(repository = 貯蔵庫)
貯蔵庫の意味で、ソースを保存する一番デカい単位。
PCで言ったら、Cドライブみたいな感じ(実際にはフォルダ単位で管理する)
githubなとネット上にあるのがリモートリポジトリ
自分のPCをにあるのが、ローカルレポジトリ
管理したいフォルダに移動して、git initするだけで生成される。

2, ブランチ(branch = 枝)
PCで言ったら、Cドライブ直下のフォルダみたいな感じ。
リポジトリを作成すると、デフォルトでmatsterブランチが作成される(これが本流)
masterブランチに対して支流となる、devブランチやdebugブランチを作成してコードを修正
最終的には、masterブランチへマージ(統合)する

3, クローン(clone = 複製)
リモートリポジトリから、自分のPCへローカルレポジトリを作成する事。

4, フォーク(fork = 二股)
他人のアカウントにあるリポジトリを、自分のアカウントのレポジトリとしてコピーする事

5, コミット(commit = 確約)
レポジトリの変更を保存する事。いわゆるセーブ

6, プッシュ(push = 押す)
ローカルレポジトリの変更を、リモートリポジトリに反映させる。いわゆるアップロード

7, プル(pull = ひっぱる)
リモートレポジトリの変更を、ローカルリポジトリに反映させる。いわゆるダウンロード

8, マージ(merge = 統合)
a, ブランチのマージ = devブランチをmasterブランチにマージする(devブランチはmasterブランチに吸収されなくなるイメージ)
b. pullする時のマージ = ローカルレポジトリの修正に、リモートリポジトリの修正を取り込む事。
pushする時のマージは、差分があると先にpullしろ!と怒られるので、システム的に起こらない。

9, コンフリクト(conflict = 衝突)
マージする時に、同じファイルの同じ箇所(とgitが判断した)に、別々の修正が入った場合に起こる衝突。
gitでは判断できないため、どちらの修正を優先するか(最終的なソース)は人間が判断して決める。

10, プル・リクエスト(pull request = プルを要求)
devブランチなどの修正を、masterブランチにpullしてマージして!という要求。
厳密には、gitの機能ではなく、githubの機能。
ユーザから別ユーザへの通知

11, .gitignoreファイル(ignore = 無視)
gitコミット(セーブ)する時に、git管理する対象外を指定する。
環境ごとに違う設定ファイル・キャッシュファイル・アップロードされた画像ファイルなど

12, revert(元に戻す)
特定のコミットを無かった事にする(コミットログには残る)
resetコマンドの場合は、コミットログからも削除される。

13, rebase(再構成?)
マージと同じくブランチを統合する。gitログの表示が一直線になって見やすくなるが、コミットIDが再発行されるので、リモートリポジトリ上で行うとpushできなくなるリスクがある。

14, squash(押しつぶす)
pushする前なら、複数のコミットを1コミットにまとめる事ができる。

15, リモート追跡ブランチ(ローカルリポジトリに存在する)
push/pullは、リモートリポジトリ⇔ローカルレポジトリで、直接やり取りされている訳ではない
リモートリポジトリ⇔リモート追跡ブランチ⇔ローカルレポジトリ

16, fetch(取ってくる)
リモートリポジトリ→リモート追跡ブランチだけで、ローカルレポジトリには反映されない

17, merge
fetchした後に、リモート追跡ブランチ→ローカルレポジトリに反映させる。
pull = fetch + merge
実際にマージする前にコンフリクトが起こるかどうか確認する事が出来る。
git merge master –no-commit
実際にファイルは変更されてしまっているので、コマンドで元に戻す。
git merge –abort

18, コミットログの修正。push前なら修正可能。ammend=ミスや不都合の修正なので、そのまんま
git commit -m “間違ったコメント”
git commit –amend -m “正しいコメントに修正”
push後に過去のコミットを変更すると、歴史の改変になりpush出来なくなるリスクがある。
※ 実際には、rebaseやgit push -f で変更する事は可能。

19, スタッシュ(stash = 横に置く、見つからないように隠しておく)
修正中にpullする必要がある時に使う。commitした後に修正無しの状態じゃないとpull出来ない。
git stash # commit後の変更を退避
git pull # リモートリポジトリの変更を取得
git stash apply # 退避した変更を元に戻す

20, タグ(tag=名札)
コミットにメッセージとは別に名前が付けられる。普通はバージョンとか書いておく