完全にGitでローカルブランチをリモートブランチに置き換える方法は?


779

私には2つのブランチがあります。

  1. ローカルブランチ(私が作業しているブランチ)
  2. リモートブランチ(パブリック、十分にテストされたコミットのみがそこに行きます)

最近、私は真剣に私の地元の支店をめちゃくちゃにしました。

ローカルブランチをリモートブランチに完全に置き換えて、リモートブランチが現在ある場所から作業を続行するにはどうすればよいですか?

私はすでにSOを検索しましたが、リモートブランチにローカルでチェックアウトしても効果がありません。


1
承認された回答には1280の賛成票があることはわかっていますが、承認された回答を@TTTによるものに変更することを検討する必要があります。
— ジェイミー

回答:


1289
  1. 置換するブランチをチェックアウトしたことを確認してください(Zoltánのコメントから)。
  2. masterが置き換えるローカルブランチであり、 "origin / master"がリセット先のリモートブランチであると仮定します。

    git reset --hard origin/master
    

これにより、ローカルのHEADブランチがorigin / masterと同じリビジョンになるように更新--hardされ、この変更がインデックスとワークスペースにも同期されます。


4
あなたの提案をありがとう、私はすでに--hardと--forceを使用するのがとても怖いので、それらを使用しないソリューションを選びました。
— YemSalat

13
@KonstantinLevin:ああ、そうです、これらのオプションの名前はかなりイライラします。git resetデフォルトでは、現在のブランチを再ポイントし、インデックスを同期します。--softインデックスの更新をスキップし--hard、ワークスペースも同期します。私自身の経験では--hard、最後のコミットを取り消す場合を除いて、ほとんどの時間を使用しています(これは単なるgit reset HEAD^)
— araqnid

9
gitの経験が増えた後、これはより良いソリューションであると確信しています。
— YemSalat 2013

24
おそらく最初にフェッチする必要があるでしょう:git fetch origin remote_branch
— b1r3k 14

53
これにより、現在のブランチがmasterのコンテンツで置き換えられることに注意してください。したがって、たとえば機能ブランチを使用している場合は、すべてのコミットがに置き換えられます。そのmasterため、最初に置き換えるブランチをチェックアウトしていることを確認してください。
— ゾルタン

218

これは3つのステップと同じくらい簡単です。

  1. ローカルブランチを削除します。 git branch -d local_branch
  2. 最新のリモートブランチを取得します。 git fetch origin remote_branch
  3. リモートブランチに基づいてローカルブランチを再構築します: git checkout -b local_branch origin/remote_branch

7
実際、@ araqnidの発言は正しく、より簡潔です。私はそれをテストしました、そしてあなたもそれを試すかもしれません。
— アダムスミス

うわー、git checkout -b local_branch origin / remote_branchは素晴らしいです!私はいつもこれを2つの別々のコマンドで行いました。ありがとう!
— ケンデペルチン2013

11
git branch -D local_branchブランチがマージされていない場合は、最初のステップで行う必要があるかもしれません。
— szeryf 2013

おかげで、私はgitflowを使用するときに苦労しました、ブランチを公開してから終了した後、削除されたブランチに移動したいと思いました。うまく利用していない
— Decebal 2014

2
現在のブランチが削除されるブランチではないことを確認する必要があります。
— a_secenthusiast 2016

43
git branch -D <branch-name>
git fetch <remote> <branch-name>
git checkout -b <branch-name> --track <remote>/<branch-name>

--trackパーツは何をしますか?
— eonist 2017

3
@GitSync、これはについてgit help branch語ってい--trackます。When creating a new branch, set up branch.<name>.remote and branch.<name>.merge configuration entries to mark the start-point branch as "upstream" from the new branch. This configuration will tell git to show the relationship between the two branches in git status and git branch -v. Furthermore, it directs git pull without arguments to pull from the upstream when the new branch is checked out. 私は答えでこのコマンドを修正しました。ポイントを上げてくれてありがとう。
— Sailesh 2017

つまり、簡単に言えば、リモートURLが新しいブランチに追加されます。だから彼らはいつまでも同期している。いわば。
— eonist 2017

2
便宜上のものと言えます。行うgit status場合、ローカルブランチが関連付けられている場合、ローカルブランチがリモートブランチの前か後ろかを報告します。さらに、ブランチをすでに追跡するように設定している場合は、完全ではなくgit pull(またはpush)を実行できます。git pull <remote> <branch><remote/branch>
— Sailesh 2017

22

すべてをリモートブランチに置き換えます。しかし、同じコミットからのみ、ローカルブランチがオンになっています:

git reset --hard origin/some-branch

または、リモートブランチから最新のものを取得し、すべてを置き換えます。

git fetch origin some-branch
git reset --hard FETCH_HEAD

余談ですが、必要に応じて、まだコミットしていない追跡されていないファイルとディレクトリを一掃できます。

git clean -fd

git cleanコマンドは私のためにそれをやりました。git reset hard origin/master追跡されていないファイルを消去しないでください。ありがとう!
— Mornor

9

現在のローカルブランチをリモートに置き換える最も安全で完全な方法:

git stash
git merge --abort
git rebase --abort
git branch -M yourBranch replaced_yourBranch
git fetch origin yourBranch:yourBranch
git checkout yourBranch

このstash行は、コミットしていない変更を保存します。このbranch行により、ブランチが別の名前に移動し、元の名前が解放されます。このfetch行は、リモートの最新のコピーを取得します。のcheckout行は、元のブランチを追跡ブランチとして再作成します。

またはbash関数として:

replaceWithRemote() {
    yourBranch=${1:-`git rev-parse --abbrev-ref HEAD`}
    git stash
    git merge --abort
    git rebase --abort
    git branch -M ${yourBranch} replaced_${yourBranch}_`git rev-parse --short HEAD`
    git fetch origin ${yourBranch}:${yourBranch}
    git checkout ${yourBranch}
}

これにより、現在のブランチの名前がreplaced_master_98d258fなどに変更されます。


git stash popそのワークフローに含めたい場合があります。隠しておいたファイルを再適用する場合。
— eonist 2017

隠されたブランチをどうしますか?それが何のためにあったのかを忘れてしまった後、それは将来どこかで再びポップアップするのではないでしょうか。
— Scott Biggs

1
@ScottBiggs stashされたブランチを削除する場合は、「git stash clear」を使用します。
— マークA.ダーラム

4

まだ誰もこれについて言及していません。私はそれをほぼ毎日使用しています:

git reset --hard @{u}

基本的に@{u}は、現在のブランチが追跡している上流ブランチの単なる省略形です。たとえば、これは通常に相当しorigin/[my-current-branch-name]ます。それはブランチにとらわれないのでいいです。

git fetch最初に、リモートブランチの最新のコピーを取得してください。


1
見栄えがいいので、リセットするブランチの名前をコピーして貼り付けるのに飽きました!
— pedroct92

1
古い質問に回答を追加した例がいくつかありましたが、私の回答はリーダーボードで上手くいきました。私はこれがそうであることを望みます。
— ジェイミー

3

それは複数の方法で行うことができ、より良い知識の観点を広めるためにこの回答を編集し続けます。

1)ハードリセット

リモート開発ブランチから作業している場合は、以下のようにリモートブランチの最後のコミットにHEADをリセットできます。

git reset --hard origin/develop

2)現在のブランチを削除し、リモートリポジトリから再度チェックアウトする

ローカルリポジトリの開発ブランチで作業していて、リモート/開発ブランチと同期していることを考慮して、次のように実行できます。

git branch -D develop
git checkout -b develop origin/develop

3)マージを中止

間違ったマージの間に(間違ったブランチで誤って行われた)間で、マージが次のように最新のブランチに戻るのを避けたい場合:

git merge --abort

4)リベースを中止

不正なリベースの間にいる場合は、以下のようにリベース要求を中止できます。

git rebase --abort

2

@Laurentの@Hugoが言ったように行うことができます。またはgit rebase、コミットを削除するために使用して、コミットがわかっている場合は削除することができます。私はgit rebase -i head~Nこの種の操作に使用する傾向があります(Nは数値であり、最後のN回のコミットを操作できます)。


実際、すべてを台無しにしたのは 'git rebase'コマンドでしたが、いくつかの強制的なマージとハードリセットを行いました。
— YemSalat

2

選択した答えは絶対に正しいですかが、それは、最新のコミット/プッシュで私を残していませんでした、...

だから私にとって:

git reset --hard dev/jobmanager-tools
git pull  ( did not work as git was not sure what branch i wanted)

私は上流のブランチを数週間、特定のブランチに一時的に設定することを知っているので(以前に切り替えた/チェックアウトしたハードリセットを実行したブランチと同じ)

したがって、リセット後

git branch --set-upstream-to=origin/dev/jobmanager-tools
git pull
git status    ( says--> on branch  dev/jobmanager-tools 

1

現在チェックアウトされていないブランチを更新したい場合は、次のようにします。

git fetch -f origin rbranch:lbranch

0

選択した説明で提供されているように、git resetは適切です。しかし、最近ではサブモジュールを使用することがよくあります:リポジトリ内のリポジトリ。たとえば、プロジェクトでZF3とjQueryを使用している場合、おそらくそれらを元のリポジトリから複製する必要があります。このような場合、git resetでは不十分です。サブモジュールを、リポジトリで定義されている正確なバージョンに更新する必要があります。

git checkout master
git fetch origin master
git reset --hard origin/master
git pull

git submodule foreach git submodule update

git status

これは、各サブモジュールの作業ディレクトリに再帰的に移動(cd)して実行するのと同じです。

git submodule update

そしてそれは非常に異なります

git checkout master
git pull

サブモジュールはブランチではなくコミットを指すためです。

その場合、1つ以上のサブモジュールのブランチを手動でチェックアウトすると、実行できます

git submodule foreach git pull

特にこの古い質問に答えるとき、説明を提供してください。あなたの答えはそのままでは役に立ちません。
— エリックA

受け入れられた答えはすでに提案していgit reset --hardます。これはほとんど価値を追加しません。
— florisla

0
git reset --hard
git clean -fd

これは私にとってはうまくいきました-クリーンはそれが削除したすべてのファイルも示しました。変更が失われることが通知された場合は、隠しておく必要があります。


-6

醜いがより簡単な方法:ローカルフォルダーを削除し、リモートリポジトリのクローンを再度作成します。


10
または、ブランチを削除して再度チェックアウトします。
— laurent

— うん

2
醜いことは時々知っておくと便利です。人々が従来の方法ではないという理由だけで人々が投票しないことを望みます:投票にもっと合理的な理由があるに違いありません...そしてそれは与えられるべきです。Gitは結果を出すものです。それはある種の神聖な文章ではありません。
— マイクげっ歯類

3
私は反対票を理解していません:-(はい、それは優雅ではありません、などですが、いくつかのケースで最もよく機能します...申し訳ありません@Hugo
— silverdr '10

@Hugo、同意。私のローカル開発ブランチに不思議で臭いがしました。チームリーダーとエンジニアリングマネージャーの両方が、より洗練されたソリューションの中で、(機能の作業を圧縮、コピー、保存して)ローカルリポジトリをnukeして再クローンすることを提案しました。
— AmitaiB
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.