プロのアプリケーション開発者は、GITやSubversionなどのバージョン管理システムをどのように使用しますか？
私は初心者の開発者であり、プロジェクトのニーズを満たすために、GITやSubversionなどの専門的なツール（これらのツールについて十分に理解していない）をどのように使用するのか、最初から疑問に思っていました。もし彼らがそれを使うなら、私はそのようなものをどのように設定しますか？
私のアプリケーションはそれほど大きくなく、まだチームで作業していません。それらは私にとって非常に役立ちますか？
このサイトにはツールの使用方法に関する質問がありますが、初心者のサポートが必要です。
ソース管理はユビキタスです。使用しないと、自分をプロの開発者と呼ぶことができないとさえ言うかもしれません。単独で開発している場合でも、ソース管理には多くの利点があります。最終的には、履歴と広範な取り消しパスの両方が提供されます。また、新しいバージョンが気に入らない場合はいつでも以前のバージョンに戻すことができるという知識で、より多くの実験を行うことができます。
とはいえ、ワークフローは、SubversionやGitなどのソース管理システム内でも、チームごとに大きく異なります。開始するのに最適な場所は、おそらくソース管理システムを選択し、その標準ワークフローに精通することです（専門家のライフサイクル全体でワークフローを切り替える必要があることを頭に留めておきます）。
はじめに、Gitをお勧めします。私はGitのファンですが、より具体的にGit Getsを選択すると、サーバーレスで作業を開始して、意味のある場合にのみサーバーをセットアップできます。一方、Subversionはサーバーを必要とし、サーバーをセットアップすることは非常に困難ではありませんが、そのようなことをよく知らない場合は困難です。
一般的なソース管理の経験則の概要を次に示します。 http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx
自分で作業する場合、大量のワークフローは必要ありません。早い段階でコミットし、頻繁にコミットします。バージョンの公開を開始する場合は、リリースにタグを付けます。実験や長い分岐作業のためにブランチを作成します（Gitを使用すると、Subversionよりも安価で簡単になります）。
非常に単純なレベルのソース管理システム（SVN、Gitなど）により、ファイルの変更履歴を保持できます。これにより、コードが時間とともにどのように変更されたかを確認し、不要な変更をロールバックできます（たとえば、変更が期待どおりに機能しない場合、コードを以前の既知の状態に戻すことができます）。これは、自分で開発したとしても、使い始めると非常に貴重なものになります。
チーム内の他のユーザーと作業しているときは、複数のユーザーが同じファイルを変更できるため、利点がさらに増加し、変更が競合しない場合（2人がファイルの異なるセクションを変更するなど）、変更はマージされます自動的に。競合がある場合は、変更を同僚の隣に表示して、変更をマージする方法について彼らと話し合うことができます。
また、コードのバージョンをリリースするときにコードベース（通常はタグと呼ばれます）のスナップショットを作成して、メインソースがまだリリースされていない可能性のある新機能に移行しても問題を簡単にデバッグできるようにすることもできます。
いくつかの役立つリソースを以下に示します。
初心者向けチュートリアル
非常に基本的なレベルから始めるのに役立つ素晴らしいチュートリアル（ビデオとテキスト）があります。 Gitは トピックの紹介 に優れたアプローチをしているようですが、初心者には穏やかな方法で最初に理由を伝え、繰り返し、定義、グラフィックを使用して、キーコマンドの名前と機能を覚えやすくします。
[〜＃〜] svn [〜＃〜]
SVNはCVSをより良くすることを目的としています。 CVS（並行バージョンシステム）は一度にファイルの処理を行いましたが、SVNは通常、一度にディレクトリまたはディレクトリツリーの処理を行いました。 SVN（およびCVSまたは他のシステム）は、職場で使用している場合に重要になる可能性がありますが、私の考えでは、数年ごとにソース管理を行うために必要なことについての理解が大幅に向上するため、後期モデルを好みますコンピュータでは、最新のモデルソース管理ツールを選択する必要があります。システムを変更することは莫大な投資であり、コード履歴は失われる可能性がありますが、多くのシステムには、コードの移行を可能にするコンバーターや、廃止されたシステムによって作成された履歴やその他のアーティファクトがあります。
プロフェッショナルなソース管理がプロフェッショナルのニーズを満たします
「GITやSubversionなどの専門的なツールを使用して、プロジェクトのニーズをどのように満たすのですか？」 「チームは、可能な限り迅速に作業しながら、お互いの邪魔をせずにチームがどのように共同作業するのですか？」
他の開発者が使用するコードを作成する開発者や、さまざまなレベルの安定性と革新性を必要とするさまざまな利害関係者がいるため、コードは頻繁に変化しています。ソース管理システムは、チームが使用するコードを保存し、時間とともに変化するバージョンと、多くの場合、変更のグループを他の変更のグループから分離するのに役立つコードの制御されたコピーであるブランチとのコンテキストで、各変更を維持することで役立ちます。
物事を元に戻し、多くのチームメンバーの作業をマージすることは、SVNおよび以前のシステムでは一元化されていて困難であった面倒です。 Gitを使用するチームの場合、マージはより簡単になり、少数の専門家ではなくチーム全体の影響を受けやすくなります。 SVNでは、分岐は個人的な問題である可能性がありますが、マージはしばしばチームに苦痛な影響を与え、コードをメインラインに戻すことは、許可を取得し、破損を回避し、作業に必要なレベルの観点から、苦痛である可能性があります。
確立されたソース管理リポジトリから、専門家は根本原因に対する問題の診断など、他のニーズを満たすことができます。以前は機能していたコードのバージョンがあり、現在のバージョンで発生した問題が新たに見つかった場合は、履歴を前後に移動して、問題が発生した時点を特定することができます。 SVNでは、この機能は未成熟ですが、Gitでは、最後に動作する/最初に失敗したバージョンの検索は、git bisectというコマンドでサポートされています。この問題は、2つのバージョン間のソース変更の1つが原因で発生します。これは、コードベース全体を検索するよりもはるかに簡単に診断できる可能性があります。
混乱して申し訳ありません。これがソース管理の使用に役立つことを願っています。
私のチームは、自社開発のチームバージョン管理システムを使用しています。 （残念ながら、GitはまだIBM iの「ネイティブ」ソースファイルでは機能していないようです）しかし、個人的には、そのシステムからソースをプルしたら、プロジェクトが完了してチェックインするまで、開発中にGitを使用します。チームVCS。
彼らが投票で言うように...早くコミットし、頻繁にコミットします。新しい機能に取り組んでいるときは、コミットします。コンパイル間でコミットし、テストとデバッグ中に変更を加えるたびに、コンパイラエラーを修正しようとします。これにより、特に変更が複数のファイルにまたがって調整されている場合に、必要に応じて、テーマのさまざまなバリエーションを簡単に試すことができます。
Gitは私が開発に取り組む方法を改善しました。