23

バグの解決策をテストするために作成され、レビュープロセスで間違っているか、問題のより良い解決策があることが示されたためにマージされていないgitブランチの現在のベストプラクティスは何ですか？

例。プロジェクトfizzbuzzには、空のフィールドでのクラッシュを報告するバグレポートがあります。

  • 新しいブランチを作成し、handle-empty-fieldsそのブランチに2つコミットして、問題を「解決」します。
  • 次に、そのブランチをfizzbuzzプロジェクトマネージャーに送信し、バグレポートにリンクします。
  • 誰かが私の修正でエラーを見つけ、別のパッチを書き、そのパッチが受け入れられます。

これで、handle-empty-fields私のコードのコードは役に立たなくなりました。正しくなく、コードに適用できなくなりましたが、そのバグレポートで参照されています。

私は何をすべきか？ブランチを維持しますか？私はすぐに数十の放棄されたブランチになってしまい、gitにはブランチを放棄または閉じたものとしてマークする方法がありません。ブランチを削除しますか？しかし、そのバグレポートを見ている人は、それを見つけて404を取得します。

他の開発者、特にダウンストリーム開発者に問題を引き起こすため、リポジトリをリベースしないように勧められることがよくあります。機能またはバグ修正ブランチの提案は何ですか？

更新：githubがプルリクエストに含まれるコミットを削除しないようです。したがって、変更をプッシュしてプルリクエストに変換すると、変更を失うことなく、後でブランチを削除できます。まあ、githubがまだ動作している間;）。

4

4 に答える 4

16

私のやり方はそれにタグを付けることです。完全なタグを使用して、わかりやすい名前を付けます。次に、ブランチを削除して、ブランチリストに表示されないようにすることができますが、タグが付けられているため、ブランチをチェックアウトすることでブランチを再作成できます。タグのすべてのコミットは引き続き使用可能であり、次のgit gcようなものでコミットが失われることはありません。

git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX"
于 2012-01-24T15:55:14.520 に答える
12

git update-ref refs/Attic/handle-empty-fields refs/heads/handle-empty-fields

タグ内のデッドブランチを保持する代わりに、別のrefs名前空間を使用できます。利点は、タグリストが整理されたままになることです。欠点は、磁器からgitの配管レベルに移行することです。

于 2012-06-21T17:40:02.667 に答える
2

これは正確な状況に依存すると思います。可能な解決策：

  • バグレポートにコメントを追加して、言及されたブランチが役に立たないことが判明し、削除されたことを示します。ブランチに何らかの価値があると感じた場合は、何をしたかを簡単に説明してください。そうすれば、ブランチがなくなっても、人々は必要な情報を入手できます。

  • ブランチを保持しますが、どういうわけか名前を変更して「放棄済み」としてマークします。これを示すコメントをバグレポートに追加します（そしてブランチへのリンクを変更します）。たとえば、ブランチ名の前に「OLD-」を付けるなどの規則を設定できます。

  • ブランチにタグを付けてから削除します（バグデータベースエントリでこれについても言及します）。そうすれば、ブランチを削除できますが、コミットにはタグを介してアクセスできます。gitはタグ（およびブランチ）に単純な名前空間を提供することに注意してください-名前に「/」を含めることができます。「oldbranch/」の下にタグを使用するなど、規則に同意することができます。（Abizernの回答から引用。）

  • ブランチがマージされたら、バグレポートでマージコミットに言及/リンクするだけです。その場合、ブランチはマージコミットに含まれているため、おそらくあまり面白くありません。

一般に、ブランチのバグ修正には特別な命名規則を採用することをお勧めします。

私の（個人的な）gitリポジトリでは、すべてのバグについて、最初にバグDBでバグを開きます。次に作業する場合は、名前がバグIDで終わるブランチを作成します（例：「opencrash-342」、「handle_empty_file-663」）。そうすれば、バグDBとブランチの関係は明らかです。

また、ブランチのリストが長くなりすぎる場合は、いつでも追加されたIDでフィルタリングできます（たとえば、閉じたバグのリストを作成し、「gitlog」の出力からこれらをフィルタリングするための小さなスクリプトなど）。

于 2012-01-24T15:49:35.237 に答える
1

これは私の見解にすぎませんが、有用なコードが含まれていないブランチは自由に削除できると思います。最悪のシナリオでは、誰かがバグレポートを見て、拒否されたバグ修正へのリンクが壊れていることに気付くでしょう...まあ、それは誰にとっても大きな問題のようには見えないと思います。

于 2012-01-24T15:34:01.073 に答える