gitflowを使用するときにクリーンなgit履歴を維持する-開発時のマージされていないコミット

gitflowを使用すると、release-1.0.0ブランチを作成してそれを両方masterとにマージするとdevelop、両方のブランチでコミットが失われます。

• masterrelease-1.0.0マージ先のコミットはありませんdevelop
• developrelease-1.0.0マージ先のコミットはありませんmaster

代わりに、後にhotfix-1.0.1作成され、にマージmasterマージされているとき、develop、マージにコミットコミットどこ以前に含まれますrelease-1.0.0にマージされましたmaster。したがって、次のようになります。

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

この音が混乱した場合、あなたは簡単にあなたが見るこのeverytieが気づくことができdevelop、通常の背後にあるコミットのカップルであるmaster（たとえ開発し、理論的には、必要があるだけで、それはメインブランチだから先になる。これらのコミットからマージされるrelease-x.x.xまでmaster）。

クリーンな履歴を維持するには、これをどのように処理する必要がありますか？

私は、2つの「メイン」ブランチを持たないようにするのが良い方法だと思います。マスターと開発は一種の冗長です。ここでcactus-flowは、作者がブランド化した完全な説明があります。

git-flowとは対照的に、いくつかの点が際立っています。

• たった1つの本店
• 早送りマージのみ

私にとって最後の1つは重要です。なぜなら、git-flowを長い間使用した後でも、--no-ffマージについて何が有用かわかりません。

ドキュメントにできるだけ近いgitflowをフォローしようとしています。gitflowはすでに多くの多くの開発者によって採用されているので、彼らはすでにこの単純なことの解決策を持っているはずなので、私は「ハック」のようなことをしたくない

私見それはあなたの大きな間違いです。可能な限りgit-flowを使用する理由はありません。それは何千ものプロジェクトで使用されるかもしれませんが、それはあなたのプロジェクトに影響を与えません、それはそれを良くしません。

Git-flowは良い出発点ですが、逆にではなく、ツールとワークフローにそれを適合させることを考える必要があります。