0b10

を使用したGitの前のバージョン管理Githubは2008年に開始されました。 あなたのソフトウェアエンジニアリングのキャリアが、私のように、Githubよりも古くない場合、Gitはあなたが今まで使用した唯一のバージョン管理ソフ 人々は時々その急な学習曲線や直感的なインターフェイスについて群がっていますが、Gitはバージョン管理のために誰もが行くようになっています。 InStack Overflowの2015年の開発者調査では、回答者の69.3％がGitを使用しており、第二の人気のあるバージョン管理システムであるSubversionを使用していました。1 2015年以降、Stack Overflowは、Gitが非常に普及していたためか、彼らが使用するバージョン制御システムについて開発者に尋ねるのをやめました。

Git自体はGithubよりも古いものではありません。 Linus Torvaldsは2005年にGitの最初のバージョンをリリースしました。 今日の若い開発者は、”バージョン管理ソフトウェア”という言葉がGitを意味していない世界を考えるのは難しいかもしれませんが、そのような世界はそれほどずっと前に存在していました。 から選択する多くのofalternativesがありました。 オープンソースの開発者はSubversion、企業、ビデオゲーム会社がPerforceを使用していました（一部はまだ使用しています）が、linuxカーネルプロジェクトは有名にbitkeeperと呼ばれるバージ

これらのシステムのいくつか、特にBitKeeperは、時間に戻って輸送youngGitユーザーに精通していると感じるかもしれません。 ほとんどはしないだろう。 BitKeeperはさておき、Gitの前に来たversioncontrolシステムは、基本的に異なるパラダイムに従って動作しました。 Versioncontrol by Exampleの著者であるEric Sinkが提供する分類では、Gitは第三世代のバージョン管理システムですが、1990年代から2000年代初頭に普及したGitの前任者の大部分は第二世代のバージョン管理システムです。2第三世代バージョン管理システムが分散されている場合、第二世代バージョン管理システムが集中化されています。 Gitが以前に「分散型」バージョン管理システムとして説明したことはほぼ確実に聞いたことがあります。 少なくとも、集中型の第二世代バージョン管理システムをインストールして実験するまでは、分散/集中型の区別をまったく理解していませんでした。

私がインストールしたシステムはCVSでした。 Cvsは、Concurrent Versions Systemの略で、最初の第二世代のバージョン管理システムです。 また、2000年にSubversionによって置き換えられるまで、約10年間、最も人気のあるバージョン管理システムでした。 それでも、Subversionは”CVSが、より良い”と思われていました。

CVSは、1986年にオランダのコンピュータ科学者Dick Gruneによって最初に開発されました。3CVSは当初、Gruneが改善したいと考えていた第一世代のバージョン管理システムであるrcs（Revision Control System）をラップするシェルスクリプトのコレクションにすぎ RCSはpessimisticlockingモデルに従って動作し、二人のプログラマが一度に単一のファイルで作業することはできません。 ファイルを編集するには、最初にrcsに排他ロックを依頼する必要がありますファイル上で、編集が完了するまで保持します。 他の誰かがすでに編集する必要があるファイルを編集している場合は、待つ必要があります。 CVSはrcsで改善され、楽観的なロックモデルを交換することにより、第二世代のバージョン管理システムを導きました。 プログラマは今、彼らの編集をマージし、任意のconflictslaterを解決し、同時に同じファイルを編集することができました。 （後にCVSプロジェクトを引き継いだエンジニアのBrian Berlinerは、1990年にCVSの革新について非常に読みやすい論文を書いた。その意味では、cvsは楽観的なモデルに応じて機能するGitとそれほど違いはありませんでした。 しかし、それは類似点が終わるところです。 事実、Linus TorvaldsがGitを開発していたとき、彼の指導原則の一つはwwwcvsnd、または”CVSは何をしないだろうか。”彼は決定について疑問があったときはいつでも、彼はcvsの設計で選択されていなかったオプションを選択するように努力しました。そのため、CVSは10年以上前にGitに先行していましたが、gitは一種の否定的なテンプレートに影響を与えました。私はCVSで遊んで本当に楽しんできました。

私はGitの分散性がなぜ前に来たもののような改善であるのかを理解するためのより良い方法はないと思います。 だから私はエキサイティングな旅に私と一緒に来て、あなたの人生の次の十分を過ごすために招待しますsoftwarenobodyの作品についての学習は、最後の十年に使 （訂正を参照してください。)

CVSの入門

CVSのインストール手順は、プロジェクトのホームページにあります。 MacOSでは、cvsを使用してインストールすることができますhomebrew。CVSは集中管理されているため、Gitのようなものではない方法でクライアント側のユニバースとサーバー側のユニバースを区別します。 違いはそれほど顕著ではないので、異なる実行可能ファイルがあります。 しかし、CVSの使用を開始するには、自分のマシンであっても、CVSバックエンドを設定する必要があります。

CVSバックエンドは、すべてのコードの中央ストアであり、リポジトリと呼ばれます。Gitでは、通常、すべてのプロジェクトのリポジトリがありますが、CVStheリポジトリにはすべてのプロジェクトが保持されます。 一度にプロジェクトだけで作業する方法はありますが、すべての中央リポジトリがあります。ローカルリポジトリを作成するには、initコマンドを実行します。 これは、ホームディレクトリのようにグローバルな場所で行うでしょう。CVSでは、cvsinitcvsコマンドの後に表示されるオプションはグローバルなinnatureですが、サブコマンドの後に表示されるオプションはサブコマンドに固有です。 この場合、-dフラグはグローバルです。 ここでは、CVSwhereにリポジトリを作成したいと伝えますが、一般的には-d-dCVSROOT環境変数を設定することができます。

ローカルで作業しているので、-d引数のパスを渡しましたが、ホスト名を含めることもできました。

コマンドは、ホームディレクトリにsandboxsandboxCVSROOTと呼ばれる別のdirectorycallが含まれていることがわかります。 このディレクトリは、environmentvariableと混同しないように、リポジトリの管理ファイルを保持します。

おめでとうございます！

最初のCVSリポジトリを作成しました。

コードのチェックイン

好きな色のリストを保持することにしたとしましょう。 あなたは芸術的に傾斜していますが、非常に物忘れのある人です。 Listofの色を入力し、favorites.txt:

blueorangegreendefinitely not yellow

ファイルをcolorsという新しいディレクトリに保存したとしましょう。 今から50年後には、あなたの好みが時間の経過とともにどのように変化したかを振り返って見るのは面白いでしょうから、お気に入りのカラーリストをバージョン管理下に置いてみたいと思います。これを行うには、ディレクトリを新しいCVSprojectとしてインポートする必要があります。 これはimportコマンドを使用して行うことができます:p>

$ cvs -d ~/sandbox import -m "" colors colors initialN colors/favorites.txtNo conflicts created by this import

ここでは、-dflagagainでリポジトリの場所を指定しています。 残りの引数はimportcolorsは、リポジトリ内の新しいディレクトリの名前を指定します。最後の2つの引数は、それぞれvendorタグとreleaseタグを指定します。タグについては、すぐに詳しく説明します。

あなたはちょうどあなたの”colors”プロジェクトをCVSリポジトリに引っ張ってきました。 CVSにコードを取り込む方法はいくつかありますが、これはPRAGMATICPROGRAMMERのCVSに関する本であるPragmaticversion Control UsingCVSによって推奨される方法です。 この方法を少し厄介にするのは、すでに存在するcolorsディレクトリを持っていても、あなたの仕事を新鮮にチェックアウト そのディレクトリを使用する代わりに、それを削除してから、CVSがすでに知っているバージョンをチェックします:これにより、colorsfavorites.txtCVSCVSディレクトリは、基本的にすべてのGitリポジトリ内の.gitディレクトリとCVSに相当します。

変更を行う

旅行の準備をしてください。Gitと同じように、CVSにはstatusサブコマンドがあります。

これは、物事が異質に見え始める場所です。 CVSにはcommitオブジェクトがありません。 上記では、”コミット識別子”と呼ばれるものがありますが、これは比較的最近の版である可能性があります—2003年に公開されたCVSを使用したpragmaticバージョン管理 Gitでは、commit45de392に関連付けられたファイルのバージョンについて話しますが、CVSファイルは別々にバージョン管理されています。 Yourfileの最初のバージョンはバージョン1.1、次のバージョンは1.2というようになります。 ブランチが含まれている場合、余分な数字が追加されるため、上記の1.1.1.1ようなものになる可能性があります。lotsofファイルとコミットを持つプロジェクトでcvs loggit logと同等）を実行すると、各ファイルの個々の履歴が表示されます。 同じプロジェクトにバージョン1.2のファイルとバージョン1.14のファイルがある可能性があります。p>

先に進んで、favorites.txt

 blue orange green+cyan definitely not yellow

cvs diffを実行して、CVSが何を考えているかを確認できます。

CVSは、”cyan”色を含む新しい行をファイルに追加したことを認識します。 （実際には、”RCS”ファイルに変更を加えたと言われていますが、cvsがRCSとの元の関連付けを完全にエスケープしたことはありません。 表示されている差分は、workingdirectoryのfavorites.txtのコピーとリポジトリに格納されている1.1.1.1バージョンの差分です。

リポジトリに格納されているバージョンを更新するには、変更をコミットする必要があります。 Gitでは、これは複数ステップのプロセスになります。 インデックスに表示されるように、変更を段階的に行う必要があります。 その後、我々は変更をコミットします。 最後に、変更を他の人に見えるようにするには、コミットをオリジンリポジトリにプッシュする必要があります。CVSでは、これらのことはすべて、cvs commitを実行すると発生します。 CVSは、見つけられるすべての変更をバンドルしてリポジトリに配置するだけです。

私はGitに慣れているので、これは恐ろしいものです。 ステージが変更される機会がなければ、作業中のdirectorymightで触れた古いものはすべて公開リポジトリの一部として終わります。 あなたは受動的に積極的に彼が知っていることを意図していない、カタルシスの必要性から、同僚の不十分な実装された機能を書きましたか？ あまりにも悪い、彼は今、あなたがディックだと思っています。 また、コミットはプッシュであるため、コミットをプッシュする前にコミットを編集することはできません。 あなたのlocalcommit履歴が数学的証明の導出のように流れるまで、40分を繰り返し実行することを楽しんでいますか？ 申し訳ありませんが、あなたはここでそれを行うことはできません、そして誰もがあなたが実際にあなたのテストを最初に書かないことを知るしかし、私は今、なぜ多くの人がGitを不必要に複雑に感じるのかを理解しています。

しかし、私は今も理解していますもしcvs commitあなたが慣れていたものであれば、ステージングとpushingchangesは無意味な雑用としてあなたを打つだろうと確信しています。人々がGitが”分散”システムであることについて話すとき、これは主に彼らが意味する違いです。 CVSでは、ローカルでコミットを行うことはできません。 コミットは中央リポジトリへのコードのサブミッションであるため、接続なしでできるものではありません。 ローカルに持っているのは、作業ディレクトリだけです。 Gitでは、本格的なローカルリポジトリを持っているので、切断しながら一日中コミットを行うことができます。 そして、他の誰も知らなくても、それらのコミットを編集したり、元に戻したり、ブランチしたり、cherry pickを好きなだけ選ぶことができます。

コミットはより大きな取引だったので、CVSユーザーは頻繁にそれらをまれにしました。コミットには、aten-commit pull requestで見られると予想される今日の変更が含まれています。 これは、コミットがCIbuildと自動化されたテストスイートをトリガーした場合に特に当てはまりました。

cvs statusを実行すると、ファイルの新しいバージョンがあることがわかります。

Merging

前述のように、CVSでは、他の誰かが既に編集しているファイルを編集することができます。 それはRCSのCVSの大きな改善でした。 あなたが一緒に戻ってあなたの変更をもたらす必要があるときはどうなりますか？

あなたが好きな色を追加するために何人かの友人を招待したとしましょうあなたのリスト。 彼らは彼らの色を追加している間、あなたはもはやあなたがいないことを決定します緑の色と同様に、リストから削除します。

変更をコミットすると、CVSがaproblemに気づくことがあります。

あなたの友人が最初に変更をコミットしたように見えます。 したがって、favorites.txtのバージョンは、リポジトリ内のバージョンと最新ではありません。 Youruncvs statusfavorites.txtのローカルコピーはversion1.2であり、いくつかのローカル変更がありますが、リポジトリバージョンは1.3です:1.2と1.3の違いを正確に確認するには、cvs diffを実行します。

私たちの友人は本当にピンクが好きなようです。 いずれにせよ、彼らは私たちが持っているよりもファイルの異なる部分を編集したので、変更はマージするのは簡単です。 CVScanは、cvs updategit pull:

$ cvs updatecvs update: Updating .RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.2retrieving revision 1.3Merging differences between 1.2 and 1.3 into favorites.txtM favorites.txt

今見てみるとfavorites.txt、あなたはそれがあなたの友人がファイルに加えた変更を含めるように変更されていることがわかります。 あなたの変化もまだそこにあります。 これで、ファイルを自由にコミットできます。

最終結果は、git pull --rebaseを実行してGitで取得するものです。 Yourchangesはあなたの友人の変更の上に追加されました。 「Mergecommit」はありません。”

場合によっては、同じファイルへの変更に互換性がない場合があります。 たとえば、あなたの友人が”green”を”olive”に変更した場合、それはyourchangeが”green”を完全に削除することと矛盾していました。 CVSの初期の頃は、これはまさにCVSが安全ではないことを人々に心配させたようなケースでした。; RCSのpessimistic錠はそのような場合が決して起こることができなかったことを保障した。 しかし、CVSguarantees誰の変更が自動的に上書きされることを確認することにより、安全性。 そのため、cvs updateを実行すると、GITがマージの競合を検出したときと同じように、CVSは両方の変更でファイルをマークアップします。 その後、ファイルを手動で編集し、保持したい変更を選択します。ここで注意すべき興味深い点は、コミットする前にマージの競合を修正する必要があることです。 これはCVSの集中化のもう一つの結果ですnature.In Gitでは、ローカルに持っているコミットをプッシュするまで、マージの解決について心配する必要はありません。

タグとブランチ

CVSには簡単にアドレス指定可能なコミットオブジェクトがないため、変更の収集をgroupaする唯一の方法は、特定の作業ディレタグを作成するのは簡単です。

$ cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt

後でcvs update-rフラグに渡すことで、ファイルをこの状態に戻:p>

$ cvs update -r VERSION_1_0cvs update: Updating .U favorites.txt

以前の作業ディレクトリの状態に巻き戻すためのタグが必要なため、CVSencouragesは多くのプリエンプティブタギングを提供します。 たとえば、メジャーリファクタの前に、BEFORE_REFACTOR_01タグを作成して、後でtherefactorが間違っていた場合に使用できます。 人々はまた、プロジェクト全体の差分を生成したい場合にタグを使用しました。 基本的には、commithashesで今日日常的に行うすべてのことは、すでに利用可能なタグを持っている必要があるため、CVSで予想および計画する必要があります。

ブランチはCVSで作成することができます。 ブランチは単なる特別な種類のタグです：

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

ブランチを作成するだけなので、cvs update:

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -j TRY_EXPERIMENTAL_THING