バージョン管理を使用する必要があるのはなぜですか？[閉まっている]

私は作家がこれを言ったブログを読んでいました

「バージョン管理システムにチェックインしない限り、コードは存在しません。すべてのことに対してバージョン管理を使用してください。バージョン管理、SVN、Git、さらにはCVSも、それをマスターして使用してください。」

私はどのようなバージョン管理も使用したことがなく、それほど優れているとは思いません。私はそれをグーグルで見て、それを以前に見たことがありますが、喜んでそれが子供たちの条件に入れられる必要があるだけです。

私が今理解しているように、SVNのようなものは、ユーザーのグループや他の開発者が同じコードにアクセスできるようにコードをオンラインで保存するためのものです。コードを更新したら、新しいバージョンを送信すると、SVNは古いコードのコピーと更新した新しいコードのコピーを保持します。

これはそれの基本的な考えですか、それとも完全に間違っていますか？

私が正しければ、次のような場合にはあまり役に立たないかもしれません。

• 他の人にコードの作業をさせないでください。
• 他の人にコードを許可する予定はありません。

これまでに：

• コードを変更しましたが、それが間違いであり、元に戻したいと思っていましたか？
• コードを紛失したか、古すぎるバックアップがありましたか？
• 製品の複数のバージョンを維持する必要がありましたか？
• コードの2つ（またはそれ以上）のバージョンの違いを確認したいですか？
• 特定の変更によってコードが破損または修正されたことを証明したいですか？
• 一部のコードの履歴を確認したいですか？
• 他の誰かのコードに変更を送信したいですか？
• あなたのコードを共有したいですか、それとも他の人にあなたのコードで作業させたいですか？
• どのくらいの作業が行われているのか、どこで、いつ、誰によって行われたのか知りたいですか？
• 機能しているコードに干渉することなく、新しい機能を試してみませんか？

これらの場合、そして他のケースでは間違いなく、バージョン管理システムはあなたの人生をより簡単にするはずです。

友人を誤って引用するには：文明時代の文明化されたツール。

一人で作業している場合でも、ソース管理の恩恵を受けることができます。とりわけ、これらの理由により：

• 何も失うことはありません。コードをコメントアウトすることはもうありません。削除するだけです。画面が乱雑になることはなく、失われることもありません。古いコミットをチェックアウトすることで回復できます。

• 自由自在に実験できます。問題が解決しない場合は、元に戻します。

• 以前のバージョンのコードを調べて、バグがいつどこで発生したかを確認できます。git bisectその点で素晴​​らしいです。

• 分岐やマージなどのより「高度な」機能により、複数の並行開発ラインを利用できます。干渉することなく2つの機能を同時に使用でき、手間をかけずに前後に切り替えることができます。

• 「何が変わったのか」がわかります。これは基本的に聞こえるかもしれませんが、私は自分がよくチェックしているものです。私はよく自分のワークフローを次のように開始します。昨日何をしましたか？

先に進んで試してください。基本的な機能からゆっくり始めて、他の人を学びます。VCSの「暗黒時代」に戻りたくないことがすぐにわかります。

ローカルVCSが必要な場合は、独自のSubversionサーバーをセットアップできます（これまで私が行っていたものです）が、今日はを使用することをお勧めしgitます。はるかに簡単です。単にcdコードディレクトリに移動して実行します。

git init

クラブへようこそ。

バージョン管理は、単独の開発者としてのみ使用している場合でも、私が絶対に必要だと言っているまれなツールです。それはあなたが生きて死ぬ道具だと言う人もいますが、私はその主張に同意します。

あなたはそれを知らなくても、おそらくあなたはおそらく現在バージョン管理を使用しています。「XXX Phpコード（12月）」または「XXX.php.bak.2」と書かれたフォルダはありますか？これらはすでにバージョン管理の形式です。優れたバージョン管理システムがこれを自動的に処理します。（データをチェックインした）任意の時点にロールバックして、そのデータの正確なコピーを表示することができます。

さらに、subversionのようなシステムを採用し、リモートリポジトリ（所有するサーバー上のリポジトリなど）を使用する場合、すべてのコードを保持する場所があります。他の場所にコードのコピーが必要ですか？問題ありません。チェックしてください。自宅でハードドライブのクラッシュ？問題ではありません（少なくともソースコードに関しては）。

現在バージョン管理を使用していない場合でも、キャリアのある時点でバージョン管理を使用する可能性が高く、原則に慣れることができます。

一人で働いていても、これが起こったことがありますか？あなたはあなたのアプリを実行し、何かがうまくいかず、「昨日はうまくいきました、そして私はそのクラス/メソッドに触れなかったことを私は誓います」コードを定期的にチェックインしている場合、クイックバージョンdiffは、前日の変更内容を正確に表示します。

一人で作業している場合でも、ソース管理の有用性を示すシナリオを次に示します。

あなたのクライアントはあなたにウェブサイトに野心的な修正を実装するように頼みます。数週間かかりますが、多くのページの編集が必要です。仕事に取り掛かります。

クライアントが電話をかけ、サイトに緊急ではあるがより小さな変更を加えるために実行していることをやめるように指示したときに、このタスクは50％完了しています。大きなタスクは完了していないため、稼働する準備ができておらず、クライアントは小さな変更を待つことができません。しかし、彼はまた、マイナーな変更をあなたの仕事にマージして、より大きな変更を望んでいます。

多分あなたはウェブサイトのコピーを含んでいる別のフォルダーで大きな仕事に取り組んでいます。ここで、マイナーチェンジを迅速に展開できる方法で行う方法を理解する必要があります。あなたは猛烈に働き、それを成し遂げる。クライアントは、さらに絞り込み要求でコールバックします。あなたもこれを行い、それを展開します。すべては順調です。

今、あなたはそれを大きな変更のために進行中の作業にマージする必要があります。急務のために何を変えましたか？メモをとるには速すぎました。また、2つのディレクトリは、開始時のベースラインに対して相対的に変更されているため、簡単に比較することはできません。

上記のシナリオは、単独で作業している場合でも、ソース管理が優れたツールになることを示しています。

• ブランチを使用してより長期間のタスクを処理し、完了したらブランチをメインラインにマージして戻すことができます。
• ファイルのセット全体を他のブランチまたは過去のリビジョンと比較して、何が違うかを確認できます。
• 時間の経過とともに作業を追跡できます（ちなみに、レポートや請求に最適です）。
• 日付または定義したマイルストーンに基づいて、ファイルのリビジョンを回復できます。

単独作業には、SubversionまたはGitをお勧めします。だれでもどちらかを自由に選択できますが、バージョン管理を使用しないよりもどちらかが明らかに優れています。良い本は、Mike Masonによる「Pragmatic Version Control using Subversion、2nd Edition」またはTravis Swicegoodによる「Pragmatic Version Control Using Git」です。

原作者：ビル・カーウィン

単一の開発者ソースコントロールとしても大きなメリットがあります。コードの履歴を保存し、いつでもソフトウェアの以前のバージョンに戻すことができます。これにより、動作していたソースコードの別のバージョンにいつでも復元できるため、実験を恐れずに試すことができます。

それは、コードの最初の行に戻るまでの巨大な「元に戻す」ボタンを持っているようなものです。

バージョン管理は、それを使い始めた後でなければ、ほとんど不可能です。複数の開発者が同じコードベースで作業している場合は不可欠ですが、1人の開発者にとっても非常に役立ちます。

コードの変更を追跡し、以前のバージョンにロールバックできます。これにより、何かが壊れた場合に変更を元に戻すことができるという知識を試すことができます。

セキュリティ（コードのバックアップを作成するという意味で）とコードのバージョン管理（頻繁に変更をコミットする習慣を身に付けていると仮定した場合）が得られます。他の誰もあなたと一緒にコードに取り組んでしまうことがなくても、どちらも非常に良いことです...

バージョン管理は、単独で作業している場合でも、以前のバージョンをチェックするのに最適です。たとえば、コードやファイルを誤って削除してしまった場合、それを取り戻すことができます。または、以前のバージョンを比較して、新しいバグが侵入した理由を確認することもできます。1人が複数の場所で作業している場合にも役立ちます。

私の個人的なお気に入りはgitです。

あなたがコードに触れる唯一の人であっても、バージョン管理を使用する理由はいくつかあります。

• バックアップ -ハードドライブがクラッシュした場合はどうなりますか？あなたはどこかにコピーを持っていますか？
• 改訂履歴 -現在、コードのコピーを別のフォルダに保存していますか？バージョン管理を使用すると、時間の経過に伴う変更を追跡し、ツールを使用してさまざまなリビジョンの比較、変更のマージ、ロールバックなどを簡単に行うことができます。
• ブランチ -いくつかの変更をテストし、まだ何をしているかを追跡し、それを維持してメインプロジェクトにマージするか、単に破棄するかを決定する機能。

コードをバージョン管理下に置くと、変更した（またはベースラインに追加するのを忘れた）ファイルを簡単に確認できます。

他の誰も明示的に言及していないように見えるのは、リリースのタグ付けまたはラベル付けです。ソフトウェアのバージョン1を使用するクライアントがあり、バージョン2の作業で忙しい場合、クライアントがバグを報告し、バージョン1.1をビルドする必要がある場合はどうしますか？

ソース管理システムを使用すると、作成したすべてのリリースにラベルを付けて、後でそれに戻って修正を行い（その修正を新しいバージョン2のコードにマージして）、誤って何かを提供してしまうことを心配せずに新しいリリースを作成できます。準備ができていません。

ソース管理は、最新のソフトウェア開発の中核部分です。それを使用していない場合（個人的なプロジェクトでさえ、経験が多いほど良い）、何かがおかしいのです。

通常、面接を受けるときに最初に尋ねる質問の1つは、「ソース管理に何を使用しますか？」です。これまでのところ、「何もない」と言ったのは1か所だけですが、彼らは「今すぐにリアル」を修正する予定でした。

他の開発者が参加するかどうかは、バージョン管理システムの必要性に完全に直交しています。

あなたは唯一の開発者になることができますが、それでも次のメリットがあります。

• すべての変更の履歴証跡
• その歴史を行き来する能力
• ソースを試し、作業中のバージョン（ブランチ）を使用して実験する機能
• バックアップコピー（特に、ソース管理サーバーとして別のマシンを使用している場合、さらにそのマシンが定期的にバックアップされている場合はさらに多い）

同じコードベースのバージョン管理で開発しているグループがある場合は、さらに必要です。

• 人々は同じファイルを同時に編集することができます（特定のシステムに依存しますが、ほとんどの健全なものはこれを行うことができます）
• いつ誰がコードに対して何をしたかを知ることができます

関係する人が増えると、開発のスタイルに応じて、どのバージョン管理ツールを選択するかがより適切になります。

古いファイルをバックアップすることも、「Subversion」と呼ばれる理由です。そのため、作業の複数のバージョンを管理して、戻る（元に戻す）ことや、その実装（分岐）を管理することができます。

プログラムのバージョンが動作していることに気付くかもしれません。

一定期間にわたっていくつかの新機能を追加することを決定し、それをリリースします。

触れなかったと思われる一部のコードに影響を与えるバグレポートの取得を開始します。

たとえば、SVNを使用すると、古いバージョンに戻って、新しいバグが存在するかどうかを確認できます。バグが発生したバージョンを見つけたら、機能したバージョンと機能しなかったバージョンを比較して変更点を確認できるため、修正が簡単になります。その後、検索が絞り込まれます。

あなたが唯一の開発者であっても、ソース管理には多くの用途があります。

もう少し軽量なものを探しているようですね。Mercurial（素晴らしい参考書）をチェックしてください。私は、ソースコードから個人的なやり取りまで、すべてに使用します。

いくつかの利点：

• 巨大な[元に戻す]ボタン。コードが実際に実行された、先週のこれらの平日を返すことができます。
• 使い捨てコード。これが何かを行うための最良の方法であるかどうかわかりませんか？ブランチを作成して実験します。MercurialのようなDVCSを使用している場合は、誰もがそれについて知る必要はありません。
• 同期化された開発。4つの異なるコンピューターで開発しています。私はそれらの間を押したり引いたりして最新の状態を維持しているので、どちらにいても最新バージョンを入手できます。

まだプログラムの古いバージョンが必要な状況になっていない場合でも、ソース管理があれば、大きな変更を加える自信が高まります。

ソースコントロールを使用した後は、作業中のバージョンを簡単に復元できることを常に知っていたので、より積極的なリファクタリングを行っていました。

つい最近、バージョン管理に興味を持ち始めました。バージョン管理システムには、コードのリポジトリという概念があります。このリポジトリを操作できるように、豊富な新しいシェルコマンドがすぐに学習されます。

コードをファイルに保存したら、これをプロジェクトのリポジトリにコミットできます。コードを開発して変更をコミットすると、リポジトリは一連のリビジョンを作成します。リビジョンをチェックアウトすると、これらのいずれにもアクセスできます。単独で作業する場合、コードファイルを失ったり、別のマシンで作業したりしない限り、多くのチェックアウトを行うことはまずありません。これらの場合、通常はすべてのファイルの最新リビジョンをチェックアウトします。

私自身は、リファクタリングをするときに「project_old」という名前のファイルやフォルダを保持しなくなりました。加えた変更は段階的に保存され、全体として機能したプロジェクトにいつでも戻ることができます。sshを介してコードをチェックアウトするだけなので、FTPを使用して展開することはほとんどありません。変更したファイルのみがダウンロードされ、サーバーにリロードする必要がある場合、ターミナルはすでにそこにあります。

GITに関するこの講演は非常に有益であることがわかりました。http://www.youtube.com/watch?v=4XpnKHJAok8

それは、Linus Torvaldsが1つのバージョン管理システムを別のバージョン管理システムの上で使用することについて議論するGoogleトークです。そうすることで、彼は概念を使用してそれらがどのように機能するかを説明し、次にそれらを実装するさまざまな方法を比較します。

自分で作業していて、すべての変更の履歴がある場合でも、おそらくsubversionのようなものが必要になります。変更を加えた理由を思い出すために、たまにコードの一部がどのように見えるかを確認したい場合があります。

頻繁にチェックインする場合も、ソース管理があると便利です。頻繁にチェックインすると、常に頻繁にロールバックできる状態になります。多くの場合、問題を解決するために1つのパスをたどり始めて、それが間違ったパスであることに気づくことができました。多くの場合、すべての作業を失いたくないという理由だけで、間違った道を進み続け、ひどい解決策を構築してしまう可能性があります。頻繁にチェックインすることで、「幸福」の最後のポイントは遠くないので、間違った道を進んでも常にロールバックして再試行し、よりエレガントでシンプルなソリューションを作成できます。これは常に良いことなので、将来書いた内容を理解して維持することができます。

それは、プロジェクトの規模と、プロジェクトの一部について考えを変える頻度によって異なります。直線的に何かを実行しているだけの小さなプロジェクトの場合、バージョン管理はおそらくあまり役​​に立ちません（ただし、バージョン管理なしでファイルを誤って削除または破損すると、泣きます）。

しかし、数週間前に、自分で巨大な趣味のプロジェクトを書いている友人に会いました。彼には、「X1」、「X2」、「test」、「faster」などのサフィックスが付いたコードのコピーが10つか20ありました。

コードのコピーを3つ以上作成した場合は、バージョン管理が必要です。優れたバージョン管理システムを使用すると、以前に行った変更を取り消すことができます。変更後に行った変更を取り消す必要はありません。特定の変更がいつ行われたかを確認できます。これにより、コードを2つの「パス」に分割し（1つは新しいアイデアをテストするためのパス、もう1つは「終了して信頼できる」コードをテストが完了するまで安全に保つため）、それらをマージして戻します。

2019年です。この比較的遅い日付で、Gitを使用することに異論があります。異議ありここでいくつかの提起が見られます。この説明では、名前付きのバックアップコピーを単に作成するのではなく、ソース管理を使用する必要性が大幅に明らかになりました。1つの重要な点は、単一の開発者プロジェクトがある場合でもソース管理を使用することです。誰も完璧ではありません。あなたは間違いを犯します。あなたが並外れて優秀で賢いなら、もっと複雑なアプリを開発することになるでしょう。しかし、あなたはまだいくつかの間違いをするつもりであり、これはそれを処理します。ああ、ピート！私はLinuxを使用したことはありませんが、私たちは皆、Linus Torvaldsの優れた技術的知性を尊重していると思います。彼はソース管理の重要性を認識し、Gitの開始に重要な貢献をしました。これは、ここで説明するすべての理由の要約です。Torvaldsはそれを理解しています：ソース管理は非常に重要です：ソース管理を使用します。この長期にわたるトピックについてコメントしてくれたすべての人に感謝します。