バージョン管理を使用する必要があるのはなぜですか？
筆者がこれを言ったブログを読んでいた
「バージョン管理システムにチェックインしない限り、コードは存在しません。すべての作業にバージョン管理を使用します。バージョン管理、SVN、Git、CVSでさえ、マスターして使用します。」
私はこれまでにバージョン管理を使用したことはありませんし、それほど素晴らしいとは思いません。私はそれをグーグルで調べたことがありますが、喜んでそれを子供の条件に入れる必要があります。
私が今理解しているように、SVNのようなものは、ユーザーのグループや他の開発者が同じコードにアクセスできるようにオンラインでコードを保存するためのものです。いくつかのコードを更新したら、新しいバージョンを送信できます。SVNは古いコードと更新した新しいコードのコピーを保持します。
これは基本的な考え方ですか、それとも完全に間違っていますか？
私が正しければ、私が次の場合はあまり役に立たないかもしれません：
- 他の人がコードを操作しないでください。
- 他の人にコードを持たせるつもりはありません。
あなたは今までに持っていますか：
- コードに変更を加え、それが間違いであることに気付き、元に戻したいですか？
- コードを紛失したか、バックアップが古すぎましたか？
- 製品の複数のバージョンを維持する必要がありましたか？
- コードの2つ（またはそれ以上）のバージョンの違いを見たいですか？
- 特定の変更によりコードが破損または修正されたことを証明したいですか？
- いくつかのコードの履歴を確認したいですか？
- 他の人のコードに変更を送信したいですか？
- あなたのコードを共有したい、または他の人があなたのコードで作業できるようにしたいですか？
- どのくらいの作業が行われているか、どこで、いつ、誰によって見たいですか？
- 動作中のコードに干渉することなく新しい機能を試してみませんか？
これらの場合、そして間違いなく他の場合、バージョン管理システムはあなたの生活を楽にするはずです。
友人を誤って引用する：文明時代の文明化されたツール。
単独で作業している場合でも、ソース管理の恩恵を受けることができます。とりわけ、これらの理由から：
何も失うことはありません。コードを再びコメントアウトしたことはありません。削除するだけです。それは私の画面を乱雑にしません、そして、それは失われません。古いコミットをチェックアウトすることで回復できます。
自由に試すことができます。問題が解決しない場合は、元に戻します。
以前のバージョンのコードを見て、バグがいつどこで導入されたかを確認できます。
git bisectはその点で素晴らしいです。分岐やマージなどの「高度な」機能により、複数の並行開発ラインを使用できます。干渉することなく2つの機能を同時に使用でき、手間をかけずに切り替えることができます。
「変更点」を確認できます。これは基本的に聞こえるかもしれませんが、それは私自身がよくチェックしていることです。私は非常に頻繁に一人でワークフローを開始します：昨日は何をしましたか？
ただ試してみてください。基本的な機能からゆっくりと始め、他の人に習いながら学習してください。 VCSのない「暗黒時代」に戻りたくないことがすぐにわかるでしょう。
ローカルVCSが必要な場合は、独自のSubversionサーバーをセットアップできます（過去に行ったこと）が、今日はgitを使用することをお勧めします。はるかに簡単です。コードディレクトリにcdして、次を実行します。
git init
クラブへようこそ。
バージョン管理は、ソロ開発者としてのみ使用している場合でも、絶対に必要とされるまれなツールです。一部の人々は、それがあなたが生きて死ぬツールであると言います、私はその主張に同意します。
おそらく知らない場合でも、おそらく現在バージョン管理を使用しているでしょう。 「XXX Phpコード（12月）」または「XXX.php.bak.2」というフォルダがありますか？これらのareバージョン管理の形式はすでにあります。適切なバージョン管理システムがこれを自動的に処理します。 （データがチェックインされている）任意の時点にロールバックでき、そのデータの正確なコピーを表示できます。
さらに、Subversionのようなシステムを採用し、リモートリポジトリ（所有するサーバー上のリポジトリなど）を使用する場合、すべてのコードを保持する場所があります。他の場所にコードのコピーが必要ですか？問題ありません、チェックしてください。自宅でハードドライブがクラッシュしますか？問題ではありません（少なくともソースコードでは）。
現在バージョン管理を使用していない場合でも、キャリアのある時点でそれを使用する可能性が高いため、現在は原則に慣れることができます。
一人で働いても、これは起こったことがありますか？アプリを実行すると、何かが機能せず、「昨日は機能しましたが、そのクラス/メソッドには触れなかったと誓います」と言います。コードを定期的にチェックインしている場合、簡単なバージョンの差分により、最終日に何が変更されたかが正確に示されます。
単独で作業する場合でも、ソース管理の有用性を示すシナリオを次に示します。
クライアントは、Webサイトに野心的な変更を加えるように依頼します。数週間かかり、多くのページを編集する必要があります。仕事に取り掛かります。
クライアントが呼び出して、サイトに緊急ではあるがマイナーな変更を加えるためにあなたがしていることをやめるようにあなたに言うとき、あなたはこのタスクで50％完了しています。大きなタスクは完了していないため、稼働する準備ができておらず、クライアントは小さな変更を待つことができません。しかし彼はまた、大きな変更のためにマイナーな変更をあなたの作品にマージすることを望んでいます。
たぶん、あなたはウェブサイトのコピーを含む別のフォルダで大規模なタスクに取り組んでいます。ここで、小さな変更を迅速に展開できる方法で行う方法を理解する必要があります。あなたは猛烈に働き、それを成し遂げます。クライアントは、さらに洗練されたリクエストでコールバックします。これも実行して展開します。すべては順調です。
今、あなたはそれを大きな変化のために進行中の作業にマージしなければなりません。緊急の仕事のために何を変えましたか？メモをとるには作業が速すぎました。また、開始したベースラインに対する変更が両方にあるため、2つのディレクトリを簡単に比較することはできません。
上記のシナリオは、ソロで作業している場合でも、ソース管理が優れたツールになり得ることを示しています。
- ブランチを使用して長期のタスクを処理し、完了したらブランチをメインラインにマージして戻すことができます。
- ファイルのセット全体を他のブランチまたは過去のリビジョンと比較して、違いを確認できます。
- 時間の経過とともに作業を追跡できます（これは、レポートや請求書の発行に最適です）。
- 日付または定義したマイルストーンに基づいて、ファイルのリビジョンを回復できます。
ソロ作品には、SubversionまたはGitをお勧めします。誰でもどちらか一方を自由に使用できますが、バージョン管理を使用しないよりも明らかに優れています。良い本は、Mike Masonによる「 Subversionを使用した実用的なバージョン管理、第2版 」またはTravis Swicegoodによる「 Gitを使用した実用的なバージョン管理 」です。
原作者： ビル・カーウィン
単一の開発者ソース管理が大きな利点を提供しているとしても。コードの履歴を保存し、いつでもソフトウェアの以前のバージョンに戻すことができます。これにより、動作していたソースコードの別のバージョンにいつでも復元できるため、実験を行う際の柔軟性が大胆になります。
それは、コードの最初の行までさかのぼる巨大な「元に戻す」ボタンがあるようなものです。
バージョン管理は、使用を開始しないと生きていくことがほとんど不可能です。複数の開発者が同じコードベースで作業している場合、それは不可欠です...しかし、単一の開発者にとっても非常に便利です。
コードの変更を追跡し、以前のバージョンにロールバックできます。何かが壊れた場合、変更を取り消すことができるという知識を試すことができます。
セキュリティ（コードのバックアップがあるという意味で）とコードのバージョン管理を取得します（頻繁に変更をコミットする習慣があると仮定します）。誰もあなたと一緒にコードに取り組んでいない場合でも、両方とも非常に良いことです...
他の誰も明示的に言及していないと思われるものは、リリースのタグ付けまたはラベル付けです。ソフトウェアのバージョン1を使用しているクライアントがいて、バージョン2で作業している場合、クライアントがバグを報告し、バージョン1.1をビルドする必要がある場合はどうしますか？
ソース管理システムでは、作成したすべてのリリースにラベルを付けることができるため、後で戻って修正し（修正を新しいバージョン2コードにマージ）、誤って何かを誤って配信することを心配せずに新しいリリースを作成できます準備ができていません。
ソース管理は、最新のソフトウェア開発の中核部分です。使用していない場合（経験が多いほど良いので個人的なプロジェクトでも）、何か間違ったことをしていることになります。
通常、仕事のために面接を受けるときに私が尋ねる最初の質問の1つは、「ソース管理に何を使用していますか？」です。これまでのところ、「何もありません」と言った場所は1つだけでしたが、彼らはそれを修正する予定でした。
バージョン管理は、単独で作業している場合でも、以前のバージョンを確認するのに最適です。たとえば、誤ってコードまたはファイルを削除した場合、元に戻すことができます。または、以前のバージョンを比較して、新しいバグが侵入した理由を確認することもできます。複数の場所で作業している1人のユーザーにも役立ちます。
私のお気に入りはgitです。
あなたがコードに触れる唯一の人であっても、バージョン管理を使用する理由はいくつかあります。
- バックアップ-ハードドライブがクラッシュした場合はどうなりますか？どこかにコピーがありますか？
- 改訂履歴-現在、異なるフォルダーにコードのコピーを保持していますか？バージョン管理を使用すると、時間の経過に伴う変更を追跡し、ツールを使用して異なるリビジョンを簡単に比較したり、変更をマージ、ロールバックしたりすることができます。
- 分岐-いくつかの変更をテストし、まだ何をしているかを追跡し、それを維持してメインプロジェクトにマージするか、単に破棄するかを決定する機能。
コードをバージョン管理下に置いておくと、変更した（またはベースラインへの追加を忘れた）ファイルを簡単に確認できます。
他の開発者が参加するかどうかは、バージョン管理システムの必要性と完全に直交しています。
あなたは唯一の開発者になることができますが、それでも次の恩恵を受けます：
- すべての変更の履歴証跡
- その歴史を行き来する能力
- ソースを試して、まだ機能するバージョン（ブランチ）を使用して実験する能力
- バックアップコピー（特に、別のマシンをソース管理サーバーとして使用している場合、さらにそのマシンが定期的にバックアップされている場合はさらに）
今、同じコードベースで開発しているグループがある場合、バージョン管理がさらに必要です。
- 人々は同じファイルを同時に編集できます（特定のシステムによって異なりますが、ほとんどの健全なシステムではこれが可能です）
- あなたは誰がコードに何をしたのかを知ることができます
より多くの人が関与している場合、開発のスタイルに応じて、選択するバージョン管理ツールの関連性が高まります。
また、バージョン管理に興味を持ち始めたのはごく最近のことです。バージョン管理システムでは、コードにリポジトリの概念があります。豊富な新しいシェルコマンドが非常に迅速に学習されるため、このリポジトリを操作できます。
コードをファイルに保存したら、プロジェクトのリポジトリにcommitできます。コードを開発して変更をコミットすると、リポジトリは一連のrevisionsを開発します。これらのいずれかにアクセスするには、リビジョンをチェックアウトしてください。単独で作業する場合、コードファイルを失ったり、別のマシンで作業したい場合を除いて、多くのチェックアウトを行うことはほとんどありません。これらの場合、通常はすべてのファイルの最新リビジョンをチェックアウトします。
私自身のために、何かをリファクタリングすることにしたとき、「project_old」という名前のファイルまたはフォルダーを保持しなくなりました。行った変更はすべて増分的に保存され、全体として機能するプロジェクトに戻ることができます。 sshを使用してコードをチェックアウトするだけなので、FTPを使用して展開することはほとんどありません。変更したファイルのみがダウンロードされ、サーバーにリロードする必要がある場合、ターミナルはすでにそこにあります。
GITに関するこの講演は非常に有益であることがわかりました。 http://www.youtube.com/watch?v=4XpnKHJAok8
Linus Torvaldsが、あるバージョン管理システムを別のバージョン管理システムを使用することについて議論するGoogleトークです。そうすることで、彼は概念を使用してそれらがどのように機能するかを説明し、それらを実装するさまざまな方法を比較します。
古いファイルのバックアップについても、「Subversion」と呼ばれています。そのため、作業の複数のバージョンを管理できます。このバージョンでは、戻って（元に戻して）、異なる実装を管理して（分岐）できます。
あなたはあなたのプログラムの作業バージョンを持っていることに気付くかもしれません。
一定の期間にわたっていくつかの新しい機能を追加することにし、それをリリースします。
自分が触れていないと思ったコードに影響するバグレポートを取得し始めます。
たとえば、SVNを使用すると、古いバージョンに戻り、新しいバグが存在するかどうかを確認できます。バグを導入したバージョンを見つけたら、それを修正する方が簡単です。これは、機能したバージョンと機能しなかったバージョンを比較して変更点を確認できるため、検索が絞り込まれます。
あなたが唯一の開発者であっても、ソース管理には多くの用途があります。
もう少し軽量なものを探しているようですね。 Mercurialを確認してください（ awesome reference book ）。私は、ソースコードから個人的な通信まで、すべてにそれを使用します。
いくつかの利点：
- 巨大な[元に戻す]ボタン。コードが実際に実行されたときに先週のそれらのハルシオン日を返すことができます
- 使い捨てコード。これが何かをするための最良の方法であるかどうかわからない？ブランチを作成して実験します。 MercurialのようなDVCSを使用している場合、誰もそれについて知る必要はありません。
- 同期化された開発。私は4つの異なるコンピューターで開発しています。私はそれらの間を押したり引いたりして最新の状態を保ちます。
プログラムの古いバージョンが必要な状況にまだなっていない場合でも、ソース管理があると、大きな変更を行う自信が大きくなります。
ソース管理を使用した後、より積極的なリファクタリングを行っていることに気づきました。作業バージョンを簡単に復元できることが常にわかっていたからです。
自分で作業している場合でも、Subversionのようなものが必要になります。これにより、すべての変更の履歴を保持できます。昔々、コードがどのように見えるかを確認して、変更を加えた理由を覚えておくとよいでしょう。
ソース管理は、頻繁にチェックインするときにも役立ちます。頻繁にチェックインすると、常に頻繁にロールバックする状態になります。多くの場合、問題を解決するために1つのパスに進み、それが間違ったパスであることに気付くことができました。多くの場合、あなたはただ間違った道をたたき続け、ひどい解決策を構築することになります-あなたがすべての仕事を失いたくなかったからです。頻繁にチェックインすることで、「幸福」の最後のポイントは遠くないので、間違った道を進んだとしても、いつでもロールバックして再試行し、よりエレガントでシンプルなソリューションを作成できます。これは常に良いことなので、あなたが書いたものを将来理解し、維持することができます。
それは、プロジェクトの規模と、その部分についてどのくらいの頻度で考えを変えるかによって異なります。直線的に何かをしている小さなプロジェクトの場合、バージョン管理はおそらくあまり役に立ちません（ただし、バージョン管理なしで誤ってファイルを削除または破損した場合、泣きそうになります）。
しかし、数週間前、私は自分で巨大な趣味のプロジェクトを書いていた友人に会いました。彼は、コードのコピーを10個または20個持っていて、「X1」、「X2」、「test」、「faster」などの接尾辞が付いていました。
コードのコピーを3つ以上作成した場合、youneedバージョン管理。優れたバージョン管理システムを使用すると、少し前に行った変更を元に戻すことができます。特定の変更がいつ行われたかを確認できます。コードを2つの「パス」に分割し（たとえば、1つは新しいアイデアをテストするため、もう1つはテストが完了するまで「試行済みの信頼できる」コードを安全に保つため）、それらを結合します。