- The added line is THIS COLOR.
- The deleted line is THIS COLOR.
#setlinebreak(on)
*VCSの特徴 [#rf5a7834]
歴代のVCS(Version Control System: バージョン管理システム)の特徴
|名称|環境|リポジトリ|h
|RCS |スタンドアロン|なし(foobar.c,v)|
|CVS&br;Subversion|ネットワーク |単一のものを有|
|Git |~|複数のものが分散|
|名称|環境|管理単位|リポジトリ|h
|RCS |スタンドアロン|単一のファイル|単一のファイルをlock/unlock|
|CVS&br;Subversion|ネットワーク |ファイルツリー|ネット上で単一のリポジトリを有|
|Git |~|~|複数のリポジトリがネット上に存|
*リポジトリの内部構造 [#h2ffffc8]
Gitではコミットする度にリポジトリ内部にひとまとまりのデータ構造が作成される。
#ref(GitCommit.png)
-作成されるデータ構造の内訳
--コミットオブジェクト
一回のコミットそのものを表すデータオブジェクト。
---コミットオブジェクトを起点として、そのコミット時点の全ての情報を参照できる。
---コミットオブジェクトにはその内容から算出されるSHA1のハッシュが識別子として割り当てられる。これをコミットIDと呼ぶ。
---コミットオブジェクトはその直前のコミットオブジェクトを指し示している。これを手繰ってゆくことでコミットの履歴を新しい方から古い方へ参照することができる。
--ツリーオブジェクト
コミットオブジェクト毎に、管理しているファイルの階層関係を表すオブジェクト
---コミットオブジェクトはおおざっぱに言うとファイルの階層関係を記録しているだけ。
OSが管理するファイルシステムそのものを記録しているわけではないので、ファイルやディレクトリの属性がすべて記録されているわけではない。
特にそのファイルのオーナやグループは全く記録されていない。
--BLOB (Binary Large OBject)
ファイルの内容を保持するオブジェクト。
---ファイルオブジェクトにもファイル内容のSHA1のハッシュ値がIDとして割り当てられる。
Gitでは、BLOBのオブジェクトIDが同じであれば、実ファイルシステム上で異なるファイルであっても、あるいは全く関係ない別のリポジトリのファイルであっても、すべて「同一のもの」として扱われる。
-コミット
Gitでは、「コミット」という言葉は2つの意味を持つ。
一つは、リポジトリでコミットオブジェクトと、それが指し示すツリーオブジェクトとBLOBの全体を称して名詞的に使う。
例えば「コミットを取り出す」とか「２つのコミットの差分を調べる」というように使う。
もう一つは、他のVCSでも用いられる「コミットする」という動詞的な意味。~
この２つの違いを意識するとGitの理解が進む（と思う）。
-ブランチ
「ブランチ」という言葉も、他のVCSとは違う使われ方をする場合がある。
#ref(Branches.png)
--「枝」じゃない
--「ブランチ」は、コミットの一連の繋がりというよりは、「現在の最新のコミットを指し示すポインタ（のようなもの）」という意味合いで用いられる。
なので、あるブランチに対しコミットが追加されると、そのブランチは新たに追加されたコミットを指すようになる。
--Gitのリポジトリを作成すると、「master」というブランチが作成される。これは他のVCSでのMain Trunkのような役割を果たす。
--「HEAD」というブランチは、「現在作業対象となっているブランチ（カレントブランチ）」を表している。
-コミットの操作
コミットの操作（コミットの再試行、取り消し、変更）関連のコマンドは種類が多く、初学が混乱しやすい部分。
--''git reset''
--''git checkout''
--''git commit --amend''
--''git revert''
--''git rebase''
--''git cherry-pick'' ...など...
>これらはそれぞれのコマンドを実行することによってコミットオブジェクトがどのように変化するかを比較してみると、それぞれのコマンドの意味が理解しやすい(と思う)。
*分散リポジトリ [#xf535bc2]
#ref(DVCS.png,around,right)
--追跡ブランチ
--refspec
Gitでは複数のリポジトリを設置し、リポジトリ間でコミットを送受信することができる。
Gitの仕組み的には、てのリポジトリは対等。
通常は、基点となるリポジトリを設け、そのリポジトリから複製した別のリポジトリ上で作業を行い、その作業結果を基点となるリポジトリに集約する「中央リポジトリ方式」がよく使われる。
複製（クローン）したリポジトリには、複製元のリポジトリの状態を記録するための特殊なブランチが存在し、これを「追跡ブランチ」と呼ぶ。
-リモートリポジトリに手の追跡ブランチを同期させる操作をフェッチ(fetch)と呼ぶ。
-プル = フェッチ＋マージ
-ローカルブランチの容をリモートリポジトリに送りつける操作をプッシュと呼ぶ
リモートリポジトリを操作するには、
-ローカルリポジトリに存在するブランチ
-ローカルリポジトリの追跡ブランチ
-リモートリポジトリに存在するブランチ
を明確に区別して指定する要がある。このための記法をrefspec (参照仕様)と呼ぶ。
参仕様の理解もGitを使う上でのポイントの一つ（と思う）。
#img(,clear)
*おすすめドキュメント [#i179cf4a]
-Git入門：Git初学習者のための効率的な学習方法を考えてみた
--http://blog.takanabe.tokyo/2014/12/13/74/
http://blog.takanabe.tokyo/2014/12/13/74/
*ツールとか [#j61bde5d]
-GUIクライアント
-リポジトリ管理
-リポジトリ管理/ GitLab, GitBucketなど
*開発フロー [#fe8160b8]
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
*雑感 [#x011c350]
-時代の要請
-黒い画面怖い
-ほんこれ
>Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self­evident. Data structures, not algorithms, are central to programming. -- Rob Pike
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
