web-dev-qa-db-ja.com

選択した{DVCS}の名前付きブランチの適切な命名規則

Mercurialをゆっくりとオフィスに統合し、名前付きブランチの使用を開始したWeb開発を行っています。

ただし、ブランチに名前を付ける限り、良い慣例はまだ見つかりません。

私たちは試しました:

  • FeatureName(これが原因で問題が発生していることがわかります)
  • DEVInitial_FeatureName(開発者が出入りすると混乱する可能性があります)
  • {uniqueID(int)} _ Feature

今までのところ、uniqueID_featureNameが優勢ですが、参照用に小さなDBで維持することを考えています。

これは、branchID(int)、featureName(varchar)、featureDescription(varchar)、date、whoなど...

これにより、1_NewWhizBangFeature、2_NowWithMoreFoo、...のようなブランチが得られ、ログを確認することなく、そのブランチの機能を簡単に参照できます。

そこに何か良い解決策はありますか?

16
jfrobishow

Issue Trackerがない場合は、設定してから{issue Tracker名} _ {チケット番号}を使用することをお勧めします。今後数年後に誰かがバグを報告し、機能がどのように機能するのか正確にわからない場合、ファイルに注釈を付けて、ユーザーがその正確な機能を要求した可能性のある場所に戻るのは簡単です。

14
Asa Ayers

私はそのようなフォームを使用することをお勧めします(例として):

 BUG_ID 
 BUG#ID 
 TICKET_ID 
 TICKET#ID 
 feature_bla-bla-bla 
 release-x.xx.xx 
 release_x.xx.xx 
 build_2010-20-12 
 build_4565 
 BRANCH_x.xx.xx 

適切な接頭辞(hgブランチからのフィルター出力を許可するため)、大文字の規則、および接頭辞とID /名前の間の区切り文字を選択するだけです。

2
gavenkoa

シンプルにして、FeatureName(またはfeature-name)の規則に従ってブランチに名前を付けることをお勧めします。はい、これは共有名前空間を意味しますが、これは現実の世界ではほとんど問題になりません。機能が完了してメインラインに完全にマージされたら、ブランチを安全に削除できます。

分散バージョン管理の主な考え方は、分岐が簡単である必要があるということです。必須の一意のIDのような追加の官僚機構を導入すると、これを難しくするだけです。

2
Adam Byrtek