7
私は最近、SVNからGitに切り替えました。ベストプラクティスなどについては、まだ学習プロセスに入っています。this guideを私たちの支店とリリースを管理するための起動パッドとしてフォローしています。フィーチャーブランチを元に戻すのがよいですか？
このドキュメントでは、フィーチャーブランチは一般的に開発者にとってローカルであり、私が他の場所で読んだこととほぼ同等であることを示しています。しかし、エンジニアの中には、次のリリースには含まれない機能の開発に取り組んでいるものもあります。これらの機能は、リリースサイクルを2〜3回繰り越したものです。
私がエンジニアから聞いた懸念は、多くのコードをローカルに保存することに懸念があることです。バックアッププロセスが整っていても、依然として懸念されています。私は彼らの心配に同意する傾向があります。
私の質問は、もっと即時のリリースが予定されていないブランチを起点にすることが標準的なのでしょうか？ある時点で、これらのブランチは、開発ブランチにマージされ、その後、起点から削除されます。
例として、1人のエンジニアがかなり大きな履物を扱っています。彼のコードが開発ブランチに押し込まれることは望ましくありません（常に次のリリース候補です）。だから私たちは彼のためにフルフルーム支店を作り、それを起源に押し込んだ。私がリンクしている文書や読んだ人以外は、これが良いか悪いのかについては明確ではありません。
もっと良い方法がある場合は、私の推測を知らせてください。
私はそれをすべて理解しており、それは私にとって理にかなっています。しかし、エンジニアが完了するのに数週間かかる可能性のあるコードで作業している場合、コードを予期せぬ状況から安全にするために、そのコードを元に戻すのは理にかなっていませんか？ – Gregg
メインのレポにバックアップシステムをセットアップしている場合は、しかし、バックアップはいろいろな方法で解決できますが、メインのリポジトリを介して行う必要はありませんが、可能性があります。再び、それはトレードオフです。人々が枝を押すようにしましょうが、あまりにも多くの枝を押しすぎるとあまり良くないかもしれないことを彼らに知らせてください。ブランチが長生きしている場合は、確かにそれがホットフィックスであれば、nah prollyではありません。 – ralphtheninja
Gotcha。それが私たちが取っているアプローチです、と私は思います。長生きの枝（週またはそれ以上）はおそらくプッシュしたいと思うでしょう。短命（日）はローカルです。これは私が好む。私はちょうど間違った方向に私の人々を訓練したいと思わなかった。ありがとう。 – Gregg