web-dev-qa-db-ja.com

なぜgit branch --unset-upstreamを呼び出して修正するのですか?

Gitの高度な操作に関しては、私は初心者です。 ブログ ブログフレームワークを使用して Octopress を維持します。 Octopressは2011年以降開発されていませんが、私の目的を十分に果たしているため、これまでのところ何も変更するつもりはありませんでした。

参考までに、私のブログはGithub Pagesでホストされています。

今日、git statusは新しい投稿の作業中に次のメッセージを表示しました。

On branch source
Your branch is based on 'Origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

git add .git commit -m 'message'git Push Origin sourceなど、後続のすべてのコマンドに対して同じメッセージが繰り返されます。

  • メッセージの意味は何ですか?
  • 何か壊れていますか?
  • はいの場合、何ですか?
  • 修正する必要がありますか?

可能であれば、pdf/webの記事を参照してください。この記事を読んで、今後の理解を深めることができます。

詳細:

bash-3.2$ git branch -a
* source
  remotes/octopress/2.1
  remotes/octopress/HEAD -> octopress/master
  remotes/octopress/gh-pages
  remotes/octopress/linklog
  remotes/octopress/master
  remotes/octopress/refactor_with_tests
  remotes/octopress/rubygemcli
  remotes/octopress/site
  remotes/Origin/source

さらに情報が必要な場合はお知らせください。ありがとう。

129
Jatin Ganhotra

TL; DRバージョン:リモート追跡ブランチOrigin/masterは存在していましたが、現在は存在しないため、ローカルブランチsourceは存在しないものを追跡します。 —そして、Gitはそれについて警告しています。 「アップストリームトラッキング」機能が意図したとおりに機能しないまま、うまく機能しているので、何かを変更するかどうかはあなた次第です。

アップストリーム設定の別のテイクについては、 「git Push --set-upstream Origin <branch>」にする必要があるのはなぜですか?


この警告はGitの新しいもので、Git 1.8.5で最初に表示されます。リリースノートには、それに関する短い箇条書き項目が1つだけ含まれています。

  • 「git branch -v -v」(および「git status」)は、他のブランチに基づいていないブランチ、上流のブランチと同期しているブランチ、および上流で構成されているブランチを区別しませんでした存在しないブランチ。

その意味を説明するには、最初に「リモート」、「リモート追跡ブランチ」、およびGitが「アップストリームの追跡」を処理する方法について知る必要があります。 (リモートトラッキングブランチはひどく欠陥のある用語です-リモートトラッキング名を使用し始めました代わりに、これはわずかな改善だと思いますが、以下では、Gitのドキュメントとの一貫性のために「リモートトラッキングブランチ」を使用します。

各「リモート」は、この場合のOriginまたはoctopressのような単なる名前です。それらの目的は、git fetchまたはgit pullを更新する場所の完全なURLなどを記録することです。 git fetch remote,を使用する場合1 Gitは(保存されたURLを使用して)そのリモートに移動し、適切な更新セットを提供します。また、「リモート追跡ブランチ」を使用して、更新をrecordsします。

「リモートトラッキングブランチ」(またはリモートトラッキング名)は、単に「リモート」で最後に見たブランチ名の記録です。各リモートはそれ自体がGitリポジトリであるため、ブランチがあります。リモートの「Origin」のブランチは、remotes/Origin/の下のローカルリポジトリに記録されます。示したテキストは、sourceOriginという名前のブランチがあり、linklog2.1octopressなどの名前のブランチがあることを示しています。

(「通常」または「ローカル」ブランチは、もちろん、自分のリポジトリで作成したブランチ名にすぎません。)

最後に、「リモート追跡ブランチ」を「追跡」するように(ローカル)ブランチを設定できます。ローカルブランチLがリモートトラッキングブランチRを追跡するように設定されると、 GitはRの「アップストリーム」を呼び出し、アップストリームの「先」または「後ろ」にあるかどうかを(コミットに関して)通知します。 sourceOrigin/sourceのように、ローカルブランチとリモートトラッキングブランチが同じ名前(リモートプレフィックス部分を除く)を使用するのは通常です(推奨も可能)が、実際には必要ありません。

そして、この場合、それは起きていません。ローカルブランチsourceがリモートトラッキングブランチOrigin/masterを追跡しています。

howの正確なメカニズムを知る必要はないはずですが、Gitはローカルブランチをセットアップしてリモートブランチを追跡しますが、それらは以下に関連しています。これがどのように機能するかを示します。ローカルブランチ名sourceから始めます。この名前を使用した、branch.source.remotebranch.source.mergeという2つの構成エントリがあります。示した出力から、これらの両方が設定されていることが明らかであるため、特定のコマンドを実行すると次のように表示されます。

$ git config --get branch.source.remote
Origin
$ git config --get branch.source.merge
refs/heads/master

これらをまとめると、2 これは、Gitにブランチsourceが「リモートトラッキングブランチ」Origin/masterを追跡することを伝えます。

しかし、ここでgit branch -aの出力を見てください。これは、リポジトリ内のすべてのローカルおよびリモートトラッキングブランチ名を示しています。リモート追跡名はremotes/ ...の下にリストされ、remotes/Origin/masterはありません。かつてあったと思われますが、今ではなくなっています。

Gitは、--unset-upstreamを使用して追跡情報をremoveできることを伝えています。これにより、branch.source.Originbranch.source.mergeの両方がクリアされ、警告が停止します。

しかし、おそらくあなたが望むのは、Origin/masterの追跡から他の何かの追跡へのswitchである可能性が高いようです:おそらくOrigin/sourceですが、おそらくoctopress/の1つ名前。

git branch --set-upstream-toでこれを行うことができます。3 例えば。:

$ git branch --set-upstream-to=Origin/source

(あなたがまだブランチの「ソース」にいて、Origin/sourceがあなたが望む上流であると仮定します。しかし、もしあれば、どれがあなたが実際に望むかを知る方法はありません)。

既存のGitブランチがリモートブランチを追跡する方法 )も参照してください。

ここで得た方法は、最初にgit cloneを実行したときに、複製元のブランチにmasterがあったと思います。また、Origin/masterを追跡するように設定されたブランチmasterがありました(これはgitの通常の標準セットアップです)。これは、branch.master.remotebranch.master.mergeOriginrefs/heads/masterに設定したことを意味します。しかし、その後、Originリモートの名前がmasterからsourceに変更されました。それに合わせて、ローカル名もmasterからsourceに変更したと思います。これにより、設定のnamesbranch.master.remoteからbranch.source.remoteに変更され、branch.master.mergeからbranch.source.mergeに変更されましたが、古いvalues、そのためbranch.source.mergeは間違っていました。

この時点で「アップストリーム」リンケージが壊れましたが、1.8.5より古いGitバージョンでは、Gitは設定の破損に気付きませんでした。 1.8.5ができたので、これが指摘しています。


それはほとんどの質問をカバーしていますが、「それを修正する必要があるか」という質問はカバーしていません。 git pull remote branchgit pull Origin sourceなど)を実行することで、この数年間、壊れた部分を回避している可能性があります。そうすれば、問題を回避できます。そのため、修正する必要はありませんneed。必要に応じて、--unset-upstreamを使用してアップストリームを削除し、苦情を停止し、ローカルブランチsourceにアップストリームanyのマークを付けないようにすることができます。

アップストリームを持つことのポイントは、さまざまな操作をより便利にすることです。たとえば、git fetchに続いてgit mergeは、アップストリームが正しく設定されている場合、通常「正しいこと」を行い、git statusの後のgit fetchは、そのブランチのリポジトリが上流のものと一致するかどうかを通知します。

利便性が必要な場合は、アップストリームを再設定してください。


1git pullgit fetchを使用し、Git 1.8.4の時点で、これ(最終的に!)は「リモート追跡ブランチ」情報も更新します。古いバージョンのGitでは、git pullを使用した場合のみ、git fetchを使用してリモートトラッキングブランチに更新が記録されませんでした。 Gitは少なくともバージョン1.8.5である必要があるため、これは問題ではありません。

2まあ、これに加えて、remote.Origin.fetchの下にある設定行を意図的に無視しています。 Gitは「マージ」名をマップして、リモートブランチの完全なローカル名がrefs/remotes/Origin/masterであることを把握する必要があります。ただし、マッピングはほとんど常にこのように機能するため、masterOrigin/masterに移動することは予測できます。

3または、git configを使用します。アップストリームをOrigin/sourceに設定したいだけなら、変更する必要があるのはbranch.source.mergeだけで、git config branch.source.merge refs/heads/sourceがそれを行います。しかし、--set-upstream-towhatを手動で実行させるのではなく、あなたがやりたいことを言うので、「より良い方法」です。

172
torek

torekの答えはおそらく完璧ですが、記録には元の質問で説明されたものとは異なる別のケースを言及したかっただけですが、同じエラーが表示されることがあります(同様の問題を持つ他の人を助けるかもしれません):

サーバーの1つでgit init --bareを使用して空の(新しい)リポジトリを作成しました。それから、PC上のローカルワークスペースにgit clonedします。

ローカルリポジトリで1つのバージョンをコミットした後、git statusを呼び出した後にそのエラーが発生しました。

Torekの回答に続いて、ローカル作業ディレクトリリポジトリでの最初のコミットで「マスター」ブランチが作成されたことを理解しています。しかし、(サーバー上の)リモートリポジトリには何も存在しなかったため、「マスター」(リモート/オリジン/マスター)ブランチすらありませんでした。

ローカルリポジトリからgit Push Origin masterを実行した後、リモートリポジトリにマスターブランチができました。これにより、エラーが表示されなくなりました。

結論として、「マスター」を含むブランチがないため、コミットがゼロの新しいリモートリポジトリに対してこのようなエラーが発生する可能性があります。

143
ElazarR

これで問題が解決する場合があります。

変更後、コミットしてから

git remote add Origin https://(address of your repo) it can be https or ssh
then
git Push -u Origin master

それがあなたのために働くことを願っています。

ありがとう

7
Ajay Kotnala

私にとっては、.git/refs/Origin/masterが壊れていました。

私は次のことを行い、問題を解決しました。

rm .git/refs/remotes/Origin/master
git fetch
git branch --set-upstream-to=Origin/master
7
smremde

次のコマンドでローカルブランチを削除します

git branch -d branch_name

あなたもできる

git branch -D branch_name 

これは基本的に削除を強制します(ローカルがソースにマージされていない場合でも)

0
Pravin

この質問は2回ありましたが、それは常にローカルブランチのgitキャッシュファイルの破損が原因でした。不足しているコミットハッシュをそのファイルに書き込むことで修正しました。サーバーから適切なコミットハッシュを取得し、次のコマンドをローカルで実行しました。

cat .git/refs/remotes/Origin/feature/mybranch \
echo 1edf9668426de67ab764af138a98342787dc87fe \
>> .git/refs/remotes/Origin/feature/mybranch
0
user1106400

実際、トレックは、私ができるよりもはるかに優れたツールの使用方法を既に教えてくれました。ただし、この場合、 http://octopress.org/docs/deploying/github/ のガイドラインに従う場合は、奇妙な何かを指摘することが重要だと思います。つまり、セットアップに複数のgithubリポジトリがあります。まず、Webサイトのすべてのソースコードが含まれるディレクトリ($WEBSITEなど)、次に$WEBSITE/_deployに存在する静的生成ファイルのみが含まれます。セットアップの面白い点は、.gitignoreディレクトリに$WEBSITEファイルがあるため、このセットアップが実際に機能することです。

十分な紹介。この場合、エラーは_deployのリポジトリからも発生する可能性があります。

cd _deploy

git branch -a
* master
remotes/Origin/master
remotes/Origin/source

.git/configでは、通常、次のようなものを見つける必要があります。

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "Origin"]
    url = [email protected]:yourname/yourname.github.io.git
    fetch = +refs/heads/*:refs/remotes/Origin/*
[branch "master"]
    remote = Origin
    merge = refs/heads/master

しかし、あなたの場合、ブランチマスターにはリモートがありません。

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "Origin"]
    url = [email protected]:yourname/yourname.github.io.git
    fetch = +refs/heads/*:refs/remotes/Origin/*

あなたが解決できるもの:

cd _deploy
git branch --set-upstream-to=Origin/master

したがって、すべてがtorekに言われたとおりですが、これはWebサイトのルートではなく、_deployディレクトリに関係している可能性があることを指摘することが重要です。

PS:zshのようなシェルをgitプラグインと一緒に使用して、将来この問題に噛まれないようにする価値があるかもしれません。 _deployが別のリポジトリに関係していることがすぐにわかります。

0
Anne van Rossum