中間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
これにより、共同作業をしている人々と共通の歴史を持つことが保証されます。
別のレベルでは、逆マージを行うべきではありません。あなたがしているのは、機能ブランチの履歴を、その機能に属さない他のコミットで汚染し、リブランチの有無に関係なく、そのブランチでの後続の作業をより困難にすることです。
これは branch per 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
に使用することで、チェックを無効にすることができます(本当に自分が何をしているのか確かな場合)。