5

私はブランチを維持するために git-flow を使用しているため、マスターがあり、ブランチを開発しています。

開発はマスターより数コミット (~50-100) 進んでいます。

ただし、選択した機能を開発からマスターに前倒しで導入する必要があります。

これどうやってするの？チェリーピックを使用する必要がありますか？最終的なマージが master に戻る前に、developer を master にリベースするとどうなりますか?

4

4 に答える 4

3

これらの特定の機能を統合するためだけに別の開発ブランチを作成しrebase -i、不要なコミットを削除するか、必要なコミットをそのブランチにチェリーピックすることを検討しましたか?

git flow リリース ブランチを使用してこれを行うこともできるようですが、そうする場合は、インタラクティブなリベース/削除アプローチを使用する必要があります。これはリリースが意図した方法ではありませんが、少なくともマスターをクリーンに保ちます。

リリース時に変更を削除するプロセスは、http://dymitruk.com/blog/2012/02/05/branch-per-feature/の「機能を削除することは、それらを配置するよりも強力である」というタイトルのセクションで、かなり詳しく文書化されています。の"。機能が同じコミットから開始されていない場合、問題が発生する可能性があります (git-flow に従っている場合、おそらくそうではありません)。しかし、あなたはそれを最大限に活用しようとすることができます.

例: インタラクティブなリベース

$ git checkout -b reduced_functionality_branch develop
$ git rebase -i sha1-for-previous-release-point
...remove the stuff you don't want...

この時点で、reduced_functionality_branch には、リリースしたいコミットのみが含まれているはずです。

于 2013-07-30T21:32:27.190 に答える
1

この場合、チェリーピックは実際にうまく機能するはずです。リベースすると、選択した変更が残りの作業の前にコミットされたかのように見えますが、それは任意のリベースで得られるものです。

ただし、CharlesB が言うように、master へのチェリー ピッキングは、git-flow モデルに厳密には準拠していません。しかし、それはそう遠くないことであり、特定の問題を解決するための簡単で優れた方法です。

于 2013-07-29T10:49:26.630 に答える
1

「git cherry-pick」を使用できます

選択的なコミットを行うため、ソース ブランチでのコミットが完了している必要があることに注意してください。マージの競合も発生する可能性があります。

于 2013-07-29T08:44:24.120 に答える
0

dev ブランチと master ブランチの両方で .gitattributes を使用し、コードの下に配置します

<file which is branch specific> merge=ours

以下のコマンドを実行

git config --global merge.ours.driver true

次にブランチをマージすると、次のものを除くすべてのものがマージされます<file which is branch specific>

于 2015-04-17T00:27:07.490 に答える