1

SVN がワークフローをサポートしないところまで来ました。

現在、開発者がすべてを中央サーバー (RAID を備え、定期的にバックアップされます) に少なくとも 1 日に 1 回コミットする SVN トランクがあります。開発者が機能の準備ができたと判断すると、SVN メンテナーがコードを安定版ブランチにマージします。安定版ブランチは定期的にビルドされ、テスト サーバーにデプロイされます。機能ブランチもいくつかありますが、機能開発の最後にのみトランクに再統合されるため、通常は問題になりません。

主な問題はトランクです。日々のコミットでカオスになる可能性が高いです。結局のところ、すべての開発者が他の開発者にとって何かを壊さないコードを持っているとは誰も保証できません。あなたは言うことができます-それが機能しない場合はコミットしないでください.しかし、PCまたはハードドライブの障害が発生した場合、1日の作業を失うリスクがあります. 開発者ごとに個別のブランチを作成することもできますが、これらのブランチの管理とマージは SVN では簡単なプロセスではありません。特に一部の開発者は初心者です (地元の大学から何人かの研修生を受け入れています)。また、開発に 1 日か 2 日しかかからない機能もあるため、SVN に専用のブランチを作成するのに手間がかかります。

ワークフローを簡素化するツールを探していたとき、TFS シェルフセットでの経験を思い出しました。これらは、未完成の変更をリモート サーバーに保存するのに非常に便利なようです。ただし、シェルブセットはバージョン管理をサポートしていないため、開発者が以前のコードに戻す必要がある場合に問題になる可能性があります。また、開発者は主に Windows と Visual Studio を使用していますが、サーバーは Linux ベースであるため、TFS に移行することはできません。

それから、Git の探索を開始しました。これは非常に強力なようで、最近登場した Visual Studio の拡張機能もいくつかあります。しかし、私はそれがどのように機能するかについて少し混乱しています。Git はリポジトリのローカル クローンを提供しているようですが、データの損失を避けるためにローカルの変更を頻繁に中央サーバーにプッシュする必要があります。

私たちが本質的に必要としているのは、開発者が独自のブランチ (フル機能、バージョン管理など) で「自動的に」作業できる機能です。このブランチは中央サーバーに保存され、一部の開発者の PC に障害が発生した場合のデータ損失を回避します。各開発者はデフォルトで独自のブランチを取得します (また、一部の実験では、開発者は自分の「マスター」ブランチからブランチをフォークできる必要があります) が、開発者が変更をブランチから Git マスターに直接プッシュすることは許可されるべきではありません。ブランチ。マスター ブランチの保守を担当する人だけが、開発者の「マスター」ブランチから機能をマージすることができます。

デフォルトで Git を使用してこのようなワークフローを実現することは可能でしょうか?それとも追加のツールや設定が必要でしょうか? Git は、実質的に同じ目標を達成できる、より優れたワークフローを提供してくれるでしょうか? つまり、デタッチされたローカル コピーで作業することによるデータ損失のリスクを最小限に抑え、毎日の変更を中央リポジトリにプッシュすることによる混乱を最小限に抑えることができるでしょうか?

4

1 に答える 1

4

序文

悪いワークフロー (および現在の SCM の不適切な使用) は、SCM を変更する悪い理由です

はい、Git(理論的には) データ損失のリスクと混乱のリスクを最小限に抑えるのに役立ちます

  • 各開発者は、ローカル リポジトリと少なくとも 2 つのリモート (個人用リモート リポジトリと共通セントラル リポジトリ) を持っています。
  • 各開発者は自分のリポジトリで作業するため、他の開発者の作業を破壊することはできません

しかし、Git のおかげで

  • DVCS の性質
  • 全体的な複雑さ

多くの追加の頭痛の種をもたらします。

  • 「中央」レポのブランチの ACL を管理することは、非常に重い、自明ではないタスクです。
  • DVCS は、すべてのリポジトリ (および情報セキュリティ) を効果的に管理できないことを意味します。
  • Subversion の日常的な使用に問題がある「初心者」は、Git でより多くの問題を抱えることになります。
  • Windows の Git は、プラットフォーム固有の問題や問題が山ほどある「いとこ」のままです。

履歴書

ワークフローを合理化し、(悪い) 習慣を修正し、少なくともしばらくは Subversion で作業を続けることをお勧めします。

いえ

  • 「Branch per Task」ワークフローの使用を開始します。トランクに直接コミットしないでください - トランクには (理想的には)マージセットのみを含める必要があります
  • 主な VCS ルール「頻繁にコミットし、すばやくコミットする」に厳密に従ってください。1 日に 1 つの巨大なコミットはひどい考えです。コミットには、1) 単一、2) 論理的に独立、3) 管理可能な変更ブロックが含まれている必要があります
  • Subversion 1.8 に移行 - いくつかの重要な側面での開発 (ファースト クラス シチズンとしての移行、マージの改善) とリポジトリの管理 (継承されたプロパティ、RDC) がはるかに簡単になりました。
于 2013-07-20T16:21:17.097 に答える