プロのアプリケーション開発者は、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人がファイルの異なるセクションを変更する）、変更はマージされます。自動的に。競合がある場合は、変更を同僚の隣に表示して、変更をマージする方法について彼らと話し合うことができます。

また、コードのバージョンをリリースするときにコードベース（通常はタグと呼ばれます）のスナップショットを作成して、まだリリースされていない可能性のある新機能をメインソースに移したとしても、問題を簡単にデバッグできます。

いくつかの役立つリソースを次に示します。

Visual Studioと.NETでSubversionとTortoise SVNを起動して実行する

Subversionによるバージョン管理

初心者向けチュートリアル

非常に基本的なレベルから始めるのに役立つ素晴らしいチュートリアル（ビデオとテキスト）があります。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は私が開発に取り組む方法を改善しました。