Git
![]() | |
![]() GitのWebインターフェース、gitweb | |
| |
2005 | |
2.46.0[1] ![]() | |
リポジトリ | |
プログラミング | C, Bourne Shell, Tcl, Perl |
Unix | |
バージョン | |
ライセンス | GNU General Public License バージョン2,GNU Lesser General Public License 2.1 |
git-scm |
Git(ギット[2][3][4][5])は、プログラムのソースコードなどの
Gitでは、
背景 および概要
[Linuxカーネルの
Linuxカーネルの
作業 の流 れ
[Gitは
- リモートサーバ
等 にある中心 リポジトリをローカルに複製 する (git clone)。 - ローカルでコンテンツの
修正 ・追加 ・削除 を行 い、ローカルリポジトリに変更 履歴 を記録 する (git commit)。必要 に応 じて過去 の状態 の閲覧 や復元 などを行 う。場合 によってはこのステップを何 度 か繰 り返 す。 - ローカルの
変更 内容 を中心 リポジトリに反映 させる (git push)。作業 者 ごとの変更 内容 が衝突 することもある。Gitが自動 で解決 できる場合 もあれば、手動 での解決 (git merge)が必要 なこともある。 更新 された中心 リポジトリ(他者 の作業 内容 も統合 されている)をローカルの複製 にも反映 する (git pull)。これによりローカル環境 のコードも最新 の内容 になるので、改 めてステップ2の作業 を行 う。
リポジトリ
設計
[Gitの
Gitの
- ノンリニアな
開発 スタイルに対 する強力 なサポート。Gitではブランチやマージが高速 に行 える。また、ノンリニアな開発 の履歴 を可視 化 ・ナビゲートするための専用 のツールを同 梱 している。また、ツリーに対 する1回 の変更 に対 して、複 数 回 のマージが発生 するという前提 を置 いているが、これは変更 点 が複数 のレビュアーによってレビューされることを想定 しているためである。 分散 開発 。他 の分散 型 バージョン管理 システム(Mercurial、BitKeeper、Darcs、Bazaar、SVK、Monotone)と同様 に、Gitでも各々 の開発 者 がリポジトリの完全 なコピーをローカルに保持 しており、各 開発 者 の行 った変更 は他 のリポジトリにコピーされる。これらの変更 は新 しい開発 用 ブランチとしてインポートされる。また、ローカルな開発 用 ブランチへのマージも可能 である。- HTTP、FTP、gitプロトコル(sshを
利用 したトンネリングも可能 )を使用 したリポジトリの配布 が可能 。また、CVSサーバのエミュレーション機能 を使用 すれば、既存 のCVSクライアントやIDEのプラグインからGitリポジトリにアクセスできる。 - git-svnを
使用 すれば、Subversionおよびsvkのリポジトリを直接 操作 できる。 大 きなプロジェクトにおける処理 の効率 化 。Gitは非常 に高速 かつスケーラブルになるよう記述 されている[16]。Mozillaによって行 われたパフォーマンステストでは、他 のリビジョンコントロールシステムと比較 して10倍 、処理 によっては100倍 高速 に動作 することが示 された[17][18]。- ツールキット
化 された設計 。gitはC言語 で書 かれたプログラム一式 と、それらのラッパーとなる何 本 かのシェルスクリプトで構成 されている[19]。GitをWindowsに移植 する過程 で、シェルスクリプトのほとんどはC言語 で書 き直 された。しかし、現在 でも複数 のコンポーネントを繋 げることで複雑 な処理 を容易 に行 えるような設計 になっている[20]。 - プラガブルなマージアルゴリズム。Gitでは
不完全 なマージに対 する優 れたモデル化 が行 われている。また、不完全 なマージを補完 するアルゴリズムも複数 存在 する。最終 的 に自動的 なマージが行 えなかった場合 には、ユーザによる編集 が必要 である旨 がユーザに通知 される。 - ガベージコレクションは
行 われない。操作 を中断 したり変更 の取 り消 しを行 った場合 、データベース中 には不要 なデータが残 ったままになる。これらのデータは操作 対象 のオブジェクトの履歴 に比例 して大 きくなる。git-gc --prune
コマンドを使用 して明示 的 にガベージコレクションを行 うこともできるが、この処理 には時間 がかかる[21]。
Gitの
- プロジェクト
全体 の変更 履歴 を調 べるよりも、一 つのファイルの変更 履歴 を調 べる方 が時間 がかかる[23]。特定 のファイルの変更 履歴 を取得 する場合 、Gitはツリーの履歴 全体 を走査 し、各 リビジョンでそのファイルに変更 があったかどうか調査 する必要 がある。ただしこの処理 手順 では、一 つのファイルに対 しても、任意 のファイルの集合 に対 しても、ほぼ同 じ時間 で履歴 の調査 が行 える。よく行 われる処理 としては、例 えば「ソースツリー中 のあるサブディレクトリと、それに関係 するヘッダファイルの調査 を行 う」といったものがある。 - ファイル
名 の変更 を明示 的 に扱 わない。CVSに対 してよく挙 げられる不満 として、ファイルのリネームや移動 を行 うと変更 履歴 が途切 れてしまう問題 がある。これは、変更 履歴 の識別 にファイル名 を使用 しているためである。CVS以降 に開発 されたバージョン管理 システムの多 くでは、管理 対象 のファイルに対 してファイル名 より寿命 の長 い、内部 的 な名前 (inode番号 のようなもの)を付与 することでこの問題 を解決 している。一方 、Gitではそのような内部 名 を使用 しておらず、その点 が長所 であるとしている[24][25]。プログラムのソースコードに対 しては、リネームの他 にも分割 やマージといった処理 が行 われる[26]。これらの処理 を単純 にファイルのリネームとして十把一絡 げに扱 うと、実際 にソースコードツリーに対 して行 われた処理 が何 であるか不明瞭 なまま履歴 に記録 されてしまう。Gitでは、リネームの検出 をスナップショット作成 時 ではなく履歴 のブラウズの際 に行 うことでこの問題 を解決 している[27]。(単純 に考 えれば、リビジョンN中 のあるファイルに対 して、リビジョンN-1中 に同 じ名前 のファイルがあれば、それが元 ファイルと考 えられる。しかし、リビジョンN-1中 に似 たような名前 のファイルがない場合 もある。この場合 Gitは、リビジョンN-1のみに存在 し、かつ似 たような内容 のファイルを検索 する。)しかし、この処理 は履歴 の表示 を行 う度 にCPUに負荷 のかかる処理 が必要 となる。そのため、使用 するヒューリスティックを選択 するオプションが提供 されている。
リポジトリの
- Gitは
新 しく作成 されたオブジェクトを個別 のファイルの形 で保存 する。各 ファイルは圧縮 されて保存 されるが、そうであったとしてもこの方法 は記録 領域 を大量 に必要 とするため非 効率 的 である。Gitはこの問題 を“pack”を使用 することで解決 している。複数 のオブジェクトは一 つのファイル(またはネットワークバイトストリーム)の形 にパックされ、各 pack間 で差分 圧縮 が行 われる。packの差分 圧縮 にはヒューリスティックが用 いられる。例 えば、同 じ名前 のファイルは似 た内容 である可能 性 が高 いものとして処理 される。ただし、リポジトリの正確 性 を保 つため、ヒューリスティックに完全 に依存 することはない。現在 のGitでも新 しく作成 されたオブジェクト(新 しく加 えられた履歴 )はまず単一 のファイルとして保存 されるため、空間 効率 を高 く保 つためには定期 的 な再 パックが要求 される。Gitはこの定期 的 な再 パックを自動的 に行 うが、git gc
コマンドを使用 することで手動 で再 パックを行 うこともできる。
Gitは
- resolve
従来 通 りの3-wayマージアルゴリズムを使用 する。- recursive
- 3-wayマージの
変種 を使用 する。ブランチのmergeやpullを行 う場合 のデフォルトである。3-wayマージにおいて共通 の祖先 が複数 ある場合 、共通 の祖先 からのmerge treeを作成 し、それをreference treeとして3-wayマージを行 う。Linuxカーネル2.6の開発 で行 われたマージコミットの履歴 から、このアルゴリズムを使用 するとマージの衝突 が少 なく、マージ漏 れもなかったことが報告 されている。さらに、リネームを伴 うマージに対 しても検出 および処理 が可能 である[29]。 - octopus
- 3つ
以上 のheadからのマージを行 う場合 のデフォルトである。
歴史
[名前 の由来
[リーナス・トーバルズによれば[30]、
「 | 」 |
Gitのオフィシャルサイトのウィキでは、“Git”という
開発 初期 の歴史
[Gitの
リーナスはBitKeeperと
「 |
だけど、 BKはスピード だから、 (パッチの |
」 |
リーナスは
- CVSを「
悪 い見本 」とする。設計 上 のことで確信 が持 てない場合 は、CVSと逆 の決断 をする。リーナスは冗談 めかして以下 のように語 っている。- “カーネルメンテナンスの
最初 の10年間 、僕 らは文字通 りtarボールとパッチを使 っていた。CVSよりもずっと優 れたソース管理 システムさ。僕 は営利 企業 (トランスメタ[34])でCVSを7年間 使 わされたことで、CVSを強烈 に憎 むようになった。CVSを強烈 に憎 んでいると言 う時 には、このことも言 っておかなくちゃいけないね。観衆 の中 にSVN (Subversion) のユーザがいるなら、この場 から去 ったほうがいいかもしれない。僕 がCVSを強烈 に嫌悪 しているということは、僕 がSubversionが史上 最大 の無意味 なプロジェクトであると思 っていることも意味 しているんだ。Subversionのしばらくのスローガンは‘ちゃんとCVSをやる’とかそんなものだったよね。そんなスローガンから始 めたら、どこにも辿 りつけないよ。CVSをちゃんとやるなんて不可能 なのさ。”[35]
- “カーネルメンテナンスの
分散 型 の、BitKeeperのようなワークフローをサポートする。- “BitKeeperだけが、「まあ
使 ってもいいかな」と最初 に思 わせてくれたSCMだというわけではないけれど、BitkeeperはSCMというものの存在 意義 と、実際 にどう使 うことができるのかを教 えてくれた。だから、Gitは技術 的 な観点 とかいろんなところでBitkeeperとは随分 違 うものになっているけど(それはもう一 つの設計 目標 でもある。Bitkeeperのクローンではないことをはっきりさせたかったから)、Gitのワークフローの多 くは、Bitkeeperが教 えてくれたフローから直接 きたものになっているんだ。”[35]
- “BitKeeperだけが、「まあ
- データ
破壊 に対 する強力 な抑止 機能 。データ破壊 は、偶然 によるものと意図 的 なものの両方 を想定 している[36][35]。 非常 に高 い処理 速度 。
Gitの
BitKeeperからの
ブランチモデル
[ソフトウェア
GitHub flow
[GitHub flowはブランチモデルのmaster
ブランチはmaster
からforkする。マージmaster
が
2011master
へマージされ、そこからデプロイされる。GitHubmaster
へmergeされている[47]。このモデルmaster
のrevert commitではなくmaster
の
マージ
[Gitはブランチのマージ(merge)に
マージがgit merge
がマージコミットをgit add
をおこない、git commit
あるいはgit merge --continue
をおこなってはじめてマージコミットが
マージコミットの
注釈
[- ^ LKML.ORG - the Linux Kernel Mailing List Archive
- ^ a b ここでは -mm ツリーメンテナのアンドリュー・モートンを
指 す。
出典
[- ^
濱野 純 ; "[ANNOUNCE Git v2.46.0"];出版 日 : 2024年 7月 29日 ;閲覧 日 : 2024年 7月 29日 . - ^ Tech Talk: Linus Torvalds on git.
該当 時間 : 1分 30秒 . 2014年 7月 21日 閲覧 。 - ^ “Git - IT
用語 辞典 e-words”. 2014年 7月 29日 閲覧 。 - ^ “Gitとは”. クラウド・データセンター
用語 集 /IDCフロンティア. 2024年 8月 4日 閲覧 。 - ^ “
入門 Git (ギット)”. Google Books. 2024年 8月 4日 閲覧 。 - ^ Scott Chacon「1.2
使 い始 める-Git略 史 」『Pro Git』 。2021年 3月 7日 閲覧 。 - ^ a b c d e Scott Chacon. “4.1 Git サーバー - プロトコル”. 2013
年 1月 19日 閲覧 。 - ^ Scott Chacon; Ben Straub. “Pro Git 2nd Edition 4.6 Gitサーバー - Smart HTTP”. 2021
年 8月 26日 閲覧 。 - ^ “Git - user-manual Documentation” (
英語 ). 2021年 8月 26日 閲覧 。 “(See also setup-git-server-over-http for a slightly more sophisticated setup using WebDAV which also allows pushing over HTTP.)” - ^ “git-clone(1) Manual Page” (
英語 ). 2017年 6月 14日 閲覧 。 “in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it” - ^ “Documentation/RelNotes/2.8.0.txt” (
英語 ). 2017年 6月 14日 閲覧 。 “The rsync:// transport has been removed.” - ^ Linus Torvalds (5 May 2006). "Re: [ANNOUNCE] Git wiki". linux-kernel (Mailing list). 2009
年 3月 3日 閲覧 。 Gitの元 となったプログラムに関 する歴史 的 経緯 - ^ Linus Torvalds (7 April 2005). "Re: Kernel SCM saga". linux-kernel (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Linus Torvalds (8 April 2005). "Re: Kernel SCM saga". linux-kernel (Mailing list). 2008
年 2月 20日 閲覧 。 - ^ Linus Torvalds (23 March 2006). "Re: Errors GITtifying GCC and Binutils". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Linus Torvalds (19 October 2006). "Re: VCS comparison table". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Stenback, Johnny (2006-11-30), “bzr/hg/git performance”, Jst's Blog 2008
年 2月 20日 閲覧 。, "git diff"と"bzr diff"のベンチマーク結果 の比較 。ケースによっては、gitの処理 速度 はBazzarの100倍 以上 になる。 - ^ Roland Dreier (2006
年 11月13日 ). “Oh what a relief it is”. 2009年 3月 3日 閲覧 。, "git log"は"svn log"と比較 して100倍 以上 高速 だが、これは後者 はリモートのサーバにアクセスする必要 があるためである。 - ^ Linus Torvalds (18 October 2006). "Re: VCS comparison table". Git (Mailing list). 2009
年 3月 3日 閲覧 。, Gitのスクリプト指向 デザインについて - ^ iabervon (2005
年 12月22日 ). “Git rocks!”. 2009年 3月 3日 閲覧 。, Gitを使 ったスクリプトの書 きやすさに関 する賞賛 - ^ “Git User's Manual” (2007
年 8月 5日 ). 2009年 3月 3日 閲覧 。 - ^ Linus Torvalds (10 April 2005). "Re: more git updates." linux-kernel (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Bruno Haible (11 February 2007). "how to speed up "git log"?". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Linus Torvalds (1 March 2006). "Re: impure renames / history tracking". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Junio C Hamano (24 March 2006). "Re: Errors GITtifying GCC and Binutils". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Junio C Hamano (23 March 2006). "Re: Errors GITtifying GCC and Binutils". Git (Mailing list). 2009
年 3月 3日 閲覧 。 - ^ Linus Torvalds (28 November 2006). "Re: git and bzr". Git (Mailing list). 2009
年 3月 3日 閲覧 。,git-blame
コマンドを使用 したソースファイル間 のコードの移動 の調査 について - ^ Linus Torvalds (2007
年 7月 18日 ). “git-merge(1)”. 2009年 3月 4日 閲覧 。 - ^ Linus Torvalds (2007
年 7月 18日 ). “CrissCrossMerge”. 2009年 3月 4日 閲覧 。 - ^ “After controversy, Torvalds begins work on git”. InfoWorld. (2005-04-19). ISSN 0199-6649 2008
年 2月 20日 閲覧 。. - ^ “GitFaq: Why the 'git' name?”. 2007
年 3月 21日 閲覧 。 - ^ Jonathan Corbet (2005-04-20), “How Tridge reverse engineered BitKeeper”, Linux Weekly News 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (7 April 2005). "Re: Kernel SCM saga." linux-kernel (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (31 October 2005). "Re: git versus CVS (versus bk)". Git (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ a b c d e f Linus Torvalds (3 May 2007). Google tech talk: Linus Torvalds on git.
該当 時間 : 02:30. 2007年 5月 16日 閲覧 。 - ^ Linus Torvalds (10 June 2007). "Re: fatal: serious inflate inconsistency". Git (Mailing list). 2009
年 3月 26日 閲覧 。 Gitにおけるデータの完全 性 に関 する設計 目標 に関 する概要 説明 。 - ^ a b Linus Torvalds (27 February 2007). "Re: Trivia: When did git self-host?". Git (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (6 April 2005). "Kernel SCM saga." linux-kernel (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (17 April 2005). "First ever real kernel git merge!". Git (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Matt Mackall (29 April 2005). "Mercurial 0.4b vs git patchbomb benchmark". Git (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (17 June 2005). "Linux 2.6.12". git-commits-head (Mailing list). 2009
年 3月 26日 閲覧 。 - ^ Linus Torvalds (20 October 2006). "Re: VCS comparison table". Git (Mailing list). 2009
年 3月 26日 閲覧 。 Git vs. BitKeeperの議論 - ^ Linus Torvalds (27 July 2005). "Meet the new maintainer..." Git (Mailing list). 2009
年 3月 26日 閲覧 。 - ^
濱野 純 (Junio C Hamano) (21 December 2005). "ANNOUNCE: GIT 1.0.0". Git (Mailing list). 2009年 3月 26日 閲覧 。 - ^ a b Scott Chacon (2011
年 8月 31日 ). “GitHub Flow”. 2020年 5月 31日 閲覧 。 - ^ "#1 - anything in the master branch is deployable.
This is basically the only hard rule of the system."[45] - ^ “GitHub Guides”. 2020
年 5月 31日 閲覧 。 “With GitHub, you can deploy from a branch for final testing in production before merging to master.” - ^ "A merged version ... is committed, and your
HEAD
, index, and working tree are updated to it."[git 1] - ^ "Paths that merged cleanly are updated both in the index file and in your working tree."[git 1]
- ^ "When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area."[git 1]
- ^ "Edit the files into shape and git add them to the index. Use git commit or git merge --continue to seal the deal."[git 1]
- ^ "the branches to be merged must be tied together by a merge commit that has both of them as its parents."[git 1]
関連 項目
[- GitHub
- バージョン
管理 システム - arch
- Bazaar
- BitKeeper - Git
以前 にLinuxカーネル開発 で使用 されていたバージョン管理 システム。ライセンス発行 に関 わる問題 によりGitが開発 されることとなった。 - Concurrent Versions System (CVS)
- Mercurial - Gitとほぼ
同 時期 に開発 が開始 された。 - Apache Subversion
外部 リンク
[- Git -
公式 ウェブサイト - Index of /pub/software/scm/git/ - Gitの
配布 ディレクトリ - Git for Windows - Windows
版 Gitの配布 サイト。 - Pro Git book
- Pro Git book