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
さらに情報が必要な場合はお知らせください。ありがとう。
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/
の下のローカルリポジトリに記録されます。示したテキストは、source
にOrigin
という名前のブランチがあり、linklog
に2.1
、octopress
などの名前のブランチがあることを示しています。
(「通常」または「ローカル」ブランチは、もちろん、自分のリポジトリで作成したブランチ名にすぎません。)
最後に、「リモート追跡ブランチ」を「追跡」するように(ローカル)ブランチを設定できます。ローカルブランチL
がリモートトラッキングブランチR
を追跡するように設定されると、 GitはR
の「アップストリーム」を呼び出し、アップストリームの「先」または「後ろ」にあるかどうかを(コミットに関して)通知します。 source
やOrigin/source
のように、ローカルブランチとリモートトラッキングブランチが同じ名前(リモートプレフィックス部分を除く)を使用するのは通常です(推奨も可能)が、実際には必要ありません。
そして、この場合、それは起きていません。ローカルブランチsource
がリモートトラッキングブランチOrigin/master
を追跡しています。
howの正確なメカニズムを知る必要はないはずですが、Gitはローカルブランチをセットアップしてリモートブランチを追跡しますが、それらは以下に関連しています。これがどのように機能するかを示します。ローカルブランチ名source
から始めます。この名前を使用した、branch.source.remote
とbranch.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.Origin
とbranch.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.remote
とbranch.master.merge
をOrigin
とrefs/heads/master
に設定したことを意味します。しかし、その後、Origin
リモートの名前がmaster
からsource
に変更されました。それに合わせて、ローカル名もmaster
からsource
に変更したと思います。これにより、設定のnamesがbranch.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 branch
(git pull Origin source
など)を実行することで、この数年間、壊れた部分を回避している可能性があります。そうすれば、問題を回避できます。そのため、修正する必要はありませんneed。必要に応じて、--unset-upstream
を使用してアップストリームを削除し、苦情を停止し、ローカルブランチsource
にアップストリームanyのマークを付けないようにすることができます。
アップストリームを持つことのポイントは、さまざまな操作をより便利にすることです。たとえば、git fetch
に続いてgit merge
は、アップストリームが正しく設定されている場合、通常「正しいこと」を行い、git status
の後のgit fetch
は、そのブランチのリポジトリが上流のものと一致するかどうかを通知します。
利便性が必要な場合は、アップストリームを再設定してください。
1git pull
はgit fetch
を使用し、Git 1.8.4の時点で、これ(最終的に!)は「リモート追跡ブランチ」情報も更新します。古いバージョンのGitでは、git pull
を使用した場合のみ、git fetch
を使用してリモートトラッキングブランチに更新が記録されませんでした。 Gitは少なくともバージョン1.8.5である必要があるため、これは問題ではありません。
2まあ、これに加えて、remote.Origin.fetch
の下にある設定行を意図的に無視しています。 Gitは「マージ」名をマップして、リモートブランチの完全なローカル名がrefs/remotes/Origin/master
であることを把握する必要があります。ただし、マッピングはほとんど常にこのように機能するため、master
がOrigin/master
に移動することは予測できます。
3または、git config
を使用します。アップストリームをOrigin/source
に設定したいだけなら、変更する必要があるのはbranch.source.merge
だけで、git config branch.source.merge refs/heads/source
がそれを行います。しかし、--set-upstream-to
はwhatを手動で実行させるのではなく、あなたがやりたいことを言うので、「より良い方法」です。
torekの答えはおそらく完璧ですが、記録には元の質問で説明されたものとは異なる別のケースを言及したかっただけですが、同じエラーが表示されることがあります(同様の問題を持つ他の人を助けるかもしれません):
サーバーの1つでgit init --bare
を使用して空の(新しい)リポジトリを作成しました。それから、PC上のローカルワークスペースにgit clone
dします。
ローカルリポジトリで1つのバージョンをコミットした後、git status
を呼び出した後にそのエラーが発生しました。
Torekの回答に続いて、ローカル作業ディレクトリリポジトリでの最初のコミットで「マスター」ブランチが作成されたことを理解しています。しかし、(サーバー上の)リモートリポジトリには何も存在しなかったため、「マスター」(リモート/オリジン/マスター)ブランチすらありませんでした。
ローカルリポジトリからgit Push Origin master
を実行した後、リモートリポジトリにマスターブランチができました。これにより、エラーが表示されなくなりました。
結論として、「マスター」を含むブランチがないため、コミットがゼロの新しいリモートリポジトリに対してこのようなエラーが発生する可能性があります。
これで問題が解決する場合があります。
変更後、コミットしてから
git remote add Origin https://(address of your repo) it can be https or ssh
then
git Push -u Origin master
それがあなたのために働くことを願っています。
ありがとう
私にとっては、.git/refs/Origin/master
が壊れていました。
私は次のことを行い、問題を解決しました。
rm .git/refs/remotes/Origin/master
git fetch
git branch --set-upstream-to=Origin/master
次のコマンドでローカルブランチを削除します
git branch -d branch_name
あなたもできる
git branch -D branch_name
これは基本的に削除を強制します(ローカルがソースにマージされていない場合でも)
この質問は2回ありましたが、それは常にローカルブランチのgitキャッシュファイルの破損が原因でした。不足しているコミットハッシュをそのファイルに書き込むことで修正しました。サーバーから適切なコミットハッシュを取得し、次のコマンドをローカルで実行しました。
cat .git/refs/remotes/Origin/feature/mybranch \
echo 1edf9668426de67ab764af138a98342787dc87fe \
>> .git/refs/remotes/Origin/feature/mybranch
実際、トレックは、私ができるよりもはるかに優れたツールの使用方法を既に教えてくれました。ただし、この場合、 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
が別のリポジトリに関係していることがすぐにわかります。