Git の学習コストが高くて酷いので、数分で理解できるように無理やり説明してみます。
大雑把に理解した後、詳しく説明したドキュメントを読んで下さい。
まともに仕組みを理解しようとすると、数時間以上は必要かと思います。
前提知識
cvs, svnなどバージョン管理システムを利用したことがあることを前提としています。
レポジトリ、ブランチ、コミット、マージ、コンフリクト等の意味は、理解していることを前提とします。
歴史
- 元はLinux のカーネル用に Linus が開発。(今は、濱野 純氏がメンテナ)
- 動作(マージ)速度を重視。
なので、無駄なマージ処理等しない工夫があったりする。
が、それによって理解が難しい一面になっているように思う(個人的感想)
分散型レポジトリ
- 分散型レポジトリ
- CVS, subversionのようにレポジトリが一箇所じゃない
- レポジトリ自体をローカルにコピー(clone)してくる
- そのローカルのレポジトリにコミットする
- ローカルのレポジトリにコミットしたものをリモートのレポジトリにpushする
- リモートとローカルで使うことが多い
- よくある例: GitHub であるレポジトリを自分のGitHubアカウントにforkする。そのレポジトリを自分のローカルPCにコピー(clone)して開発。というパターンが一般的。
- 複数のリモートレポジトリを持ったりすることもある
- 誰かのローカルレポジトリの内容を自分のローカルに取り込む、なども可能
どこに反映する?
- どこのレポジトリ?
- どこのブランチ?
上記2つを指定する必要がある。
分散レポジトリなので、どこのレポジトリのどのブランチにpushするの? を指定する。
GitHub からレポジトリをコピー(clone)して、ローカルでdevelopブランチを作ってそこにコミットし、別のリモートにあるgit レポジトリ(例えば BitBucket) にあるdevelopブランチに、pushする。などができる。
origin master って?
よく見るのが、git push origin master の "origin master"。
- origin が、リモートレポジトリの場所の別名
- master は、master ブランチ
つまり、どこのレポジトリの、どのブランチかを指定する
3つの状態
この3つの状態を初めに理解するのが重要です。
下記の3つの状態に作業を行うからです。
- 作業ディレクトリ
- ステージング・エリア
- Gitディレクトリ (レポジトリ)
作業ディレクトリで変更ファイルをステージにあげてから、レポジトリにコミットします。
作業の流れ
よくある作業の流れ
- GitHubの場合(GitHubの本家レポジトリを自分のGitHubにforkする)
- リモートのレポジトリをコピー (git clone [リモートレポジトリの場所])
- 作業ブランチを作成 (git branch [ブランチ名])
- 作業ブランチに移動 (git checkout [ブランチ名])
- 作業ディレクトリで、ファイルを変更する
- 状態の確認 (git status)
- ステージング・エリアに変更済みファイルを追加 (git add)
- コミット (git commit)
- コミットしたものをリモートレポジトリにプッシュ (push)
- GitHubの場合、本家にプルリクエストを送るパターンが多い
その他、よくある作業
- リモート・レポジトリの変更の取り込み、マージ
- マージ・コンフリクトの解消
- ファイル、ブランチの削除
- 作業の取り消し
チームで作業しはじめ、沢山のリモートレポジトリ、ブランチと作業し始めると、さらい複雑で学習コストがかかります。
ファイルの状態
git status でファイルの状態の確認する時に必要な概念です。
gitに認識されているか、いないか?
- 追跡されている (tracked)
- 追跡されてない (untraced)
追跡されているファイルの3つの状態
- 変更されていない (unmodified)
- 変更されている (modified)
- ステージされている (staged)
コミット情報のやり取り
無理やり大雑把に表現すると以下のような感じ
リモートとローカルレポジトリとのやり取り
- fetch
- push
ローカルレポジトリとのやり取り
- add
- commit
(ローカル&リモート)ブランチとのやり取り
- merge
- pull (= fetch & merge )
その他
- svn update 的な git update はないよ
レポジトリ管理のディレクトリ
.git ディレクトリ以下で管理
リモートレポジトリの変更を取り込む方法
git merge か git rebase かがわかりづらい!! (別記事で書く!)
Fast forward (早送り)
- マージの命令が来ても、結局ファイルが一緒なら実際にファイルのマージしないで、コミットの先頭に持っていくだけ 巨大なLinux kernelのように無駄なマージコスト削減のためと思われる
その他、覚える必要があること
- git pull と git rebase の違い
- git stash でファイル変更を一時退避
- コンフリクトの解消方法
- add, commit, push作業の取り消し方法
参考
Git - Wikipedia
http://ja.wikipedia.org/wiki/Git
Git - Book
http://git-scm.com/book/ja/