これらの単語はGitで何を意味しますか:リポジトリ、フォーク、ブランチ、クローン、トラック?


130

私は正直なところ、ここでのセマンティクスを明確にしていません。それらはすべてコード+履歴ユニットのコピー/バリアントに関するものですが、それを過ぎると私は言うことができるかどうかわかりません。この論理構造はどこかで説明されていますか?


5
Pro Gitブック(progit.org/book)の最初の数章を読むことをお勧めします。
ewall、

61
+1。多くのgitチュートリアルは、特定の単語の意味やgitの動作を説明せずに、特定のタスクを実行する方法を示しています。それらのトピックに対処するリソースを求めることは正当な質問です。
Daniel Stutzbach、

14
ダニエルのコメントをさらに+1したい。一部の用語(リポジトリなど)の意味は明白ですが、それらの関係は常に(ブランチ対フォーク)であるとは限らず、本当の意味は、集中化されたVCSに慣れているユーザーによって簡単に誤解されます。さらに、Pro Gitの「ブランチとは」をご覧ください。セクション-基本的なユーザーは本当にブロブとツリーについて知りたいのですか、それとも単にブランチが何であるかを質的に知りたいのですか?
カスカベル

1
@DanielStutzbach本で明確でないことについてのコメントを提出することが可能です。(私はそれを言うための正しい用語を知りません。)私はそうしました、私は本がリポジトリが何であるかを定義する必要があると言いました。私は、何かを非常によく理解している人々から概念的な資料を入手することは非常に難しいことに同意します。その本(現在)は、データベースがこのコンテキストで何であるかを定義せずにデータベースについて話し、リポジトリが何であるかについては何も述べていません。
user34660

回答:


146

リポジトリは、単に作業の履歴が保存される場所です。多くの場合.git、作業コピー(作業中のファイルの最新の状態のコピー)のサブディレクトリにあります。

プロジェクトをフォークするには(特定の時点で誰かのリポジトリからソースを取得し、独自の分岐した変更を適用します)、リモートリポジトリを複製してそのコピーを作成し、ローカルリポジトリで独自の作業を行います。変更をコミットします。

リポジトリ内にはブランチがあります。ブランチは、独自のリポジトリ内で効果的にフォークされます。あなたのブランチはあなたのリポジトリに祖先コミットを持ち、あなたの変更でそのコミットから分岐します。後でブランチの変更をマージできます。ブランチを使用すると、複数の異なる機能を同時に処理できます。

リモートリポジトリの個々のブランチを追跡することもできます。これにより、別の個人のブランチから変更を取り込み、それらを自分のブランチにマージできます。これは、あなたと友達が一緒に新しい機能に取り組んでいる場合に役立ちます。

すばらしいgit本がオンラインでたくさんあります。開始するには、ProGitGit Magic、および公式のチュートリアルとコミュニティブックをご覧ください。


もちろん、Fのマニュアルとチュートリアルを読むことが基本です。しかし、これは私にとって全体の素晴らしい要約のようです。とても有難い!
ブラソフィロ

ローカルの作業ディレクトリを新しいブランチに切り替えることができることに注意してください( "git checkout <new_branch>")。この場合、ローカルの作業ディレクトリのファイルは、切り替え先のブランチのコンテンツによって置き換えられます。ただし、作業内容が失われることはありません。Gitは、前のブランチで行ったすべてのコミットされた変更(「git commit」)をGitの「データベース」(非表示の.gitフォルダー)に保存し、ファイルを元に戻すことができます。
KrisWebDev 2013年

3
歴史的には、使用したVCSに関係なく、分岐と分岐は2つの別個のものと見なされていたので、特別な言及が必要だと思います。分岐は、開発者間での好ましい暗黙の合意と見なされました。フォークは、プロジェクトに取り組んでいる開発者がいくつかのことに同意せず、別れを決心したことを暗示しているため、より深刻でした。成功したフォークは通常、双方が合意に達した後で、後で1つのプロジェクトにマージされました。それ以来、Git(およびGitHub)はこれらの用語を曖昧にしており、両方の用語は基本的に同じ考えを表しますが、異なる方法で表現しています。
redteam316 2014年

では、リポジトリにはプロジェクトのファイルがありませんか?あなたはあなたの仕事の歴史が保存されいる場所を言います。それだけですか?ファイルの履歴ではなく、ファイル自体の履歴ですか?
user34660

13

RTFMで自分の質問に答えます。

しかし、この細かいマニュアルを読んでください。著者が言うように:

「私がこれから引き出す結論は、Gitがどのように機能するかを理解している場合にのみ、実際にGitを使用できるということです。短期的にはどのようなときに実行する必要があるコマンドを覚えているだけですが、行き詰まったり、さらに悪いことに、何かを壊したりするのは時間の問題です。

「Gitの既存のリソースの半分は、残念ながら、そのアプローチを採用しています。それらは、どのコマンドをいつ実行するかを順を追って説明し、それらのコマンドを模倣するだけで問題がないことを期待しています。残りの半分はすべての概念を通過しますが、私が見たものから、Gitがどのように動作するかをすでに理解していることを前提とした方法でGitを説明しています。」


この紹介はsbf5.com/~cduan/technical/gitに移動されたようです。元のURLは今のところまだ機能します。
エリックアンダーソン

1
これは、コンテキスト内でも同様です。すぐに生産性を上げる必要がある場合、または実際にコードをチェックインする必要がある場合は、gitの動作を深く理解しなくてもかまいません。チュートリアルは問題ありません。これは私がgitに入った方法です。ただし、ブランチの作成、フォーク、リベースなど、より高度なタスクが必要な場合は、gitがどのように機能するかを知っておく必要があります。特に、バックグラウンドが集中管理されている場合はそうです。
Phil

3

このGoogleTechTalkは、Gitの素晴らしい紹介であり、実際に舞台裏で何が起こっているのかを学びながら、言語も学びます。それはGitのごく初期の寄稿者によって与えられ、彼はGitへの導入の方法として2007年にこの講演を行いました。この話を見れば、リポジトリ、フォーク、ブランチなどの各単語が何であるかがわかるだけでなく、これらのそれぞれが作成、マージされたときなどの背後で何が起こっているかもわかります。

住所は長いですが、とても参考になります。また、Gitを他のバージョン管理システムと対比することで、Gitがそのように作成された理由と、他の管理システムと比較したGitの比較優位について理解を深めることができます。話は古いですが、立ち上がって実行することは非常に役立ちます。マニュアルに飛び込む前にこれを見ていた。結果として、物事はもっと理にかなっていると思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.