5

マージのみのワークフローを、より頻繁にリベースを使用するように変更することを考えています。この特定のケースでは、私は唯一の開発者ですが、複数のプラットフォームで作業しており、多くの場合、プラットフォーム固有の部分について同じファイルを編集し、通常は競合しない変更を加えています。しかし、git merge と git rebase との安全性についての議論があるため、これについては少し確信が持てません (たとえば、thisthis 、質問の上位 2 つの回答を参照してください)。

質問:「安全」を目標にしながら、可能な限りクリーンなプル/リベース/マージを行うには、次のような方法があります。

  • プッシュされていないコミットがある場合は、git pull --rebaseローカル履歴と競合する最初のマージ操作まで。
  • 次にgit pull --no-rebase、残りをマージして競合解決を行います。
  • 履歴の並行部分をできるだけ短く保つために、競合しない最後の変更のリベースに戻る可能性があります。

したがって、競合がなければ、最終結果はリベースと優れた線形履歴でプルされます。競合がある場合、マージは表示されますが、並行履歴はできるだけ短くなります。

これは、適切なスイッチ (プル スクリプトまたはエイリアスに書き込むことができる) を使用して、1 つまたは 2 つの単純なプレーン git コマンドで可能ですか? そうでない場合、既存のツールで可能ですか?

この質問の別の見方: rebaseまたはmergeを選択する決定を自動化したいので、 pullを実行するときにその詳細について考える必要はありません。

また、これは意味がありますか?:)

4

1 に答える 1

2

私はあなたが提案していることに従います。最初にリベースを試みます。競合がなければ機能し、履歴はよりクリーンになります。競合がある場合は、マージを行います。

唯一の違いは、3 番目の箇条書きで提案されているように、1 つのプルのコミット間でマージとリベースを分割しようとしないことです。実際、それが理にかなっているのかどうかさえわかりません。rebase continue競合を処理し、競合を解決するときに行うことと同じように思えます。結果は、競合のあるリベースと同じになります。

プッシュする必要がある変更がある場合。リベースを行うか、競合がある場合はマージを行います。

于 2013-10-09T13:30:57.100 に答える