26

私はgitブランチモデルに頭を悩ませようとしてきました。私はいくつかのアイデアについてhttp://nvie.com/posts/a-successful-git-branching-model/を見ていて、Subversionから来て、私が本当に楽しみにしていたことの1つは、1か所で変更を加えることでした。それを必要としたすべてのブランチにマージします。Subversionでは、コードのコピーを大量に作成することになりました。

しかし、私はまだこれを完全には理解していません。これが私が持っている標準的なタイプのワークフローであり、常に競合が発生します。

# create new version branch
git checkout master
git checkout -b v3
vim pom.xml  # change branch version to "3.1-SNAPSHOT"
git commit -a
git checkout master
vim pom.xml  # change master version to "4.0-SNAPSHOT"
git commit -a

したがって、マスターは4.0-SNAPSHOTにあり、ブランチは3.1-SNAPSHOTにあります。

ブランチにホットフィックスを作成してトランクに移動したくありません。

git checkout v3
git checkout -b hotfix
vim file.txt  # make a bugfix change
git commit -a
git checkout v3
git merge hotfix  # this works fine
git checkout master
git merge hotfix  # this has a conflict since both branches have changed the version

私はそれが起こっている理由を理解しており、それは理にかなっています。これを行うためのより良い方法はありますか？

私はチェリーピックについて読みました。これは私がテストして機能しました。

git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868

ただし、これを処理する「正しい」方法とは思えません。助言がありますか？

4

4 に答える 4

28

それについて超技術的になりたい場合は、共通の祖先から修正プログラムを作成できます。

git merge-base v3 master
git checkout -b hotfix <whatever you got from merge-base>
# make your fix
git checkout v3 && git merge --no-ff hotfix
git checkout master && git merge --no-ff hotfix

        v3--------v3 (hotfixed)
       /         /
ancestor----hotfix
       \         \
        master----master (hotfixed)

フラグは、 Gitがマージコミットを作成し、ラベルをまたはにプルする代わりに、ホットフィックスのヒントにブランチラベルを--no-ff保持することを強調するためにあります。（ブランチには、またはにないコミットが1つあるため、フラグを省略して同じ動作を得ることができます。詳細については、ドキュメントを参照してください。）hotfixv3masterhotfixmasterv3

個人的には、それはやり過ぎだと思います。gahooaを使用します。ブランチで意味のあるホットフィックスを作成してから、ブランチを相互に関連付ける方法に応じて、マージまたはチェリーピックします。

于 2012-05-25T21:58:05.137 に答える
13

本当に、あなたの答えは、ツリーを同じ履歴に基づいて作成するかどうかによって異なります...たとえば、4.0 は最新の 3.X + 4.0 のすべての変更に基づいています...

個人的には、新しいバージョンの新しいブランチを開始することに決めたら、お勧めしません。ある時点で、ソフトウェアは別の方向を向いているため、ブランチもそうすべきです。

これはgit cherry-pickあなたの理想的な解決策として残ります。最も意味のあるブランチに変更を加えてから、古いバージョンにチェリーピックします。これは、古いブランチをチェックアウトして同じ変更を手動で適用し、新しいコミットを行った場合と同じです。それはそれをきれいに保ちます。

Git のマージまたはリベースは、ブランチの履歴をそれぞれ独自の方法で統合しようとしますが、これはバグ修正などをバックポートするときに望ましくないと思われます...

于 2012-05-25T21:16:44.513 に答える
1

ブランチ「4.0」で作業していて、「3.1」を修正する必要がある場合は、「3.1」をコミットした後に「4.0」をリベースできます。

機能ブランチ 4.0 にいることを確認します。 

git checkout 4.0

現在の作業を保存して、他のブランチをチェックアウトできるようにします。 

git stash  
git checkout 3.1

編集してコミットします。

git commit -a -m "bug fix"  
git checkout 4.0

変更を元に戻します:

git stash apply

4.0 を変更して、"3.1" の現在のヘッドから分岐するようにします。 

git rebase "3.1"
于 2012-05-25T21:12:02.200 に答える
0

私もこの質問に苦労してきました。バージョニング戦略を少し変更したい場合 (つまり、Maven が推奨する -SNAPSHOT バージョンから離れる場合)、これは固定バージョンを使用することで解決できると思います (マスター（または開発ブランチが何であれ）のSNAPSHOTまたは0.0.0-SNAPSHOTなど）。(Maven を使用している場合、SNAPSHOT サフィックスは重要です。Maven は SNAPSHOT バージョン管理されたアーティファクトを他のアーティファクトとは異なる方法で扱うためです。)

実際、プロダクション ブランチ (リリースをビルドするブランチ) またはリリースのみを目的としたブランチ (たとえば、バージョン番号の変更) のバージョン番号のみを変更するというポリシーを制定することをお勧めします。開発ブランチにマージするつもりはありません。

私はまだこの戦略を実際に使用していませんが、ちょうどそれについて考えていたので、試してみようと思います.

于 2015-07-31T19:46:27.663 に答える