web-dev-qa-db-ja.com

開発ブランチのgitコミットを機能ブランチにマージする方法

Gitリポジトリに開発ブランチと機能ブランチがあります。開発にコミットを追加し、そのコミットを機能ブランチにマージしたいと考えています。これをやれば

git checkout feature
git merge develop

最終的にマージコミットになります。開発の新しいコミットを機能ブランチに頻繁にマージするため、これらの不要なマージコミットをすべて回避したいと思います。私はこれを見ました answergit rebase developしかし、最終的にはブランチを巻き戻しすぎてリベースは失敗します。

更新：私がやったことは

git checkout feature
git merge develop # this creates a merge commit that I don't want
git rebase # this gets rid of the merge commit but keeps the commits from develop that I do want
git Push

更新：私はちょうど機能ブランチにマージしてからリベースすると、開発時の元のコミットが異なるハッシュを取得することに気付きました。最終的には機能を開発にマージして、ニースをプレイしないと思うので、私はそれが望んでいるとは思わない。

gitgit-mergegit-rebasefeature-branch
31
gitq

あるブランチを別のブランチに統合するには、マージまたはリベースする必要があります。他の場所で参照されていないコミット（他のローカルブランチにマージされていない、リモートにプッシュされていないコミット）をリベースすることだけが安全であるため、通常はマージする方が適切です。

機能ブランチが純粋にローカルである場合、開発の上にリベースできます。ただし、リベースがどのように機能するかを理解するには時間がかかります。実行する前に、誤って重複したコミットまたはドロップされたコミットを作成することは非常に簡単です。マージコミットはノイズが多いように見えますが、マージは常に安全で予測可能なことが保証されています。

見やすくするために、グラフにすべてを一緒に記録してみてください。

git log --all --graph --oneline --decorate

また、本当に必要developのコミットがfeatureにマージされたかどうかを検討する価値があります。多くの場合、これらは後でfeatureがdevelopにマージされるまで別々にできるものです。

developにfeatureコードが必要であることが定期的にわかっている場合、機能ブランチの実行時間が長すぎることを示している可能性があります。理想的には、機能は、途中で定期的に統合する必要なく、独立して作業できるように分割する必要があります。

30
ben_h

developブランチから1つのコミットだけが必要な場合は、featureブランチでそれをチェリーピックできます：

 git checkout feature
 git cherry-pick -x <commit-SHA1>

コミットはブランチの最上部に新しいものとして適用され（競合が発生しない場合）、featureブランチをマージして戻すと、Gitは競合なしにそれを処理します。

12
CharlesB