ここで概説されているgit分岐戦略を使用していますhttp://nvie.com/posts/a-successful-git-branching-model/
これまでのところ、私にとっては本当にうまくいっています。
私が自問自答することが多いのは、機能ブランチに取り組んでいるときに、プロジェクト全体に関連するコードを実装する必要があるということです。これらの状況を処理する最善の方法は何ですか?
a) メインの開発ブランチをチェックアウトし、変更をコミットして、機能ブランチを開発からリベースします。
b) 機能ブランチに変更を加えてから、開発にマージして、他の機能ブランチがそのコードにアクセスできるようにします。
c) 共通コード用の新しいブランチを作成し、それを開発およびそれを使用する必要がある機能ブランチにマージします。
ここで別の質問です。機能ブランチをメインの開発ブランチにマージする頻度はどれくらいですか? 機能が完全に完成するまで待ってからマージして削除しますか? それとも、開発が安定している間はいつでも何度か開発にマージしますか?
私はオプション a/ が好きですが、現実には、コミットの後にコミットを行っている場合、それらのいくつかはプロセスのずっと後の段階で実際に共通のコードであることに気付くだけです。
それがブランチ(feature通常はまだプッシュされておらず、共有されていないブランチ)で発生した場合、私interactive rebaseは . -前方マージ)。そこから、これらの新しい共通機能の恩恵を受ける必要がある他のブランチに
リベースできます。masterfeaturemaster
機能ブランチをマージバックすることは、その機能ブランチの状態が他の人に見える必要がある場合にのみ意味があります (ブランチをリポジトリにプライベートにmaster保ちながらプッシュしたいため)。
開発の残りの場合:feature
featureブランチにあるものの一部を必要とせずに続行できますmasterいくつかの一般的なファイル セットを変更せずに続行できます (これは、とfeatureブランチの間で長く待つほど、マージがはるかに困難になることを意味します)feature、その後、後でブランチをマージすることを好みます。