Gitでのリモートブランチのリベース

私は中間のGitリポジトリを使用して、リモートSVNリポジトリをミラーリングしています。そこから、人々はクローンを作成して作業できます。中間リポジトリでは、マスターブランチが上流のSVNから毎晩リベースされており、機能ブランチに取り組んでいます。例えば：

remote:
  master

local:
  master
  feature

私は機能ブランチをリモートに正常にプッシュして戻すことができ、期待どおりの結果になります。

remote:
  master
  feature

local:
  master
  feature

次に、ブランチを再セットアップしてリモートを追跡します。

remote:
  master
  feature

local:
  master
  feature -> origin/feature

そして、すべてが順調です。ここで私がしたいことは、リモートで機能ブランチをマスターブランチにリベースすることですが、ローカルマシンからこれを実行したいと思います。私ができるようにしたい：

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

リモート機能ブランチをリモートマスターで最新の状態に保つため。ただし、この方法ではGitが文句を言います。

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pullトリックを行いますが、私が避けたいマージコミットを引き起こします。私は、メッセージが述べていることを懸念してるfeature -> featureのではなく、feature -> origin/featureこれは単にプレゼンテーションものになるかもしれませんね。

私は何かを見逃しているのですか、それとも完全に間違った方法でこれを行っていますか？リモートサーバーでリベースを実行することを回避することは重要ではありませんが、リベースからのマージの競合を修正することがはるかに困難になります。

これは、その機能が1人で使用されているのか、それとも他の人が使用しているのかによって決まります。

それがあなただけの場合、リベース後にプッシュを強制できます。

git push origin feature -f

ただし、他の人がそれに取り組んでいる場合は、マスターからマージしてリベースしないでください。

git merge master
git push origin feature

これにより、協力している人々と共通の歴史を持つことができます。

別のレベルでは、バックマージを行うべきではありません。あなたがしているのは、機能ブランチの履歴を機能に属していない他のコミットで汚染し、そのブランチでのその後の作業をより困難にします-リベースするかどうか。

これは、機能ごとのブランチと呼ばれるテーマに関する私の記事です。

お役に立てれば。

この件を取り上げてよかったです。

これは、多くのgitユーザーが知ることから利益を得ることになるgitの重要なこと/概念です。git rebaseは非常に強力なツールで、コミットをまとめたり、コミットを削除したりすることができます。しかし、他の強力なツールと同様に、基本的に何をしているのかを知っている必要があります。

ローカルで作業していて、ローカルブランチをいじり回しているときは、変更を中央リポジトリにプッシュしていなければ、好きなことを行うことができます。つまり、自分の履歴を書き換えることはできますが、他の履歴を書き換えることはできません。ローカルのものをいじるだけで、他のリポジトリに影響を与えることはありません。

このため、いったんコミットをプッシュしたら、後でそれらをリベースしないでください。これが重要な理由は、他の人があなたのコミットを引き入れて、コードベースへの貢献に基づいて作業を行う可能性があるためです。後でそのコンテンツをある場所から別の場所に移動（リベース）してプッシュすることにした場合変更すると、他の人が問題を抱え、コードをリベースする必要があります。1000人の開発者がいるとしましょう:)それは多くの不必要なやり直しを引き起こすだけです。

feature新しいに基づいてリベースしたためmaster、ローカルfeatureはorigin/featureもはや早送りではありません。したがって、この場合、を実行して早送りチェックをオーバーライドすることは完全に問題ないと思いますgit push origin +feature。これを設定で指定することもできます

git config remote.origin.push +refs/heads/feature:refs/heads/feature

他の人がの上で作業している場合origin/feature、彼らはこの強制更新によって邪魔されます。リベースの代わりに新しいmasterをマージすることでそれを回避できfeatureます。結果は確かに早送りになります。

--forceへのオプションを使用して、チェックを無効にすることができます（本当に何をしているのか本当にわかっている場合）git push。