コードをマージしても問題ないと思いますか？

StackOverflow https://stackoverflow.com/questions/1410722

  •  05-07-2019
  •  | 
  •  

質問

今朝、リファクタリングに関する2つの意見を読みました。

  • オピニオン1（ページが存在しない）
  • オピニオン2（ページが存在しない）

彼らは、コードを次のように分岐する（そしてその後マージする）ことを推奨している：

  1. トランクを清潔に保ちます。
  2. 開発者が危険な変更から離れることを許可します。

私の経験では（特にBorlandのStarTeamの場合）、マージは重要な作業です。そのため、必要な場合にのみ分岐します（つまり、リリース候補を凍結する場合）。

理論的には、分岐は理にかなっていますが、マージのメカニズムにより非常に危険な操作になります。

私の質問：

  
      
  • コードのマージを快適に感じていますか？
    •   
  • リリースを凍結する以外の理由でコードを分岐しますか   候補者ですか？
    •   
役に立ちましたか？

解決

いくつかの緩やかな指針：

  • ブランチは遅く、必要なときにのみ
  • 早期に頻繁にマージする
  • 変更を行う人または元のバージョンを書く人のいずれかが、マージを行うための適切な人を取得します

分岐は単なる別のツールです。最大限の利益を得るには、分岐を効果的に使用する方法を学ぶ必要があります。

分岐に対するあなたの態度は、おそらく分散型オープンソースプロジェクト（Gitのプロジェクトなど）と会社の開発プロジェクト（おそらくSVNで実行されているプロジェクト）の間で異なるはずです。分散プロジェクトの場合は、分岐を奨励してイノベーションと実験を最大限に活用し、後者の場合はより厳密な制御が必要になり、分岐が発生する/しないのを指示するコード行ごとにチェックインポリシーを指示する必要があります。 ;コード。

ここに分岐のガイドがあります：
http://www.vance.com/steve/perforce/Branching_Strategies.html

次の短いガイドに、いくつかの高レベルのベストプラクティスを示します。
https：//www.perforce。 com / sites / default / files / pdf / high-level-perforce-best-practices.pdf

他のヒント

分岐は苦痛かもしれませんが、そうすべきではありません。

これは、gitのようなプロジェクト（mercurial、bazar）がCVSとSVNについて教えてくれることです。 GitとMercurialでは、分岐は簡単です。 SVNでは簡単ですが、大きなプロジェクトでは管理が少しハードコアになる可能性があります（ブランチ/マージプロセスに費やされる時間が、gitやmercurialなどの他のものと比較して非常に長くなる可能性があり、 -明らかな競合）。これは、頻繁に分岐することに慣れていないユーザーが分岐に自信を持つのに役立ちません。分岐の強力な使用法を知らない多くのユーザーは、プロジェクトに新しい問題を追加しないために分岐を遠ざけ、未知のものへの恐怖が効率を大きく損なうようにします。

分岐は、分岐するのに十分な理由で使用する必要がある簡単で強力なツールである必要があります。

ブランチのいくつかの正当な理由：

  • 特定の機能を他の人と並行して作業する（または、プロジェクトに一人でいる場合は、他の機能を代わりに使用する）;
  • アプリケーションのブランドバージョンがいくつかある;
  • 同じアプリケーションの並列バージョンを使用する-チームの一部が同時期に開発したコンカレントテクニックのように、何がより効果的かを確認する。
  • アプリケーションが「安定」しているアーティスト/デザイナー（ゲームなど）の特定のブランチでアプリケーションのリソースが変更されている機能の追加とデバッグには他のブランチとトランクが使用されます。
  • [ここに便利な使用法を追加]

分岐は簡単です。マージはそうではありません。そのため、分岐することはほとんどありません。

SVNを使用すると、分岐は比較的簡単です。特に、トランクを定期的にブランチにマージして、同期がずれすぎないようにします。

svnを使用します。コードの分岐には約5分しかかかりません。これは、トランクを台無しにすることから私たちを救う痛みの量と比較してささいなことです。

数百人の開発者が分岐する数百万行のコードベースで作業することは、日常的に発生します。ブランチの寿命は、行われている作業の量によって異なります。

小さな修正の場合：

  • デザイナーはメインストリームから分岐を作成します
  • 変更を加える
  • テスト
  • レビュー
  • 蓄積された変更をメインストリームからサイドブランチにマージします
  • 前のステップの1つ以上を繰り返します
  • メインストリームにマージ

多人数チーム機能の場合：

  • チームはメインストリームから機能サイドブランチを作成します
  • 個々のチームメンバーは、「小さな修正」のように機能サイドブランチを操作します。アプローチブランチをマージして機能ブランチを作成します。
  • サイドブランチプライムは、メインストリームからフィーチャサイドブランチに蓄積された変更を定期的にマージします。メインストリームから機能サイドブランチへの小さな増分マージは、処理がはるかに簡単です。
  • 機能が機能する場合、メインストリームから機能サイドブランチへの最終マージを行います
  • 機能サイドブランチをメインストリームにマージ

カスタマーソフトウェアリリースの場合：

  • リリースブランチを作成
  • ブランチをリリースするために必要に応じて修正を提供する
  • 必要に応じて、メインストリームとの間で修正が伝播されます

顧客リリースストリームは、サポートに非常に費用がかかる場合があります。テストリソース-人と機器が必要です。 1〜2年後、メインストリームが進むにつれて、特定のストリームに関する開発者の知識が古くなり始めます。

MicrosoftがXP、Vista、およびWindows 7を同時にサポートするにはどれくらいの費用が必要か想像できますか？テストベッド、管理、ドキュメント、顧客サービス、そして最後に開発者チームについて考えてください。

ゴールデンルール：多数の開発者を失速させる可能性があるため、メインストリームを決して中断しないでください。 $$$

ブランチの問題は、ブランチの作成が簡単な分散バージョン管理システム（私の場合はGitですが、MercurialとBazaarもあります）を使用する理由です。

開発には常に短命のブランチを使用しています。これにより、自分のリポジトリをいじって間違いや悪い選択をした後、メインブランチの変更を rebase できるので、クリーンな変更のみが履歴に保持されます。

tag sを使用してフリーズコードをマークします。これらのシステムでは、コードベースに長期間存在するブランチをロードすることなく、バグ修正のためにこれらのシステムに簡単に戻って分岐できます。

私はSubversionを使用しており、分岐は非常にシンプルで簡単だと考えています。質問1に答えるために。はい。

分岐の理由は大きく異なります。必要に応じて分岐します。あらゆる可能性のためにルールと理由を述べるのはかなり難しい。

ただし、「開発者が危険な変更から逃れることを許可する」限り、コメント。私はそれに完全に同意します。本当にコードをいじりたいときはいつでもブランチを作成します。そして、私がそれで作業している唯一の開発者であったらいいのにと思います。

svnとTFSを使用したプロジェクトに参加しましたが、単独での分岐は非常に簡単です。

リリース候補、長期的または実験的な機能、および他のチームの干渉から隔離するために分岐を使用しました。

古いブランチまたは非常に開発されたブランチはトランクとは大きく異なる場合があり、元に戻すにはかなりの労力が必要になる可能性があるため、ブランチングの唯一の痛みを伴う瞬間はマージです。

上記のことを述べたので、分岐は開発中に考慮する必要がある強力で便利なプラクティスであると言えます。

マージが非常に苦痛な場合は、より優れたVCSへの移行を検討してください。それはより大きな痛みですが、一度だけです。

私たちはsvnを使用し、変更をブランチに適用するルールを採用しました。わずかな変更はトランクで行われます。

ブランチリリースも。

ブランチングとマージはうまく機能しました。座って物事がどのように適合するかについて考える必要があることは確かですが、通常、svnはすべてをマージする素晴らしい仕事をします。

svnを使用しています。コードをブランチするのに1分もかかりません。以前はClearcaseを使用していましたが、コードの分岐に1分もかかりませんでした。また、私は他のより小さなSCMを使用しましたが、それらはブランチをサポートしていないか、使用するには苦痛でした。 Starteamは後者のように聞こえます。

したがって、より便利なものに移行できない場合（実際、Starteamについて悪いことしか聞いていません）、別のアプローチを試す必要があります：手動ブランチ。これには、コードをチェックアウトし、別のディレクトリにコピーして、新しいディレクトリとして追加することが含まれます。マージする必要がある場合は、両方のディレクトリをチェックアウトし、WinMergeを使用してマージを実行し、結果を元のディレクトリにチェックインします。ブランチを使い続けると厄介で潜在的に困難ですが、動作します。

Branchingのトリックは、完全に新しい製品として扱うことではありません。これはブランチです-比較的短命のデバイスで、メインの製品トランクに個別に安全に変更を加えるために使用されます。マージが難しいと思う人は、コードファイルをリファクタリングして（名前の変更、コピー、新規作成、古い削除など）、ブランチが完全に異なるものになるか、ブランチを長く維持して変更が蓄積されるようにします。オリジナルにほとんど似ていない。 ブランチを長期間保持することができます。変更を定期的にマージするだけです。これを行うと、分岐/マージが非常に簡単になります。

私は数回しかやったことがないので、私は正確にそれを快適にしません。

いくつかのチェックインにまたがる設計実験を行うために行ったので、分岐は庭で遊ぶための簡単な方法です。 、そう多くの時間を失いませんでした。

また、トランクをコンパイルできないようにする広範な変更を行うときにもそれを行いました。私のプロジェクトでは、コードベースの大部分（ジェネリックからsystem.objectへ）のコンパイル時の型安全性を削除する必要があることが明らかになりました。これにはしばらく時間がかかり、コードベース全体を変更する必要があり、他の人の作業に干渉することがわかっていました。また、完成するまでビルドが中断します。そこで、ジェネリックを分岐して削除し、その分岐がコンパイルされるまで作業しました。それをトランクにマージしました。

これはかなりうまくいきました。つま先の踏み出しをたくさん防いだ。うまくいけば、このようなことは二度と起こらないでしょう。設計が変更され、この種の広範囲にわたる編集が必要になり、大量のコードがスローされることはないということは珍しいことです...

ブランチを適切に管理して、マージを簡単にする必要があります。私の経験では（Perforceを使用）、メインラインからブランチへの定期的な統合は、メインラインへの統合が非常にスムーズに進むことを意味しました。

マージが失敗するのはまれなケースのみでした。メインラインからブランチまでの絶え間ない統合にはマージが関係している可能性がありますが、それらは自動編集ツールが人間の介入なしに処理できる小さな編集でした。これは、ユーザーが「見ない」ことを意味していました。これらが起こっています。

したがって、最終的な統合に必要なマージは、多くの場合、自動的に処理することもできます。

Perforces 3-wayマージツールは、実際に必要なときに非常に役立ちました。

  

コードの分岐を快適に感じますか？

実際に使用しているツールによって異なります。 Starteamの場合、分岐は実に重要なことです（TBH、Starteamは分岐を嫌います）。 Gitでは、分岐は通常のアクティビティであり、非常に簡単です。

  

リリース候補をフリーズする以外の理由でコードを分岐しますか？

まあ、これは本当にバージョン管理パターンに依存しますが、簡単な答えはイエスです。実際、次の記事を読むことをお勧めします。

最初の記事で説明したパターンは本当に気に入っており、Starteamを含む任意の（非分散）バージョン管理システムに適用できます。

Git、Mercurialなどの分散バージョン管理システム（DVCS）を使用した（そしてそれのみを使用した）2番目のアプローチ（実際には、両方の戦略の組み合わせ）を検討するかもしれません...

StarTeamを使用し、それを必要とする状況（つまり、リリースサイクル中の本番への修正プログラム、または複数のリリースウィンドウにまたがる長期にわたるプロジェクト）がある場合にのみ分岐します。ビューラベルを使用してリリースを識別します。これにより、後で必要に応じてブランチを簡単に作成できます。すべてのビルドはこれらのビューラベルに基づいており、ラベルのないコードはビルドしません。

開発者は、「コード-テスト-コミット」に従ってください。モデルおよびテスト目的のビューまたは「リスク」が必要な場合開発では、作成して管理します。リポジトリを管理し、必要な場合にのみブランチを作成します。それらの時間は次のとおりです（ただし、これらに限定されません）：

  • 生産ホットフィックス
  • 開発サイクルが長いか重複しているプロジェクト
  • 広範な書き換えまたは実験的開発

StarTeamのマージツールは最高ではありませんが、それによって引き起こされる問題にまだ遭遇していません。マージを実行している人は、自分が何をしているのかを知っているだけで十分です。

「読み取り専用参照」の作成Star Teamで表示し、フローティング構成に設定すると、トランクの変更がブランチに自動的に表示されます。変更時に分岐するアイテムを設定します。これは、同時開発の取り組みに適しています。

「読み取り専用参照」の作成ラベル付けされた構成のビューは、既存の製品リリースのホットフィックスに使用します（ラベル付けされていると仮定します）。

分岐はほとんどの人が答えたように簡単ですが、あなたが言うようにマージはそうではありません。

実際のキーは、分離テストと単体テストです。分岐する前に 切り離し、メインに注目して、切り離しとインターフェイスが維持されていることを確認してください。このようにマージするときは、レゴのピースを交換するようなものです。古いピースを削除すると、新しいピースがその場所に完全に収まります。単体テストは、何も壊れていないことを確認するためにあります。

分岐とマージはかなり簡単です。

  • 分岐/マージは非常に快適です。
  • 分岐は、開発プロセスモデルに応じてさまざまな理由で行われます/

いくつかの異なるブランチモデルがあります：

こちらです

  Trunk          
  .      
  .      
  .      
  ..         
  . ....     
  .   ...
  .      ..Release1
  .      
  .      
  ...        
  .  .... 
  .    ...Release2
  .      
  .      
  ..         
  . ...  
  .  .. 
  .    ...Release3
  .      
  .

今、奇妙なことがあります。 Release1にバグ修正が必要だとします。ここで、Release1をブランチして1.1を開発する必要があります。これで問題ありません。R1をブランチして作業を行い、R1にマージしてR1.1を形成できるからです。これにより、リリース間で差分がどのように明確に保たれるかに注意してください。

別の分岐モデルでは、すべての開発がトランクで行われ、各リリースにタグが付けられますが、その特定のリリースではそれ以上の開発は行われません。開発のために分岐が発生します。 

  Trunk                                           
  .                                                         
  .                                                         
  .                                                         
  .Release1           
  .                       
  .                       
  .                   
  .                   
  .Release2           
  .                   
  .......                 
  .      ......       
  .           ...DevVer1
  .          .    
  .          .            
  .        ...DevVer2
  .      ....         
  .  ....             
  ...                     
  .Release3           
      .

他の主要なブランチモデルが1つまたは2つある可能性がありますが、頭上からそれらを思い出すことはできません。

要するに、VCSは柔軟な分岐とマージをサポートする必要があります。 ファイルごとのVCSシステムは、IMO（RCS、Clearcase、CVS）に大きな痛みをもたらします。 SVNはここでも面倒だと言われていますが、理由はわかりません。

Mercurialはここで素晴らしい仕事をしています（gitと同様です）。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top