マージのみのワークフローを、より頻繁にリベースを使用するように変更することを考えています。この特定のケースでは、私は唯一の開発者ですが、複数のプラットフォームで作業しており、多くの場合、プラットフォーム固有の部分について同じファイルを編集し、通常は競合しない変更を加えています。しかし、git merge と git rebase との安全性についての議論があるため、これについては少し確信が持てません (たとえば、thisとthis 、質問の上位 2 つの回答を参照してください)。
質問:「安全」を目標にしながら、可能な限りクリーンなプル/リベース/マージを行うには、次のような方法があります。
- プッシュされていないコミットがある場合は、
git pull --rebase
ローカル履歴と競合する最初のマージ操作まで。 - 次に
git pull --no-rebase
、残りをマージして競合解決を行います。 - 履歴の並行部分をできるだけ短く保つために、競合しない最後の変更のリベースに戻る可能性があります。
したがって、競合がなければ、最終結果はリベースと優れた線形履歴でプルされます。競合がある場合、マージは表示されますが、並行履歴はできるだけ短くなります。
これは、適切なスイッチ (プル スクリプトまたはエイリアスに書き込むことができる) を使用して、1 つまたは 2 つの単純なプレーン git コマンドで可能ですか? そうでない場合、既存のツールで可能ですか?
この質問の別の見方: rebaseまたはmergeを選択する決定を自動化したいので、 pullを実行するときにその詳細について考える必要はありません。
また、これは意味がありますか?:)