160

私は中間の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が、これは単なるプレゼンテーションのことかもしれません。

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

4

5 に答える 5

219

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

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

git push origin feature -f

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

git merge master
git push origin feature

これにより、コラボレーションしている人々と共通の歴史を持つことができます。

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

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

お役に立てれば。

于 2011-06-01T16:49:51.997 に答える
38

このテーマを取り上げてくれてうれしいです。

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

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

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

于 2011-06-01T19:24:00.867 に答える
6

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

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

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

于 2011-06-01T12:19:38.383 に答える
0

私はGitBashの使用に慣れておらず、Windowsを使用している開発者向けにTortoiseGit（newbeesのGUI）を使用して回答を追加しています。

TortoiseGitを使用して、リモートブランチをローカルブランチに強制的にリベースします

上記の多くのように、これは、「プライベート」リポジトリブランチでのみ行う場合です。つまり、リモートの「開発」または「機能」ブランチをローカルコピーでリベースするために、誰もあなたに椅子を投げることはありません。1週間分の（またはそれ以上の）作業をコミットしてプッシュした他の開発者は、ブランチの履歴（ログ）から消去されます。

それらを回復する方法はありません-もちろん、共同開発者は、ブランチの現在の履歴または最新のコミットと彼らのコミットよりもはるかに進んでいるため、PULLがエラーをスローする可能性が高いため、変更を加えたままになります。良いことGitは分散バージョン管理システムです。

したがって、リモートブランチを元に戻すには、この力に注意してください。あなたはここに警告されます。;）

于 2021-11-18T01:26:11.203 に答える
-1

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

于 2011-06-01T10:55:35.963 に答える