プロジェクトで作業しているのが私だけの場合、コードリポジトリを使用する必要がありますか？
重複の可能性：
独立した開発者のためのバージョン管理？
プロジェクトで作業しているのが私だけの場合は、コードリポジトリを使用する必要があるかどうかわかりません。
実際、コードリポジトリを使用しない理由はほとんどありません。以前のバージョンに簡単にロールバックできるという事実だけで、自動化されたテストにもかかわらず、誤ってリグレッションバグを導入した後、何度もリアエンドをカバーしてきました。
推奨事項が必要な場合-Mercurialを試してください。それは本当にシンプルですが、非常に強力です。不要な複雑さのため、Gitは避けます。もちろん、これは私の個人的な意見です。だからあなたに一番合ったものを選んでください。
さて、最近のソース管理の第3世代では、それらを特別に使用し始めることはそれほど難しくありません git または Mercurial 、私があなたが使用してはならない理由のマイナス面は考えられませんそれらのいずれか。
また、リモート環境を設定したくない場合は、 Github 、 bitbucket 、 CodeGoogle などのサイトを使用してソースを維持し、取得することができますいつでも好きなときに。
@Christianに同意しなければなりませんgitは実際には非常にシンプルで率直なソリューションであり、十分に文書化されており、非常に強力です。個人的には私はMercurialを数回、短期的に使用したので、それについて強い意見を持つことはできません。
TL; DR答えは「はい、Ja、Si、Oui！」です
私は会社で唯一の開発者です。私は現在生産中または可能性があるがいつか生産中のものにSVNを使用します。私がそれを使用する10の理由：
バックアップ。私のHDが失敗した場合、すべてのコードを失いたくない！
私が何かを完全に詰め込んだ場合に備えて、以前のバージョンのコードに簡単にロールバックできるようにします（大きなリファクタリングを行うときにも勇気を与えます）
チェックインするたびに単体テストを実行する継続的なビルドを簡単にセットアップできます
継続的ビルドは、社内の他の誰もが（またはテスト、UAT、またはデモ）を確認できるように、アプリケーションの「ステージング」バージョンも作成します。
上司（および私）が私が取り組んでいることを確認するための良い履歴を与えます
新しいプログラマーがオンボードに来るとき、私は簡単に彼らをコードに向けることができます
作業中の新機能を導入せずに緊急修正を展開する必要がある場合に備えて、コードの「現在の製品リリース」バージョンにタグを付けます。
複数のソリューションで共有されている再利用可能なコードライブラリの管理が簡単になります（私はC＃の世界にいます）
SVNの世界のすべてを最新の状態に保ちます（最新のTortoise SVNのバージョンでは、古くてクールなコミットを行うと、自動的に更新するように求められます）。自分で作業することの優れた点は、多くのことをテストするのがはるかに簡単になることです。他の人のためにコード/ビルド/テスト/フレームワークを壊すことを心配する必要はありません。
病気（または休日など）がうまくいかなくても、コードが私のマシンに行き詰まっていない場合、上司がSVNからコードを取り除くことができます。
また、私はスカムをコーディングするだけではなく、ソフトウェアエンジニアであることも思い出させてくれます。
コードリポジトリは履歴であり、履歴があっても害はありません。私はbashシェルスクリプトの〜/ binディレクトリで物事を誤解しており、リビジョン管理のおかげで私は救われました。リポジトリがバックアップされている限り、それを別の種類のソースコードバックアップとしても考えることができます。新しいLinuxプラットフォームに移行するときに、町の税収ソフトウェアをCVSから復元し、すべてをリポジトリからチェックアウトした後にビルドしました。
職場で使用しているのと同じソフトウェア、またはgitのようなより現代的なソフトウェアを使用します。
私はティムに同意します。はい、バージョン管理システムを使用する必要があります。しかし、私はサーバーをセットアップする必要がない単純なものを使用します。私はすべてのプロジェクトにGitを使用しています。たとえそれらがシンプルで小さいものであっても（最初は…）。 Gitリポジトリをセットアップするには、git initなので、とても簡単です。もちろん、これまでにGitを使用したことがない場合は、適切な選択ではないかもしれません…
間違いなく！純粋に、コードを以前のバージョンなどにロールバックできるという理由で。バージョン管理は価値があります。できることは「ctrl + z」だけです！
はい、小さなスクリプトよりも大きなものなら何でも。利点の1つは、元のコピーを消去したり、変更を元のコードベースにマージするのが非常に面倒だと判断したりすることを心配せずに、新しい設計とコードベースの強力なリファクタリングを先に進めることができることです。変更を反映する準備が整いました。
単一の開発者にとって、質問は「プロジェクトで作業しているのが私だけの場合、ソースコードのバックアップを取るべきか」という単純化です。たいと思うでしょう。
これと比較して追加の利点は淡いですが、とにかくそれらのいくつかは非常に有用であると思われるでしょう。利点は、プロセスのかなり後の段階で明らかになります。
2番目に便利な機能は、クリーンルーム環境で顧客に出荷するビットを構築する機能です。これにより、ビルドを確実に再現できるようになります。これは、後でメンテナンスする必要がある場合に非常に重要です。
VCSでコードを使用する利点は十分に文書化されています。回帰/ロールバックテスト、将来的に人を追加する機能、変更履歴のコメントなど。
ただし、数個のファイルのみで構成されるか、バージョン管理されたリリースが不要な非常に小さな「プロジェクト」の場合は、を使用して完全に最下位のバージョン管理を回避できる可能性があります。 [〜＃〜] rcs [〜＃〜]。 RCSは、CVSがもともと構築されたファイルごとのリビジョン管理システムです。あなたの目標が上記のメリットを得るだけであれば、RCSは中央リポジトリを必要とせずに実現しますOR急な学習曲線。
私はまだRCSを使用して、サーバー構成ファイルのリビジョン履歴、または特定の領域以外ではあまり使用されない個々のシェルスクリプトを維持しています。いくつかのファイルをまとめて「リリース」バージョンの何かにパッケージ化する必要が生じたら、RCSの限界を超えました。しかし、それはまだその場所を持っています。
私の0.02ドル。
私はこの船に乗っています。ソース管理を使用するだけでなく、すべてのソフトウェアを完全に別のボックスで構築しています。
これにより、私のマシンで作成されたすべてのソースコードが実際にソース管理にチェックインされていることが確認されます。さらに、すべての別のバックアップがあります。
別のマシンのコストはイギリスで約300ポンドなので、IMOはこれを行わないことを正当化できません。