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

16

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

しかし、ブランチに名前を付けることに関しては、良い慣習を見つけることができませんでした。

試しました：

FeatureName（これが問題の原因であることがわかります）
DEVInitial_FeatureName（開発者が出入りするときに混乱する可能性があります）
{uniqueID（int）} _ Feature

これまでuniqueID_featureNameが勝っていますが、参考のために小さなDBで維持することを考えています。

ブランチID（int）、featureName（varchar）、featureDescription（varchar）、date、whoなど...

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

より良い解決策はありますか？

version-control mercurial

— jfrobishow
ソース

14

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

— アサ・エアーズ
ソース

バグトラッカーがあり、バグ修正のためにブランチ名にbugIDを使用することを計画しています。私の質問は、まったく新しいものを追加する以外に何も修正しない、まったく新しい開発に関するものでした。愚かな強化チケットを作成してそこから行くことができると思います。

— jfrobishow

5

絶対に新しい機能のチケットを作成する必要があります。追跡する作業もあります。一意のIDが必要な場合は+1。

— AShelly

新しい機能のすべての詳細をトラッカーに確実に入れると、誰かが設計どおりに機能するか、本当にバグがあるかを後で確認できます。私は5歳以上のプログラムを維持する開発チームで働いています。クライアントがバグを報告し、それを調査すると、設計どおりに機能しており、元の開発者と元のリクエスタが両方ともなくなっていることがあります。なぜそうなのかわからないという同様の状況があり、機能がトラッカーになければ、見つける方法がありません。

— アサエアーズ

2

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

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

— アダム・バーテク
ソース

1

同意します、これが道です。衝突を避けられないほど多くのブランチがある世界はどこでしょうか？

— 代替案

結構、名前に関連付けられた説明を取得することは私たちにとってより重要です...最初のコミットにはそれを含める必要がありますが、それをすばやく抽出する方法はわかりません。

— jfrobishow

1

大企業の環境では、開発者に機能の名前を付けさせることは遅かれ早かれ頭痛の種になります。

— AShelly

1

「大企業環境」では、開発者は信頼できないためです。ただし、変数、関数、およびファイルの名前も作成します。それも管理するための委員会を設置する必要があります！（皮肉）

— アダムByrtek

2

このような形式を使用することをお勧めします（例として）：

BUG_ID
バグ#ID
TICKET_ID
チケット#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 /名前の間の区切り文字を選択するだけです。

— ジバンコア
ソース

最後にBUGID_ {freeCamelCasedTextDescription}で行った+1。

— jfrobishow