web-dev-qa-db-ja.com

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                                                
[email protected]'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://[email protected]/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to Push some refs to 'git+ssh://[email protected]/media/LINUXDATA/working'

私はGitの2つの異なるバージョンを使用しています（リモートでは1.7、ローカルマシンでは1.5）。それが考えられる理由ですか。

gitgit-push
922
hap497

あなたは単にあなたのリモートリポジトリをベアリポジトリに変換することができます（ベアリポジトリに作業コピーはありません - フォルダは実際のリポジトリデータのみを含みます）。

リモートリポジトリフォルダで次のコマンドを実行します。

git config --bool core.bare true

そのフォルダ内の.git以外のすべてのファイルを削除します。そして、エラーなしでリモートリポジトリに対してgit Pushを実行することができます。

1106
John

Git を学び始めたときに同じエラーが発生しました。他の答えのいくつかは明らかにGitに不慣れな人のためのものではありません！

とにかく、2つのリポジトリがあり、1つは最初に作成したもので、もう1つは作成したばかりのものです。

今あなたはあなたの作業リポジトリにいて、 "master"ブランチを使っています。しかし、あなたはオリジナルのリポジトリから同じ「マスター」ブランチに「ログイン」されることもあります。今、あなたはオリジナルで「ログイン」しているので、Gitはあなたがオリジナルで作業していて物事を台無しにしているかもしれないのであなたがめちゃくちゃになるかもしれないのを恐れています。そのため、元のリポジトリに戻って "git checkout someotherbranch"を実行する必要があります。これで、問題なくプッシュできます。

これが役に立つことを願っています。

677
Robert Gould

エラーメッセージは何が起こったのかを説明します。 Gitの最近のバージョンでは、そのブランチがチェックアウトされている場合、プッシュによるブランチの更新を拒否します。

2つのベア以外のリポジトリ間で作業する最も簡単な方法は、次のどちらかです。

  1. リポジトリをプル（またはフェッチしてマージ）するか、必要に応じて更新します。

  2. 別のブランチ（インポートブランチ）にプッシュしてから、そのブランチをリモートマシンのマスターブランチにマージします。

この制限の理由は、Push操作はリモートのGitリポジトリでのみ動作し、インデックスと作業ツリーへのアクセスがないことです。 したがって、許可されている場合、チェックアウトされたブランチをプッシュすると、 HEAD がリモートリポジトリのインデックスと作業ツリーと矛盾するように変更されます。

これにより、プッシュされたすべての変更を元に戻す変更を誤ってコミットすることが非常に簡単になります。 また、コミットされていないローカル変更と新しいHEAD、インデックス、およびPushがHEADを動かすことによって引き起こされたワーキングツリー。

123
CB Bailey

概要

リポジトリのチェックアウトされているブランチにプッシュすることはできません。これは、そのリポジトリのユーザーにデータと履歴の喪失で終わる可能性が最も高いためです。しかし、あなたは同じリポジトリの他のブランチにプッシュすることができます。

ベアリポジトリにはブランチがチェックアウトされていないので、ベアリポジトリの任意のブランチにいつでもプッシュできます。

あなたのニーズに応じて、複数の解決策があります。

解決策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のガベージコレクタにとって公平なゲームになります。

110
Nowhere man

移行先サーバーで.git/configを編集することで、この「制限」を回避できます。次の行を追加して、gitリポジトリが "チェックアウト"されていてもプッシュされるようにします。

[receive]
denyCurrentBranch = warn

または

[receive]
denyCurrentBranch = false

1つ目はブランチを混乱させる可能性を警告しながらPushを許可しますが、2つ目は静かにそれを許可します。

これは、編集用ではないサーバーにコードを「デプロイ」するために使用できます。これは最善の方法ではありませんが、コードをデプロイするための簡単な方法です。

60
Kris

私はまだリモートボックスに使えるリポジトリを持っているという考えが好きですが、ダミーブランチの代わりに、私は使うのが好きです：

git checkout --detach

Git - 私はgitバージョン1.7.7.4を使っています。

40
stackdump

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がプッシュされました！

38
Ciro Santilli 新疆改造中心996ICU六四事件

私は同じ問題を抱えていました。私にとっては、Git Pushを使用してコードをサーバーに移動します。私はサーバー側のコードを変更しないので、これは安全です。

リポジトリでは、次のように入力します。

git config receive.denyCurrentBranch ignore

これにより、作業コピーである間にリポジトリを変更できます。

Git Pushを実行したら、リモートマシンに移動して次のように入力します。

git checkout -f

これにより、プッシュした変更がリモートマシンの作業コピーに反映されます。

注意して欲しいのですが、あなたがプッシュしている作業コピーに変更を加えたとしてもこれは必ずしも安全ではありません。

28
Orbital_sFear

サーバーリポジトリを再作成して、ローカルブランチマスターからサーバーマスターにプッシュできます。

リモートサーバー上で

mkdir myrepo.git
cd myrepo.git
git init --bare

そうですね、あなたの地元の支店から：

git Push Origin master:master
24
nau

これを引き起こすためにおそらくしたこと：

この種のことはあなたが小さなプログラムを打ち出しに行くときに起こります。すでに機能していたものを変更しようとしているので、あなたは永久的なアンドゥアビリティのあなたのレベル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'と同じ親フォルダーに置かないでください）。私はあなたに同様にすることを勧めますが、私は上記のステップをできるだけ単純にしたかったです。

20
Jemenake

いくつかの設定手順で、次のようなワンライナーを使用して簡単に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 [email protected]:mywebsite.git
git Push production +master:refs/heads/master

準備完了！今後はgit Push productionを使って変更をデプロイすることができます。

このソリューションの功績は http://sebduggan.com/blog/deploy-your-website-changes-using-git/ にあります。何が起こっているのかについてのより詳細な説明についてはそこを見てください。

18
Jack Senechal

あなたは裸のリポジトリにプッシュするだけであるべきです。ベアリポジトリとは、ブランチをチェックアウトしていないリポジトリです。あなたが裸のリポジトリディレクトリにcdするならば、あなたは.gitディレクトリの内容だけを見るでしょう。

10
RibaldEddie

3つの選択肢があります

  1. もう一度引いて押します。

    git pull; git Push

  2. 別のブランチにプッシュする：

    git Push Origin master:foo

    そしてそれをリモートでマージします（gitまたは pull-request のいずれかによる）。

    git merge foo

  3. それを強制します（rebaseを介して意図的にコミットを変更しない限り、お勧めできません）。

    git Push Origin master -f

    それでも拒否される場合は、denyCurrentBranch on remote repositoryを無効にします。

    git config receive.denyCurrentBranch ignore
9
kenorb

実際、リモートをチェックアウトされていないブランチに設定すれば十分です。別の支店でリモコンをチェックアウトしたら、プッシュできます。

7
sebthemonster

私は私のAndroid携帯電話とラップトップのリポジトリを同期させるためにGitを使用して同じ問題を抱えていました。私にとっての解決策は、@ CharlesBaileyが示唆しているように、Pushではなくpullを実行することでした。

Androidリポジトリのgit Push Origin masterは、リポジトリの非ベアチェックアウトへのプッシュ+作業コピーのために@ hap497が取得したのと同じエラーメッセージで私には失敗します。

ラップトップリポジトリのgit pull droid masterと作業コピーが私のために働きます。もちろん、git remote add droid /media/Kingston4GB/notes_repo/のようなものを以前に実行しておく必要があります。

5
hobs

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で作業ディレクトリが同期しなくなります。どのような通常のワークフローを使用しても機能します。

4
Andrew C

目的のプロジェクトの.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 < [email protected]>
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
2
aircraft

通常のリモートリポジトリが欲しい場合は、追加のブランチを作成してチェックアウトしてください。それを1つのブランチにプッシュし（チェックアウトされていない）、ローカルからプッシュした後に現在アクティブになっているブランチとマージします。

たとえば、リモートサーバーでは、次のようになります。

git branch dev
git checkout dev

ローカルセットアップで：

git Push

リモートサーバー上

git merge dev
2
Mr Coder

これがbareサーバの仕組みを確認するためにできるテストの1つです。

ライブサイトがホストされているワークステーションとサーバーがあり、このサイトを随時更新したいとします（これは、2人の開発者が素手の仲介人を介して仕事をやり取りする状況にも当てはまります）。 。

初期化

ローカルコンピュータにディレクトリを作成し、そこにcdを作成してから、次のコマンドを実行します。

# initialization
git init --bare server/.git
git clone server content
git clone server local
  1. まず裸のserverディレクトリを作成します（最後の.gitに注目してください）。このディレクトリはリポジトリファイルのコンテナとしてのみ機能します。
  2. 次に、サーバーリポジトリを新しく作成したcontentディレクトリにクローンします。これはあなたのサーバーソフトウェアによって提供されるライブ/プロダクションディレクトリです。
  3. 最初の2つのディレクトリはサーバー上にあり、3番目のディレクトリはワークステーション上のローカルディレクトリです。

ワークフロー

これが基本的なワークフローです。

  1. localディレクトリに入り、ファイルをいくつか作成してコミットします。最後にそれらをサーバーにプッシュします。

    # create crazy stuff
git commit -av
git Push Origin master

  2. contentディレクトリに入り、サーバーの内容を更新します。

    git pull

  3. 1-2を繰り返します。ここでcontentはサーバーにプッシュすることができる別の開発者かもしれません、そしてあなたが彼から引っ張るかもしれないのでlocal。

2
simo

私はこの質問を見ているほとんどの人が最初の2つの大きな答えで止まると確信しています、しかし私はまだ私の解決策を提供したいと思います。

説明したエラーが発生したときにEclipse + EGit Webプロジェクトをセットアップしました。 GitHubアプリを使用しただけで問題が解決しました。 EGitはいつもプッシュを拒否しますが、GitHubデスクトップアプリは肩をすくめて私の変更をプッシュします。多分それは複数のログイン状況をもっと優雅に扱うでしょう。

1
pille

これを行うための最良の方法は次のとおりです。

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

これでリポジトリが複製されますが、.../remoteに作業コピーは作成されません。リモコンを見ると、currentrepo.gitという名前のディレクトリが1つ作成されているのがわかります。

それからあなたのローカルGitリポジトリから：

git remote add remoterepo ..../remote/currentrepo.git

変更を加えたら、次のことができます。

git Push remoterepo master
1
Bill Donahue

既存のベアリポジトリでgit --initを再実行しなければなりませんでした、そしてこれはベアリポジトリツリーの中に.gitディレクトリを作成しました - 私はそこにgit statusをタイプした後にそれを実現しました。私はそれを削除し、すべてが再び大丈夫だった:)

（これらの答えはすべて素晴らしいですが、私の場合は、説明したように（私が見ることができる限り）まったく異なるものでした。）

1
Jan

これを使ってリモートアップストリームブランチにプッシュすると、この問題は解決しました。

git Push <remote> master:Origin/master

リモートはアップストリームレポジトリにアクセスできないので、これはそのリモートへの最新の変更を取得するための良い方法でした。

1
jontro

私が見つけた他の人に役立つ記事は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 [email protected]:repos/<br/>

Xcodeにコミットした後にXcodeプロジェクトから変更をプッシュするには：

cd /xcode-project-directory<br/>
git Push [email protected]:repos/projectname.git<br/>

よりスムーズで洗練された上記の方法があることは間違いありませんが、少なくともこれでうまくいきます。 /xcode-project-directoryはあなたのxcodeプロジェクトが保存されているディレクトリです。おそらく/Users/Your_Name/Documents/Project_Nameです。 projectnameは文字通りプロジェクトの名前です、しかしそれはあなたがそれを呼ぶことを気にするものなら何でもである場合もあります。 Gitは気にしない、あなたはそうだろう。

Scpを使用するには、リモートサーバー上に _ ssh _ アクセスが許可されているユーザーアカウントが必要です。自分のサーバーを実行している人は誰でもこれを持つでしょう。共有ホスティングなどを使用している場合は、運が悪くなる可能性があります。

remotehost.comはリモートホストの名前です。あなたは簡単にそのIPアドレスを使うことができます。さらに明確にするために、SSHキーを使用してリモートホスト上で Gitosis を使用しているので、プッシュ時にパスワードの入力を求められることはありません。記事ホスティングGitリポジトリ、簡単な（そして安全な）方法は、それらすべてを設定する方法を説明します。

1
Korutech App Solutions

空の（ベア）リポジトリを作成したら、リモートサーバの設定ファイルを変更する必要があります。

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
1
vimal krishna

Herok で展開gitリポジトリを使用してこの問題に遭遇しました。

Herokuの側に非ベアリポジトリがある理由はわかりませんが、回避策として、リモートリポジトリをリセットし、再アップロードすることができました。

リポジトリのHerokuのコピーをコラボレーション用の唯一のgitリポジトリとして使用するべきではありませんが、念のため、次のように明確に述べます： Heroku以外の場所に安全に保存されたリポジトリのコピー。リセットすると、リポジトリの内容が削除されます。

リセットするには：

  1. Heroku toolbelt （コマンドラインクライアントを含む）をまだインストールしていない場合はインストールします。

  2. heroku-repo plugin をまだインストールしていない場合はインストールします。

    heroku plugins:install https://github.com/heroku/heroku-repo.git

  3. リポジトリを削除し、新しい空のリポジトリを作成するリセットを実行します

    heroku repo:reset

  4. 通常どおりHerokuリモートにプッシュします。すべてを再アップロードします。

1
rakslice

念のために誰かがそれが役に立つと思います。私にとっては、gitサーバーのパーミッションの問題でした。最初からプロジェクトをチェックアウトして単純なファイルをプッシュしたところ、「プッシュが拒否されました：オリジン/マスターへのプッシュが拒否されました」というメッセージが表示されました。

0
PbxMan

私には解決策があります：

リモートで：

git checkout -b some_tmp_name

現地で：

git Push

リモートで：

git checkout master
git branch -d some_tmp_name

しかしこれは実際の解決策ではありません。

0
jmarceli