Git Pushエラー「[remote rejected] master - > master(ブランチは現在チェックアウトされています)」
昨日、 Git リポジトリをあるマシンから別のマシンにクローンする方法について質問しました。どのようにして別のマシンからクローンをgitできますか。。
私は今私のソース(192.168.1.2)から私の行き先(192.168.1.1)へGitリポジトリをうまくクローンすることができます。
しかし、私がファイル、git commit -a -m "test"
およびgit Push
を編集したとき、私は目的地(192.168.1.1)でこのエラーに遭遇します。
git Push
hap@192.168.1.2's password:
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error:
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to Push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'
私はGitの2つの異なるバージョンを使用しています(リモートでは1.7、ローカルマシンでは1.5)。それが考えられる理由ですか。
あなたは単にあなたのリモートリポジトリをベアリポジトリに変換することができます(ベアリポジトリに作業コピーはありません - フォルダは実際のリポジトリデータのみを含みます)。
リモートリポジトリフォルダで次のコマンドを実行します。
git config --bool core.bare true
そのフォルダ内の.git
以外のすべてのファイルを削除します。そして、エラーなしでリモートリポジトリに対してgit Push
を実行することができます。
Git を学び始めたときに同じエラーが発生しました。他の答えのいくつかは明らかにGitに不慣れな人のためのものではありません!
とにかく、2つのリポジトリがあり、1つは最初に作成したもので、もう1つは作成したばかりのものです。
今あなたはあなたの作業リポジトリにいて、 "master"ブランチを使っています。しかし、あなたはオリジナルのリポジトリから同じ「マスター」ブランチに「ログイン」されることもあります。今、あなたはオリジナルで「ログイン」しているので、Gitはあなたがオリジナルで作業していて物事を台無しにしているかもしれないのであなたがめちゃくちゃになるかもしれないのを恐れています。そのため、元のリポジトリに戻って "git checkout someotherbranch"を実行する必要があります。これで、問題なくプッシュできます。
これが役に立つことを願っています。
エラーメッセージは何が起こったのかを説明します。 Gitの最近のバージョンでは、そのブランチがチェックアウトされている場合、プッシュによるブランチの更新を拒否します。
2つのベア以外のリポジトリ間で作業する最も簡単な方法は、次のどちらかです。
リポジトリをプル(またはフェッチしてマージ)するか、必要に応じて更新します。
別のブランチ(インポートブランチ)にプッシュしてから、そのブランチをリモートマシンのマスターブランチにマージします。
この制限の理由は、Push操作はリモートのGitリポジトリでのみ動作し、インデックスと作業ツリーへのアクセスがないことです。 したがって、許可されている場合、チェックアウトされたブランチをプッシュすると、 HEAD
がリモートリポジトリのインデックスと作業ツリーと矛盾するように変更されます。
これにより、プッシュされたすべての変更を元に戻す変更を誤ってコミットすることが非常に簡単になります。 また、コミットされていないローカル変更と新しいHEAD
、インデックス、およびPushがHEAD
を動かすことによって引き起こされたワーキングツリー。
概要
リポジトリのチェックアウトされているブランチにプッシュすることはできません。これは、そのリポジトリのユーザーにデータと履歴の喪失で終わる可能性が最も高いためです。しかし、あなたは同じリポジトリの他のブランチにプッシュすることができます。
ベアリポジトリにはブランチがチェックアウトされていないので、ベアリポジトリの任意のブランチにいつでもプッシュできます。
あなたのニーズに応じて、複数の解決策があります。
解決策1:ベアリポジトリを使用する
お勧めのとおり、1台のマシンで作業ディレクトリが不要な場合は、ベアリポジトリに移動できます。リポジトリをめちゃくちゃにしないようにするには、クローンを作成するだけです。
machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo
今、あなたは以前と同じアドレスにあなたが望むすべてをプッシュすることができます。
解決策2:チェックアウトされていないブランチにプッシュする
しかし、リモートの<remote>
のコードをチェックアウトする必要がある場合は、Pushへの特別なブランチを使うことができます。あなたのローカルリポジトリであなたはあなたのリモートをOrigin
と呼んでいて、あなたはブランチマスターにいます。それなら
machine2$ git Push Origin master:master+machine2
Origin
リモートレポジトリにいるとき、それをマージする必要があります。
machine1$ git merge master+machine2
問題の解剖
ブランチがチェックアウトされると、コミットは現在のブランチのヘッドを親として持つ新しいコミットを追加し、ブランチのヘッドをその新しいコミットに移動します。
そう
A ← B
↑
[HEAD,branch1]
になる
A ← B ← C
↑
[HEAD,branch1]
しかし、誰かがそのブランチにプッシュすることができれば、ユーザーはgitがdetached head modeと呼ぶものになるでしょう。
A ← B ← X
↑ ↑
[HEAD] [branch1]
明示的に別のブランチをチェックアウトすることを要求せずに、ユーザはもはやbranch1にはいません。さらに悪いことに、ユーザーは任意のブランチの外側になり、新しいコミットはダングリングになります。
[HEAD]
↓
C
↙
A ← B ← X
↑
[branch1]
仮に、この時点でユーザーが別のブランチをチェックアウトすれば、この未確定のコミットはGitのガベージコレクタにとって公平なゲームになります。
移行先サーバーで.git/config
を編集することで、この「制限」を回避できます。次の行を追加して、gitリポジトリが "チェックアウト"されていてもプッシュされるようにします。
[receive]
denyCurrentBranch = warn
または
[receive]
denyCurrentBranch = false
1つ目はブランチを混乱させる可能性を警告しながらPushを許可しますが、2つ目は静かにそれを許可します。
これは、編集用ではないサーバーにコードを「デプロイ」するために使用できます。これは最善の方法ではありませんが、コードをデプロイするための簡単な方法です。
私はまだリモートボックスに使えるリポジトリを持っているという考えが好きですが、ダミーブランチの代わりに、私は使うのが好きです:
git checkout --detach
Git - 私はgitバージョン1.7.7.4を使っています。
git config --local receive.denyCurrentBranch updateInstead
https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155
これをサーバーリポジトリで使用すると、追跡されていない上書きが発生しない場合は作業ツリーも更新されます。
コメントの VonCによる として Git 2.3 に追加されました。
Git 2.3をコンパイルして試してみました。使用例
git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead
cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git Push Origin master:master
cd ../server
ls
出力:
a
b
そう、b
がプッシュされました!
私は同じ問題を抱えていました。私にとっては、Git Pushを使用してコードをサーバーに移動します。私はサーバー側のコードを変更しないので、これは安全です。
リポジトリでは、次のように入力します。
git config receive.denyCurrentBranch ignore
これにより、作業コピーである間にリポジトリを変更できます。
Git Pushを実行したら、リモートマシンに移動して次のように入力します。
git checkout -f
これにより、プッシュした変更がリモートマシンの作業コピーに反映されます。
注意して欲しいのですが、あなたがプッシュしている作業コピーに変更を加えたとしてもこれは必ずしも安全ではありません。
サーバーリポジトリを再作成して、ローカルブランチマスターからサーバーマスターにプッシュできます。
リモートサーバー上で
mkdir myrepo.git
cd myrepo.git
git init --bare
そうですね、あなたの地元の支店から:
git Push Origin master:master
これを引き起こすためにおそらくしたこと:
この種のことはあなたが小さなプログラムを打ち出しに行くときに起こります。すでに機能していたものを変更しようとしているので、あなたは永久的なアンドゥアビリティのあなたのレベル3スペルをキャストします:
machine1:~/proj1> git init
そして、あなたは/ commitを追加し始めます。しかし、 then の場合、プロジェクトはより複雑になり始め、あなたは別のコンピュータ(自宅のPCやラップトップのような)から作業したいので、次のようにします。
machine2:~> git clone ssh://machine1/~/proj1
それが複製され、すべてが良さそうに見えるので、あなたはmachine2からあなたのコードに取り組みます。
そして ...あなたはmachine2からコミットをプッシュしようとしますが、タイトルに警告メッセージが表示されます。
このメッセージの理由はあなたが引っ張ったgitリポジトリがちょっとmachine1のそのフォルダのために使われることを意図していたからです。 clone からうまくいくことができますが、プッシュすると問題が発生する可能性があります。 2つの異なる場所でコードを管理するための「適切な」方法は、推奨されているように「ベア」リポジトリを使用することです。裸のリポジトリは作業をするようには設計されていません in それは複数のソースからのコミットを調整するためのものです。 git config --bool core.bare true
の後に.gitフォルダ以外の 削除 すべてのファイル/フォルダを推奨するのはこのためです。
トップクラスの回答を明確にする: その回答に対するコメントの多くは、「machine1から.git以外のファイルを削除していないのに、machine2からコミットすることはできた」などのコメントを含んでいます。そのとおり。しかし、これらの他のファイルは現在gitリポジトリから完全に「分離」されています。そこにgit status
を試してみると、「fatal:この操作は作業ツリーで実行する必要があります」のようなものが表示されるはずです。そのため、ファイルを削除するという提案は、machine2からのコミットが work ;にならないようにするためのものではありません。混乱しないように、gitはまだこれらのファイルを追跡していると考えてください。それでもmachine1上のファイルで作業したい場合は、ファイルを削除するのが問題です。
それで、あなたは本当に何をすべきですか?
Machine1とmachine2でまだ作業する予定の量に応じて異なります...
machine1からの開発が終了し、すべての開発をmachine2に移動した場合... 最も重要な回答が示すとおりに実行します。次に、git config --bool core.bare true
を実行し、必要に応じて.git以外のすべてのファイルを削除します。それらのフォルダは追跡されておらず、混乱を招く可能性があるためです。
machine2での作業が1回限りの作業で、そこで開発を継続する必要がない場合は、 /それで裸のリポジトリを作成する必要はありません。ただftp/rsync/scp/etc。 machine * 1 *のファイルの上にmachine * 2 *のファイルをコピーし、machine * 1 *からコミット/プッシュしてから、machine * 2 *のファイルを削除します。他の人がブランチを作ることを提案していますが、あなたが他のマシンから一度だけ行った開発をマージしたいだけならそれは少し面倒だと思います。
machine1とmachine2の両方で開発を続ける必要がある場合は、 その後、適切に設定する必要があります。レポを裸に変換する必要があります。 次に machine1でその複製を work inにする必要があります。おそらくこれを行う最も簡単な方法は次のとおりです。
machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1
非常に重要: リポジトリの場所をproj1からproj1.gitに移動したため、 machine2の.git/configファイルでこれを更新する必要があります 。その後、machine2から変更内容をコミットできます。最後に、私は自分の裸のリポジトリを私の作業ツリーから離れた中央の場所に保管しようとします(すなわち、 'proj1.git'を 'proj1'と同じ親フォルダーに置かないでください)。私はあなたに同様にすることを勧めますが、私は上記のステップをできるだけ単純にしたかったです。
いくつかの設定手順で、次のようなワンライナーを使用して簡単にWebサイトに変更を適用できます。
git Push production
これは素晴らしく簡単です、そしてあなたはリモートサーバーにログインしてプルまたは何かをする必要はありません。プロダクションチェックアウトを作業ブランチとして使用しない場合、これが最もうまくいくことに注意してください。 (OPはわずかに異なる状況で作業していました、そして@Robert Gouldの解決策がそれにうまく対処したと思います。この解決策は、リモートサーバーへの展開により適しています。)
最初に、あなたのWebルートの外側で、あなたのサーバのどこかに裸のリポジトリをセットアップする必要があります。
mkdir mywebsite.git
cd mywebsite.git
git init --bare
次にファイルhooks/post-receive
を作成します。
#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f
そしてファイルを実行可能にします。
chmod +x hooks/post-receive
あなたのローカルマシンでは、
git remote add production git@myserver.com:mywebsite.git
git Push production +master:refs/heads/master
準備完了!今後はgit Push production
を使って変更をデプロイすることができます。
このソリューションの功績は http://sebduggan.com/blog/deploy-your-website-changes-using-git/ にあります。何が起こっているのかについてのより詳細な説明についてはそこを見てください。
あなたは裸のリポジトリにプッシュするだけであるべきです。ベアリポジトリとは、ブランチをチェックアウトしていないリポジトリです。あなたが裸のリポジトリディレクトリにcdするならば、あなたは.gitディレクトリの内容だけを見るでしょう。
3つの選択肢があります
もう一度引いて押します。
git pull; git Push
別のブランチにプッシュする:
git Push Origin master:foo
そしてそれをリモートでマージします(
git
または pull-request のいずれかによる)。git merge foo
それを強制します(
rebase
を介して意図的にコミットを変更しない限り、お勧めできません)。git Push Origin master -f
それでも拒否される場合は、
denyCurrentBranch
on remote repositoryを無効にします。git config receive.denyCurrentBranch ignore
実際、リモートをチェックアウトされていないブランチに設定すれば十分です。別の支店でリモコンをチェックアウトしたら、プッシュできます。
私は私のAndroid携帯電話とラップトップのリポジトリを同期させるためにGitを使用して同じ問題を抱えていました。私にとっての解決策は、@ CharlesBaileyが示唆しているように、Pushではなくpullを実行することでした。
Androidリポジトリのgit Push Origin master
は、リポジトリの非ベアチェックアウトへのプッシュ+作業コピーのために@ hap497が取得したのと同じエラーメッセージで私には失敗します。
ラップトップリポジトリのgit pull droid master
と作業コピーが私のために働きます。もちろん、git remote add droid /media/Kingston4GB/notes_repo/
のようなものを以前に実行しておく必要があります。
Gitの古いバージョンでは、現在チェックアウトされている非ベアリポジトリのブランチへのプッシュを許可していました。
これは許すのが非常に混乱を招くことでした。それで彼らはあなたが見る警告メッセージを付け加えました、そしてそれはまたひどく混乱します。
最初のリポジトリが単なるサーバーとして機能している場合は、他の回答で推奨されているようにそれをベアリポジトリに変換し、それを実行します。
ただし、両方とも使用中の2つのリポジトリ間で共有ブランチを作成する必要がある場合は、次の設定でそれを実現できます。
Repo1 - サーバーとして機能し、開発にも使用されます
Repo2 - 開発専用になります
Repo1を次のように設定します。
作業を共有するブランチを作成します。
git branch shared_branch
安全のために、shared_branch以外のものへの変更をすべて拒否する$(REPO).git/hooks/updateも作成する必要があります。
repo1/.git/hooks (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"
if [ "${refname}" != "refs/heads/shared_branch" ]
then
echo "You can only Push changes to shared_branch, you cannot Push to ${refname}"
exit 1
fi
それではrepo1にローカルブランチを作成し、そこで実際の作業を行います。
git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'
(git config --global Push.default upstream
が機能するためにはgit Push
が必要な場合があります)
これでrepo2を作成できます
git clone path/to/repo1 repo2
git checkout shared_branch
この時点では、repo1とrepo2の両方が、repo1のshared_branch
からプッシュアンドプルするローカルブランチで動作するように設定されています。そのエラーメッセージについて心配する必要はなく、またrepo1で作業ディレクトリが同期しなくなります。どのような通常のワークフローを使用しても機能します。
目的のプロジェクトの.git/config
を確認してください。
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[receive]
denyCurrentBranch = updateInstead
core. bare
がfalseの場合は、trueに設定できます。
$ git config core.bare true
そしてあなたのローカルでリモートにプッシュ:
git Push remote_repo // suppose the destination repo is remote_repo
それは成功するでしょう、remote_repoであなたはgitのバージョンをチェックすることができます。
$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date: Thu May 17 21:54:37 2018 +0800
そして今、あなたはあなたの "ワークスペース"でgitを使うことができません。
$ git status
fatal: This operation must be run in a work tree
bare.bare
をfalseに戻す必要があります。
$ git config core.bare false
通常のリモートリポジトリが欲しい場合は、追加のブランチを作成してチェックアウトしてください。それを1つのブランチにプッシュし(チェックアウトされていない)、ローカルからプッシュした後に現在アクティブになっているブランチとマージします。
たとえば、リモートサーバーでは、次のようになります。
git branch dev
git checkout dev
ローカルセットアップで:
git Push
リモートサーバー上
git merge dev
これがbare
サーバの仕組みを確認するためにできるテストの1つです。
ライブサイトがホストされているワークステーションとサーバーがあり、このサイトを随時更新したいとします(これは、2人の開発者が素手の仲介人を介して仕事をやり取りする状況にも当てはまります)。 。
初期化
ローカルコンピュータにディレクトリを作成し、そこにcd
を作成してから、次のコマンドを実行します。
# initialization
git init --bare server/.git
git clone server content
git clone server local
- まず裸の
server
ディレクトリを作成します(最後の.gitに注目してください)。このディレクトリはリポジトリファイルのコンテナとしてのみ機能します。 - 次に、サーバーリポジトリを新しく作成した
content
ディレクトリにクローンします。これはあなたのサーバーソフトウェアによって提供されるライブ/プロダクションディレクトリです。 - 最初の2つのディレクトリはサーバー上にあり、3番目のディレクトリはワークステーション上のローカルディレクトリです。
ワークフロー
これが基本的なワークフローです。
local
ディレクトリに入り、ファイルをいくつか作成してコミットします。最後にそれらをサーバーにプッシュします。# create crazy stuff git commit -av git Push Origin master
content
ディレクトリに入り、サーバーの内容を更新します。git pull
1-2を繰り返します。ここで
content
はサーバーにプッシュすることができる別の開発者かもしれません、そしてあなたが彼から引っ張るかもしれないのでlocal
。
私はこの質問を見ているほとんどの人が最初の2つの大きな答えで止まると確信しています、しかし私はまだ私の解決策を提供したいと思います。
説明したエラーが発生したときにEclipse + EGit Webプロジェクトをセットアップしました。 GitHubアプリを使用しただけで問題が解決しました。 EGitはいつもプッシュを拒否しますが、GitHubデスクトップアプリは肩をすくめて私の変更をプッシュします。多分それは複数のログイン状況をもっと優雅に扱うでしょう。
これを行うための最良の方法は次のとおりです。
mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/
これでリポジトリが複製されますが、.../remote
に作業コピーは作成されません。リモコンを見ると、currentrepo.git
という名前のディレクトリが1つ作成されているのがわかります。
それからあなたのローカルGitリポジトリから:
git remote add remoterepo ..../remote/currentrepo.git
変更を加えたら、次のことができます。
git Push remoterepo master
既存のベアリポジトリでgit --init
を再実行しなければなりませんでした、そしてこれはベアリポジトリツリーの中に.git
ディレクトリを作成しました - 私はそこにgit status
をタイプした後にそれを実現しました。私はそれを削除し、すべてが再び大丈夫だった:)
(これらの答えはすべて素晴らしいですが、私の場合は、説明したように(私が見ることができる限り)まったく異なるものでした。)
これを使ってリモートアップストリームブランチにプッシュすると、この問題は解決しました。
git Push <remote> master:Origin/master
リモートはアップストリームレポジトリにアクセスできないので、これはそのリモートへの最新の変更を取得するための良い方法でした。
私が見つけた他の人に役立つ記事は5分でGitです。
Gitバージョン管理下の Xcode プロジェクトで、DCにある Virtual Distributed Ethernet (VDE)にプッシュアップしたいと考えていました。 VDEは Centos 5を実行します。
私がGitについて読んだ記事のどれも、裸のリポジトリについて話していませんでした。私が _ svn _ 背景から来るのが簡単であるべきだと思ったことを試みるまで、それはすべてとても単純に聞こえました。
リモートリポジトリを裸にするためのここでの提案はうまくいきました。私の要件にとってさらに良いのは、Xcodeプロジェクトをprojectname.git
に複製し、それをリモートサーバーにコピーすることでした。それから魔法のように働いたプッシュ。次のステップはコミットについてのエラーなしでXcodeをプッシュすることですが、今のところTerminalからやっても大丈夫です。
そう:
cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>
Xcodeにコミットした後にXcodeプロジェクトから変更をプッシュするには:
cd /xcode-project-directory<br/>
git Push sshusername@remotehost.com:repos/projectname.git<br/>
よりスムーズで洗練された上記の方法があることは間違いありませんが、少なくともこれでうまくいきます。 /xcode-project-directory
はあなたのxcodeプロジェクトが保存されているディレクトリです。おそらく/Users/Your_Name/Documents/Project_Name
です。 projectnameは文字通りプロジェクトの名前です、しかしそれはあなたがそれを呼ぶことを気にするものなら何でもである場合もあります。 Gitは気にしない、あなたはそうだろう。
Scpを使用するには、リモートサーバー上に _ ssh _ アクセスが許可されているユーザーアカウントが必要です。自分のサーバーを実行している人は誰でもこれを持つでしょう。共有ホスティングなどを使用している場合は、運が悪くなる可能性があります。
remotehost.com
はリモートホストの名前です。あなたは簡単にそのIPアドレスを使うことができます。さらに明確にするために、SSHキーを使用してリモートホスト上で Gitosis を使用しているので、プッシュ時にパスワードの入力を求められることはありません。記事ホスティングGitリポジトリ、簡単な(そして安全な)方法は、それらすべてを設定する方法を説明します。
空の(ベア)リポジトリを作成したら、リモートサーバの設定ファイルを変更する必要があります。
root@development:/home/git/repository/my-project# cat config
あなたが見るでしょう
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
あなたはこれを真に真から真にし、そして私はlogallrefupdates = trueを削除します(その使用の確信はありません!)
に
[core]
repositoryformatversion = 0
filemode = true
bare = true
あなたは以下をテストすることがあります
$ git remote show Origin
* remote Origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)
このHEADブランチ:(不明)はプッシュできない場合に表示されます。そのため、HEADブランチが分からない場合は、ベアをtrueに変更し、プッシュが成功したら再利用できます。
git remote show Origin
そしてあなたは見るでしょう
HEAD branch: master
Herok で展開gitリポジトリを使用してこの問題に遭遇しました。
Herokuの側に非ベアリポジトリがある理由はわかりませんが、回避策として、リモートリポジトリをリセットし、再アップロードすることができました。
リポジトリのHerokuのコピーをコラボレーション用の唯一のgitリポジトリとして使用するべきではありませんが、念のため、次のように明確に述べます: Heroku以外の場所に安全に保存されたリポジトリのコピー。リセットすると、リポジトリの内容が削除されます。
リセットするには:
- Heroku toolbelt (コマンドラインクライアントを含む)をまだインストールしていない場合はインストールします。
heroku-repo plugin をまだインストールしていない場合はインストールします。
heroku plugins:install https://github.com/heroku/heroku-repo.git
リポジトリを削除し、新しい空のリポジトリを作成するリセットを実行します
heroku repo:reset
通常どおりHerokuリモートにプッシュします。すべてを再アップロードします。
念のために誰かがそれが役に立つと思います。私にとっては、gitサーバーのパーミッションの問題でした。最初からプロジェクトをチェックアウトして単純なファイルをプッシュしたところ、「プッシュが拒否されました:オリジン/マスターへのプッシュが拒否されました」というメッセージが表示されました。
私には解決策があります:
リモートで:
git checkout -b some_tmp_name
現地で:
git Push
リモートで:
git checkout master
git branch -d some_tmp_name
しかしこれは実際の解決策ではありません。