私は自分の開発ブランチで開発を行い、本番環境にプッシュする準備ができたらマスターにマージするのが好きです。マスターブランチに何もコミットしない限り、すべてがスムーズに進みます。
しかし、開発ブランチで変更されたものと競合する何かをマスターブランチにコミットした状況に遭遇しました。開発ブランチをマスターにマージするとき、競合を解決する必要があります。大したことではありませんが、開発ブランチがマスターブランチにすべてを持っていることを確認するために（開発が最新であることを確認するために）、マスターブランチをマージして、競合を再度解決する必要があります。
特にあなたが公に押し出しているものにとって、リベースは一般的に悪いと聞きました。
このタイプのセットアップを管理するためのより良い方法はありますか？
マスターから開発ブランチに定期的にマージし、競合を解決します。（これを定期的に行っている場合、競合は通常非常に軽微です。）
マスターへのマージが行われるまでに、開発はまったく競合しないはずです。
技術的に間違っていることよりも、あなたに影響を与えているいくつかの誤解があるかもしれません。
まず、通常、マスターブランチに直接コミットしないでください。あなたがあなたの状況を説明した方法から、それが起こっているかどうかはわかりませんが、起こっている場合は、そうしないようにしてください。
何かをマスターにきれいにマージできないことがわかった場合は、マスター自体で問題を修正しようとしないでください。代わりに、機能ブランチで問題を修正する必要があります。そこで問題を修正したら、マスターにきれいにマージできます。
リベースに関しては、リモートリポジトリにプッシュするまでリベースを使用することはまったく問題ありません。リモートリポジトリに何かをプッシュした後は、リベースしたくありません。他の誰かの履歴を台無しにしているため、gitはそれを実際に解決できません。したがって、リベースを恐れないでください。いつ使用するか、いつ使用しないかを知ってください。
ここでリベースを使用して（問題のブランチをリモートでプッシュしていないと仮定して）問題を解決する方法の1つは、マスターにクリーンにマージできない機能ブランチを取得して、マスターにリベースすることです。これにより、そのブランチの問題を解決するように強制されます。それが解決されたら、マスターへのマージは簡単であり（マスターがその間に再び変更されていない限り）、マスターにきれいにマージできます。
gitで利用できるチュートリアルはたくさんあり、それらにも役立ついくつかの優れたコード例があります。これは、より「古典的な」ものの1つであり、ここで説明するワークフローはうまく機能すると思います。http://nvie.com/posts/a-successful-git-branching-model/
そこでワークフローを半自動化しようとする「gitflow」という名前のbashスクリプトセットを承認していないことに注意してください（これらのスクリプトは、試したときにうまく機能しませんでした）が、そこで説明されているワークフロー自体はうまく機能します。
私がそれをする方法は逆です：
マージ中にすべての競合を解決します。
gitはブランチのマージと処理に関しては優れていますが、3方向の差分/マージツールを使用した手動の面倒な作業以外に、競合を解決するための迅速な方法はないと思います。
また、@ cHaoが以下の回答で述べたことを実行するのに役立ちます。頻繁にマージし、小さくマージします。そうすれば、大きな競合マージの状況はほとんど発生しません。
私が言えることから、開発はすべての新しいことが起こる場所です。したがって、その場合は、開発から分岐します（機能分岐）。そのブランチで作業します。完了したら、開発を機能ブランチにマージして、最新であることを確認します。次に、開発ブランチをチェックアウトし、機能ブランチをそれにマージします。チームのメンバーが開発ブランチに機能を追加し続けると、ある時点でマネージャーは次のようokay, we're releasingになります。その時点で、マスターを開発にマージし（誰かがマスターに不正なコミットを行った場合に備えて）、チェックアウトします。マスターとマージはそれに発展します。
うまくいけば、誰も直接開発したり習得したりすることを約束しません。これらの2つはにマージされるだけです。また、機能の開発中とマージ後のテストがあることを願っています。
関係する限りrebase、はい、彼らはあなたがあなたのブランチを共有した後にそれをしないと言います。したがって、この場合、共有されているため、開発ブランチでは実行しません。
そうです
git checkout master
git reset --hard dev
したがって、マスターは正確に開発者になります。マスターでホットフィックスを送信する場合は、devをリベースすることを忘れないでください。