version-control - チームがソース管理を採用する必要があるのはなぜですか？

Question

会社に利益をもたらすものについて上司に正式なプレゼンテーションを行う機会があります。私の考えは、職場でソース管理を採用することです。私は仕事で自分のプロジェクトを管理するためにMercurialを使用していますが、チームの他のメンバーは正式なソース管理システムを導入していません。残念ながら、私はアイデアを提示するのが苦手です。

では、開発者がソース管理を使用しなければならない理由を教えていただけますか？さらに、なぜVisual SourceSafe以外のツールを選択するのですか？私はVSSを使用した経験がありませんが、なぜMicrosoftのツールを使用しないのかと彼は尋ねるでしょう。

ここにいる多くの賢いプログラマーからの意見を聞きたいです！私の好みのオプションはSVNまたはMercurialです。どちらもWindowsバージョンを適切にサポートしているようで、どちらもCVSよりも古風ではありません。また、自己宣言したオープンソースの弟子として、私はオープンソースツールを提案したいと思います。:)

ありがとうございました！

編集：簡単に言うと、一般的に、他の開発者の現在の慣行は、フォルダをコピーし、日付をタグ付けし、おそらく自分で記録することです。あなたは絵を手に入れます。上司が「うまくいったら、なぜ修正するのか」と言ったらどうしますか？

score 66 · Accepted Answer

ソース管理を使用する開発環境と使用しない開発環境の 2 つの例を比較してみましょう。

A: 使用します
B:使用しない

シナリオ 1: プロジェクトが要求され、完了し、展開される

A + B) プログラマーはプロジェクトを社内で開発し、完成したらテストにプッシュしてから、クライアント (誰であれ) に納品します。

全体像としては、それほど違いはありません

シナリオ 2: プロジェクトがリリースされた後、クライアントが機能 X を必要としないと判断した場合

A + B) 開発者は、クライアントが望まないコードを削除し、テストして配信します。

繰り返しますが、大きな違いはありません。

シナリオ 3: 2 週間後、クライアントは機能 X が実際に必要であると判断した

A) 開発者は、2 で取り出したコードを通常の開発ツリーに再統合し、テストして納品します。

B) 開発者は、個人のマシン、ファイルサーバー、およびバックアップで古いコードを検索します。コードが見つかった場合は、各ファイルを手動で再挿入する必要があります。そうでない場合は、おそらくその機能全体を再コーディングする必要があります。

なんらかの理由で取り出した古いコードを簡単に取得できます

シナリオ 4: システムに奇妙なバグがあり、関数はブール値の結果を返すはずなのに、常に false を返します。2週間前はそうではなかった。

A) 開発者はソフトウェアのすべての古いバージョンを調べ、return false ディレクティブが適切なスコープ内にないことを突き止めます。ループの外側ではなくループの内側で実行されています。

B) 開発者は、問題が何であるかを把握するために何週間も費やします。最終的に、彼らは間違った行に戻っていることに気付き、それを修正します。ソース管理がないということは、実行されたファイルが動作していたときと現在の違いを見つけるのではなく、実行されたすべてのファイルを調べる必要があることを意味します。

シナリオ 5: 誰かがビルドを中断します。テストを通過し、数週間後にのみ通知されます。

A) チームはコミット履歴を調べ、誰がビルドを壊したかを突き止め、その人に修正させ、チームディナーを購入します。

B) チームはエラーを見つけるためにプロジェクト全体を遡る必要がありますが、誰がそのコードを挿入したのか特定できません。開発者は互いに非難し合い、チームの力は失敗します。

誰が、いつ、何を、なぜコミットしたのかを簡単に確認できます。

score 25 · Accepted Answer

あなたもあなたのチームも完璧ではないので、ソース管理を使用してください。ソース管理の主な機能は、開発プロセスの完全な履歴記録があることを確認することです。この記録があれば、実験が失敗した場合に以前のバージョンにバックアップできることを知って、自信を持って「実験的」バージョンに分岐することができます。

さらに、svnのような優れたソース管理システムにより、複数の開発者が同じファイルで作業できるようになり、それぞれがもたらす違いを調整するための強力なツールが提供されます。

score 18 · Accepted Answer

単純に-コードの本当の履歴があります-変更（バグの理由）を調査し、バージョンに戻し、監査します。バックアップだけでは不十分です-現在の画像のコピーを持っているだけです。ファイルを変更して、自分が何をしたかを思い出せたらいいのにと思ったことはありませんか？

score 15 · Accepted Answer

これらの理由でソース管理を使用する必要があります

1）任意のバージョンにロールバックできます

2）異なる開発者が同じファイルで作業できます

3）すべての開発者は、同じコードベースにアクセスできます

4）変更を追跡できます

5）機能しない変更をロールバックできます

6）ソース管理は継続的インテグレーションの基礎であり、TDDに大いに役立ちます

7）ソース管理を使用しない場合、ファイルが失われたり上書きされたりして、正常に機能しないため、ゆっくりと怒ります。

VSSは最悪のSCCアプリケーションではありません。私は何年も使用し、それを嫌うようになりましたが、機能し、シンプルで、多くの人が知っています。

score 9 · Accepted Answer

簡単な実際の例を次に示します。

数年前、私の上司は、「機能 XYZ は以前は機能していましたが、現在は機能していません。何が起こったのか誰も知りません。修正できますか?」と言いました。

これまで機能 XYZ を扱ったことはありませんでした。したがって、それを修正するには、それが何をするのかを理解しようとする多くの苦労が必要です.

しかし、ソース管理があります。だから私はこれを行います：

機能 XYZ をテストするテストスクリプトを作成します。
現在のバージョンを取得します。建てる。テスト。機能 XYZ が破損しています。
1 週間前のバージョンを取得します。建てる。テスト。機能 XYZ が機能します。
これら 2 つの中間のバージョンを取得します。建てる。テスト。機能 XYZ が機能します。
以前のバージョンと現在のバージョンの中間のバージョンを取得します。建てる。テスト。機能 XYZ が破損しています。

最終的に変更点に到達するまで、このバイナリ検索を続けました。バージョン 145 (言うことにします) では機能が機能していましたが、バージョン 146 では機能が機能していませんでした。次に、これら 2 つのバージョンを比較して、何が変わったのかを確認しました。私たちのテクニカルリーダー (ため息) が、機能を変更するコードをチェックインしていたことが判明しましたが、機能 XYZ を壊す副作用ももたらしました。

そこで、副作用を取り除き、テストしたところ、見よ、機能 XYZ が再び機能しました。

ソース管理がなければ、これを行うことはできません。機能 XYZ を再び機能させるものに魔法のようにヒットすることを期待して、何かを変更しながら、あわてて動き回る必要があります。

ソース管理では、バージョンをテストして、問題の原因となった正確なコードを特定し、修正するだけです。

score 8 · Accepted Answer

Microsoft（MSDN）には、ソース管理の利点に関する優れた記事があります。
http://msdn.microsoft.com/en-us/library/ms173539.aspx

賛否両論に関して、ここSOについてもたくさんの良い質問があります。
使用した後のgitの長所と短所は何ですか？

Subversionは非常に人気がありますが、Gitはソース管理の世界で「次の大きなもの」になるでしょう。

score 8 · Accepted Answer

ほとんどの人がソース管理の主要な機能について説明しているように思えますが、最大の利点の 1 つは省略されています。これらは：

支店

ソースコードリポジトリがなければ、特定の目的のためにコードのブランチ (またはコピー/ストリームなど) を作成することはできません。ブランチを作成およびマージできないことは、VSS が実際のソースコード管理システムである資格を失う最大の要因の 1 つです。ブランチの目的には次のようなものがあります。

バグ修正

バグを解決し、コードのメインラインまたはトランクバージョンから離れた場所でそれを行う必要がある場合があります。これは、テスト環境での問題を解決するためか、さまざまな理由である可能性があります。バージョン管理ツールがあれば、新しいブランチ (VSS が苦手なもの) を簡単に作成してバグを修正し、必要に応じてそれをメインラインコードにマージすることができるはずです。

メンテナンスリリース

これはバグ修正とほぼ同じですが、コードが本番環境にリリースされた後に行われます。例としては、フィックスパック、サービスリリースなどがあります。ここでも、必要に応じて変更をトランクにマージできるようにする必要があります。

新機能

現在のコードを維持しながら、新しいバージョンの開発を開始する必要がある場合があります。たとえば、v1.0 をリリースして維持しているが、v1.0 を維持しながら v2.0 の作業を開始する必要があるとします。ブランチはこの状況を解決するのに役立ちます

タグ付け/ラベリング

ソースコード管理システムが行うもう 1 つのことは、特定の時点でのソースコードのスナップショットを作成することです。これらは、VSS ではラベル、subversion ではタグなどと呼ばれます。これらを定期的に作成し、プロジェクトの重要なマイルストーンにリンクすることで、リリース間でコードの何が変更されたかを正確に判断できるようになります。これは、監査人にとって重要な場合がありますが、問題の原因/範囲を追跡する場合にも重要です。VSS はディレクトリではなくファイルのみをバージョン管理するため、ここでも VSS は失敗します。これは、リポジトリ内のファイルまたはディレクトリの名前を変更/移動/削除した場合、システムの以前のバージョンを再作成することが不可能であることを意味します (リファクタリングするとよく発生することです)。Subversion のような優れたソースコード管理システムは、まさにこれを行います。

score 6 · Accepted Answer

SVNを使用することをお勧めします。理由は次のとおりです。

ソース管理はあなたに素晴らしい歴史を与えます。どこで変更が加えられたかを確認できるため、時間の経過とともに何が変更されたかを確認するための優れた方法が提供されます（毎回送信の概要を入力するとさらに便利です）
開発者にとって、何かがひどくうまくいかない場合、それは優れたフォールバックを提供します。ファイルへの変更を履歴内の任意の時点に戻すことができるため、作成したいmodを試してみて、機能しない場合は簡単にロールバックできます。
さまざまな開発者のコンピューターに実行するよりもはるかに簡単にバックアップできる中央リポジトリを提供します。
これにより、プロジェクトを別の方向に分岐させることができます。これは、特殊化やカスタマイズに役立ちます。
1つの中央コピーへの変更をマージまたは操作できるようにすることで、複数の開発者が同じプロジェクトおよび同じソースで共同作業できるようにします。

VSSを使用しないことをお勧めします-理由については、次のページを参照してください： http ://www.highprogrammer.com/alan/windev/sourcesafe.htmlその他の理由について。

score 5 · Accepted Answer

いくつかのバージョン管理システムがあると、多くの場合に役立ちます。

単一の開発者、単一のブランチ

各バージョン管理システムがそれ自体をバージョン管理と呼びたい場合に完全に実行しなければならない最も基本的なタスクは、プロジェクトの指定されたバージョンに戻ることができるようにすることです。あなたが物事を台無しにしたならば、あなたは前のバージョンに行くことができます。以前のバージョンを調べて、それがどのように行われたかを確認できます（たとえば、リファクタリング前、またはコード/ファイルを削除する前の状態）。

バージョン管理システムは、デルタ化（以前のバージョンとの違いのみを保存）と圧縮を使用するため、指定した日付でバックアップコピーを保存する場合に比べて、ディスク容量を大幅に削減できます。通常、バックアップシステムは、プロジェクトの最後のNバージョンを保存する手段であり、バージョン管理システム（VCS）がプロジェクトのすべての履歴を保存している間、N = 1（以前のバージョンのみ）の場合もあります。N番目の最後のバージョンを削除してからしばらくの間マーフィーを知っていると、それが調べたいバージョンであることがわかります。

さらに、いくつかの最後のバージョンに戻るのは簡単で自動化されています。また、過去のバージョンで1つのファイルがどのように表示されたかを調べたり、現在の状態と過去のバージョンの違いを（diff形式で）取得したりすることもできます。バージョンにタグを付ける（または「ラベルを付ける」）こともできるので、日付だけでなく、現在のバージョンからn番目のバージョンであるだけでなく、たとえばv1.2またはの記号名でも過去のバージョンを参照できますv1.2-rc0。
バージョン管理システムを使用すると、履歴を調べて、コードの一部（特定のファイルの一部）が現在の状態に到達した理由（および方法）を思い出させることができます。annotateほとんどのVCSでは、ファイルの行ごとの履歴を調べることができます。つまり、ファイルが変更されたとき、どのコミットで、誰によって（コマンドの名前は、blameまたはpraiseVCSに応じて）ファイルの各行に注釈を付けます。一部のVCSでは、特定のコードフラグメントを導入したバージョン（リビジョン）の履歴を検索できます（たとえば、VCSの1つであるGitでは「pickaxesearch」と呼ばれます）。

この機能が本当に役立つためには、ある程度の規律を維持する必要があります。変更が行われた理由を書き留めて、新しいバージョン（新しいリビジョン/新しいコミット）ごとに説明する必要があります。このような説明（コミットメッセージ）は非常に便利ですが、バックアップシステムでは自然な位置を占めていません。

もちろん、この機能は、開発者があなただけではない場合にさらに役立ちます...
バージョン管理システムを使用すると、コード内のバグを見つける別の方法が可能になります。つまり、履歴を検索して、バグを引き起こしたバージョンを見つけることができます：bisectionghistory。バグを導入したリビジョンを見つけた場合、バグを検索する領域は限られています（最良の場合：非常に限られています）。これは、バグが最後の動作バージョンとバグのある最初のバージョンの違いにある必要があるためです。また、何をしたいのかを思い出させるために、変更の説明（コミットメッセージ）があります。この機能は、 diffデバッグとも呼ばれます。最新のバージョン管理システム（VCS）は、自動化をサポートしています（または半自動化された）履歴を二等分して検索（履歴を半分に分割し、バグが含まれている部分を見つけ、単一の責任のあるバージョンが見つかるまで繰り返します）、bisect（または同様の）コマンドの形式で。

この機能が本当に役立つためには、ある程度の規律を維持する必要があります。以前のバージョンとのわずかな違いだけで、1つの機能のみを処理し、単一の変更をコミットする（変更を保存する/バージョン管理システムに特定の状態を保持する）必要があります。つまり、頻繁にコミットします。
ほとんどのバージョン管理システムは、自動テストや製品の自動構築などを可能にするさまざまなフックを提供します...または単にコーディング標準（コーディングガイドライン）に準拠していないことを思い出させます。

単一の開発者、複数のブランチ

バージョン管理システムでは、ブランチ（またはストリーム、またはビュー）と呼ばれる複数の代替の並列開発ラインを作成できます。一般的なケースは、開発ブランチを持つことです。つまり、不安定な開発（新機能をテストするため）用の個別のブランチ、現在動作しているバージョンである（またはそうあるべき）安定した（メイン、トランク）バージョン用の個別のブランチ、およびより個別のメンテナンス（修正）用の個別のブランチがあります。）ブランチ。

メンテナンスブランチがあると、新しい開発からの干渉を心配することなく、バグ修正を行ったり、リリースされたバージョンを修正したサービスパック/マイナーバージョンを生成したりできます。後で、メンテナンスブランチを安定版にマージするか、メンテナンスブランチから安定版ブランチと開発ブランチにbigfixを選択できます（さらに/他の開発でバグが個別に修正されなかった場合）。
最新のVCS（ここでは最新とは、ブランチの分岐とマージの両方が簡単であることを意味します）により、もう少し先に進むことができます。つまり、個別の機能（いわゆるトピックブランチ）で作業するための個別のブランチを生成できます。これにより、ある機能の動作を別の機能の動作に切り替えることができます（また、新機能の開発から緊急に要求されたバグ修正の動作に切り替えるだけではありません）。
他の（通常はサードパーティの）製品のソースに基づいて製品を開発している場合は、ベンダーのブランチを使用して、ベンダーからの製品の新しいバージョンを行った変更と簡単に統合できるようにする必要があります。確かに、これはもはや純粋に「単一の開発者」の場合ではありません。

複数の開発者

同じプロジェクトで複数の開発者が作業している場合、バージョン管理システムを使用するとさらに利点があります。VCSは、誰かがあなたの変更を上書きしたり、あなたの変更を考慮に入れなかったりすることを心配することなく、同時（並列）開発を可能にします。もちろん、バージョン管理システムを使用することは、コミュニケーションに代わるものではありません。
上記のすべての機能は、複数の開発者の場合にさらに重要です。特定の変更を生成したのは誰か、コードを最後に変更したのは誰か（つまり、ビルドを壊したのは誰か）を調べ、自分だけではないコードのバグを見つけます。

score 4 · Accepted Answer

どうして絶対にソース管理が必要なのかについての長い議論：

小規模な開発グループ（1〜2人のプログラマー）にはバージョン管理が必要ですか？

そのスレッドからの私のコメント：

自分でプロジェクトに取り組んでいる場合でも、常に何らかのソース管理が必要です。

変更の履歴を持つことは、いつでもコードベースの状態を確認できるようにするために不可欠です。プロジェクトの履歴を振り返る理由はさまざまです。悪い変更をロールバックできることから、顧客が新しいバージョンにアップグレードするのではなく、パッチでバグを修正したい場合に古いリリースのサポートを提供することまで、さまざまな理由があります。ソフトウェア。

ある種のソース管理がないことは、純粋な狂気です。

VSSに関する限り、何もないよりは確かに優れています。それは間違いなく最高のソース管理ではなく、非常に古いものですが、それがそこにある非常に多くの企業のために仕事を続けているという事実。

上司がMicrosoftツールを使い続けることに決めた場合は、VSSではなくTeamFoundationServerを選択してください。これはVSSよりもはるかに優れたシステムであり、統合されたバグ追跡などの優れた機能を備えています。

score 4 · Accepted Answer

シンプル：コードがソースセーフにない場合、コードは存在しません

Subversionは無料で、VSSよりも優れていますが、VSSは間違いなく優れています。

score 4 · Accepted Answer

何かを言う前に、会社がソース管理を使用していない理由を調べてください。

理由がわかれば、ソース管理が役立つシナリオを思いつくのは簡単です。

score 3 · Accepted Answer

では、開発者がソース管理を使用しなければならない理由を教えていただけますか?

チーム全体が使用できる 1 つの方法を提供します。誰もが同じ「基本ルール」の下で行動します。
変更は無秩序ではなく整然としているため、開発時間を節約できます。
変更を追跡する機能により、説明責任が促進され、維持されている資料の問題を解決する適切な人物を簡単に見つけることができます。
行われた正確な変更のリストを迅速かつ簡単に生成できるため、バージョンごとにどのように変更されたかについての情報をユーザーに簡単に通知できます。
変更中に重大なミスがあった場合、以前のバージョンの情報に「ロールバック」するのは簡単です。

ソース管理は保険のようなものです! あなたはそれを必要としないことを願っていますが、必要になったときにそれを持っていることをうれしく思います!

score 3 · Accepted Answer

私からそれを取ってください、VSS が吹きます。これは、履歴付きの基本的なファイルストレージです。何でも VSS より優れており、VSS は何もないよりは優れています :)

score 2 · Accepted Answer

なぜなら：

コストが削減されます - 開発者は、現在のアドホックなアプローチよりも、実際の VCS でアイテムをチェックイン/チェックアウトするのに費やす時間が少なくて済みます。
これは、組織の知的財産を保護します。これは、ソフトウェア会社にとって最も重要な考慮事項です (データ以外...)。あなたはソフトウェアを作成するために支払われます - それは完全にアクセス可能であるべきではありませんか?
これにより、より迅速で信頼性が高く、簡単なバックアップメカニズムが提供されます。すべての VCS にはダンプ機能が組み込まれています。これらは、単純なファイルコピーよりも成熟している傾向があります。
これは開発者間の通信メカニズムとして機能します。バージョン管理システムによっては、コメント/ラベル/チェックアウトステータスを使用して、他の誰かがファイルで作業したかどうか、本番環境に昇格したかどうか、対応するサポートがあるかどうかを判断できます。チケット番号など
開発を合理化します。ファイルのバージョンやその他のメカニズムを比較する機能は、会社にとって有益です。

score 2 · Accepted Answer

本当に申し訳ありませんが、実際に開発環境でのソース管理 (の形式化) を主張しなければならないのであれば、絶望的な状況です。あなたの上司が、ソース管理が価値のある取り組みであると実際に確信する必要がある場合、あなたの上司は、ソフトウェア開発者グループのマネージャーになるにはふさわしくありません。誰かが効果的に管理するためには、少なくともランドスケープの基本的な理解が本当に必要です。議論してプレゼンテーションを行う価値のある何かについて実際に議論する必要があるときに、何が起こるか想像さえできません.

ソース管理なしで開発することは、休憩なしで車を運転するようなものです。シームレスな並行開発を行う能力を失い、コードを作業コピーにバックアップする能力を失い、コード注釈を介して歴史的な調査を行う能力を失い、個別の変更に伴うコンテキストとコメントを確認する利点を失います。失う、ピリオド。ソース管理を使用することは非常に明白であり、非常に多くの利点があるため、それを正当化する必要があるとは衝撃的です。

職場では subversion を使用していますが、一部の開発者 (私自身を含む) は git-svn ブリッジを介して Git をローカルで使用しています。個人的な仕事では、Git を使用します。

score 2 · Accepted Answer

あなたのチームがソース管理を採用すべきではないのはなぜですか?

個人の開発者でも、ソース管理を使用しています。現代のソフトウェア開発環境では、ソース管理を使用しない理由はほとんどないと思います。あなたがまだそれを持っていないことはもっと驚くべきことです。この質問は、家の塗装工が「なぜはしごを使用する必要があるのか。ご存知のように、はしごで家を塗装するのではなく、刷毛で塗装するのです」と尋ねるようなものだと私は思います。

score 2 · Accepted Answer

なぜ正式なプレゼンテーションを行うのですか？

チームの規模が少なくとも 2 人であると仮定して、現実世界の例を実行します。2 人 (またはそれ以上、多ければ多いほど良い) の人がコードを取得し、変更を行い、ソース管理以外のものを使用してすべての変更を統合するために必要なことを示します。使用することを意味します。

次に、ソース管理を使用して同じシナリオを実行します。

ソース管理を使用することで節約できる時間と労力は、それ自体が物語っています。

score 2 · Accepted Answer

結論に固執し、それがお金にどのように関係しているかを説明すれば、上司はおそらく耳を傾けます.

あなたが一人のプログラマーである場合、主な議論は、単純な間違いを修正したり、間違った考えになったコードをロールバックしようとしたりして、時間 (したがってお金) を無駄にする可能性が減るということだと思います.

あなたが複数のプログラマーである場合、上記は 2 回行われます。さらに、お互いを待つ時間を無駄にすることなく、同じコードベースで一緒に作業できる唯一の正気の方法です。

Visual Source safe は何もないよりはましですが、ほとんどすべての点で優れた無料のオプションがあります。上司がソース管理が不可欠である理由を理解するためにプレゼンテーションを必要としている場合、理解を深めれば、上司はあなたがどのツールを使用するかは気にしないかもしれません。他のツールの経験があり、vss を使用していないということは、収益に関連するため、それで十分な場合があります。

score 1 · Accepted Answer

チームの残りの部分に賛同していることを確認してください。それらでプレゼンテーションをテストできますか？うまくいけば、彼らもその必要性を理解しています。

グッドプラクティスがボトムアップで開始されているのを見るのはうれしいことです。何らかの管理上の命令ではなく、独自の慣行から来る場合、おそらく誰もがその慣行を採用する可能性が高くなります。

score 1 · Accepted Answer

バージョン管理を使用する主な理由は一貫性です。

プロジェクトに一貫性がない場合、問題が発生し、コードが失われます。

score 1 · Accepted Answer

1

みたいなことを避けるために

     "Hey! What happens ? It worked yesterday."

于 2009-02-20T18:02:41.500 に答える

score 1 · Accepted Answer

経営陣に SCCS に時間を投資するよう説得する最も簡単な方法は、バックアップとアーカイブに焦点を当てることです。Subversion (SVN) などを利用することで、任意のプロジェクトを任意の時点に即座に復元できます。誰かにバックアップテープを調べてもらう必要も、わかりにくいディレクトリ構造で複数のバージョンを追跡することを心配する必要もありません。

他にも多くの利点があることは明らかですが (つまり、2 人のユーザーが同じファイルで同時に作業できるなど)、何年も前に私の会社をすぐに売却したのはバックアップです。

score 0 · Accepted Answer

他の人はソース管理の特定の利点について他の場所で言及していますが、私は質問の「VSS」部分を明示的に扱いたいと思いました。

上司が Microsoft ツールを使用したい場合、Team Foundation Server と Team Suite は非常に優れた組み合わせです。また、バグ追跡、ドキュメント、レポート機能などの他のツールも含まれているため、後でプロセスを改善するための優れたプラットフォームになります。私が働いている場所では、VSS に非常に満足しており、同僚から VSS に関する恐ろしい話を聞いたことがあります。

「Microsoft Tools」の質問に対する回答として、TFS を念頭に置いてください。

version-control - チームがソース管理を採用する必要があるのはなぜですか？

25 に答える 25

単一の開発者、単一のブランチ

単一の開発者、複数のブランチ

複数の開発者

あなたのチームがソース管理を採用すべきではないのはなぜですか?

Related

Reference