9

最近、SVNからGitに切り替えましたが、ベストプラクティスなどに関しては、まだ学習プロセスにあります。ブランチとリリースを管理するための出発点として、このガイドに従っています。

このドキュメントは、機能ブランチは一般的に開発者にとってローカルであり、他の場所で読んだものとほぼ同等であることを示唆しています。ただし、一部のエンジニアは、次のリリースには含まれない機能に取り組んでいます。これらの機能は、リリースサイクルの2〜3回前に実行されます。

私がエンジニアから聞いた懸念は、彼らが非常に多くのコードをローカルに保つことを懸念しているということです。バックアッププロセスが実施されていても、それは依然として懸念事項です。そして、私は彼らの懸念に同意する傾向があります。

だから私の質問は、より即時のリリースが予定されていないブランチが元にプッシュされるのは標準ですか?ある時点で、これらのブランチは開発ブランチにマージされ、元のブランチから削除されます。

例として、1人のエンジニアがかなり大きなフルフィルメントピースに取り組んでいます。彼のコードが開発ブランチ(常に次のリリース候補)にプッシュされることは望ましくありません。そこで、私たちは彼のためにフルフルメントブランチを作成し、それを元に戻しました。私がリンクした文書や私が読んだ他の文書は、これが良い習慣か悪い習慣かを明確にしています。

ここでより良い方法がある場合は、私に知らせてください、または私の推測を確認してください。

4

2 に答える 2

7

場合によります。

誰かが機能に取り組んでいて、それを他の開発者と共有したい場合、それは完全に理にかなっています。しかし、それが単独で作業している機能である場合、それを共有する必要がないのに、なぜそれをサーバーにプッシュするのでしょうか。機能が完了すると、最終的にはマスターや開発などの他のブランチにマージされます。

共有する必要のあるブランチを共有し、他のブランチをローカルに保持します。必要がない場合は、メインリポジトリを台無しにしないでください。さらに、他の開発者は、git remote prune originを介して、ブランチがメインリポジトリから削除されたときに、参照のリポジトリを手動でクリーンアップする必要があります。

于 2012-04-06T20:24:27.927 に答える
3

小さいサイズの機能の場合はオプションです。バックアップの目的で、中規模から大規模の機能を毎日プッシュすることをお勧めします。あなたの会社は、あなたの開発者が彼のPCが死んだときに2週間の仕事を無駄にしたと聞くのを嫌うでしょう。

于 2015-05-26T15:33:14.483 に答える