2

たとえば、すべてを「バージョン1.0完了」としてコミットし、機能を追加したいnewfeature場合は、「ホットフィックス」または「クイックフィックス」が必要な場合にブランチを作成することをお勧めします。 "、masterブランチとブランチを切り替えることができnewfeatureます。

しかし、例では、操作は次のとおりです。

git checkout master
git checkout -b hotfix

// now do any fix that is needed in Emacs

git commit -am "finished hot fix"
git checkout master
git merge hotfix
git branch -d hotfix       // delete the hotfix branch

問題は、hotfix作成して、すべてのマージと削除を実行する必要があるということhotfixです。ブランチに切り替えてmaster修正を行い、コミットしてみませんか？それだけですか？hotfixブランチを作成する正当な理由はありますか？

4

3 に答える 3

1

それは完全にあなた次第です。

修正のサイズに応じて選択するのが良い戦略だと思います。優れた開発者が1つまたは2つのファイル（それぞれに数行）を変更することが予想される場合は、マスターブランチで変更できます。

ただし、一方で、プロジェクトに取り組んでいる開発者が100人いて、新しい開発者が多くの作業、10以上のファイル、100以上の行の変更を意味する可能性のある修正プログラムを提供する必要がある場合は、おそらくより良いでしょう。そして、ホットフィックスブランチを作成する方が快適です（そして、それを削除することは、役に立たなくなり、面倒になるので、良い習慣です）。

特定のブランチが必要かどうかを判断する基準は、これらのケースの間のどこかにあり、あなた（またはあなたの管理者）の決定です。

同時に異なる修正/機能に取り組んでいて、それらが競合している場合（たとえば、構成が異なる場合、または1つがコンパイルされなくなった場合など）、便利なもう1つのケースがあります。

于 2012-08-29T09:06:14.190 に答える
1

マスターブランチを開発ブランチとして使用している場合、私の意見では、ホットフィックス用に別のブランチを作成することはできません。しかし、このような分岐モデルを使用している場合は、非常に便利です。

彼らは別々の開発ブランチとマスターブランチを使用しています。マスターブランチは、リリースバージョンのタグ付け専用です。したがって、顧客に問題があり、修正プログラムを実行したい場合は、マスターリリースタグから修正プログラムブランチを作成できます。したがって、修正プログラムは通常の開発ブランチから完全に切り離され、顧客は必要なもの、つまり修正プログラムのみを入手できます。

ブランチのマージと削除も問題ありません。--no-ffを使用している場合は、マージがあったことを再構築できます。

于 2012-08-29T09:06:23.693 に答える
1

ある種のgitワークフローを探しているようです。@nvieとして知られているVincentDriessenによるgit分岐モデルと、彼が作成したツールgit-flowもお勧めします。これは本当にgitを操作するエレガントな方法です、あなたは本当にそれを試す必要があります。

于 2012-08-29T10:26:49.410 に答える