Git push error '[удаленный отклонен] master -> master (ветка в настоящее время извлечена)' - PullRequest
926 голосов
/ 12 мая 2010

Вчера я опубликовал вопрос о том, как клонировать репозиторий Git с одной из моих машин на другую, Как я могу 'git clone' с другой машины? .

Теперь я могу успешно клонировать Git-репозиторий из моего источника (192.168.1.2) в пункт назначения (192.168.1.1).

Но когда я произвел редактирование файла, a git commit -a -m "test" и a 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 (1.7 на пульте и 1.5 на локальной машине). Это возможная причина?

Ответы [ 30 ]

1 голос
/ 16 марта 2012

Статья, которую я нашел полезной для других: Git за 5 минут .

У меня был проект Xcode под управлением Git-версией, который я хотел передать до Virtual Distributed Ethernet (VDE), который у меня есть в DC. VDE работает Centos 5.

Ни одна из статей, которые я читал о Git, не говорила о голых репозиториях. Все это звучало так просто, пока я не попробовал то, что, по моему мнению, должно быть легко, исходя из SVN фона.

Предложения здесь, чтобы сделать удаленное хранилище пустым. Еще лучше для моих требований было клонировать проект Xcode в projectname.git, скопировать его на удаленный сервер; затем толчки волшебным образом сработали. Следующим шагом будет получение Xcode для отправки без ошибок о коммитах, но пока я в порядке, делая это из терминала.

Итак:

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. имя проекта - это буквально название проекта, но это может быть любое название. Git не волнует, вы будете.

Чтобы использовать scp, вам нужно иметь учетную запись пользователя на удаленном сервере, которая имеет доступ SSH . Любой, у кого есть собственный сервер, будет иметь это. Если вы пользуетесь виртуальным хостингом и т. П., Вам может не повезти.

remotehost.com - это имя вашего удаленного хоста. Вы можете так же легко использовать его IP-адрес. Просто для большей ясности я использую Gitosis на удаленном хосте с SSH-ключами, поэтому мне не нужно вводить пароли при нажатии. В статье Хостинг Git-репозиториев, простой (и безопасный) способ рассказывается, как все это настроить.

1 голос
/ 11 сентября 2015

Вам нужно будет изменить файл конфигурации на удаленном сервере, как только вы создадите пустой (пустой) репозиторий, скажем,

root@development:/home/git/repository/my-project# cat config 

там вы увидите

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

Вы будетеизмените это значение с false на 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 неизвестна, вы должны изменить голое на истинное, и после успешного нажатия вы можете повторно использовать

git remote show origin

, и вы увидите

 HEAD branch: master
1 голос
/ 03 сентября 2012

Лучший способ сделать это:

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

Это клонирует репозиторий, но не создаст никаких рабочих копий в .../remote. Если вы посмотрите на пульт, вы увидите один созданный каталог, который называется currentrepo.git, что, вероятно, вам и нужно.

Затем из вашего локального репозитория Git:

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

После внесения изменений вы можете:

git push remoterepo master
1 голос
/ 06 сентября 2012

Мне пришлось повторно запустить git --init в существующем пустом хранилище, и это создало каталог .git внутри пустого дерева хранилища - я понял, что после ввода git status там. Я удалил это, и все снова было хорошо:)

(Все эти ответы великолепны, но в моем случае это было что-то совершенно другое (насколько я вижу), как описано.)

1 голос
/ 07 мая 2013

Я уверен, что большинство людей, просматривающих этот вопрос, остановятся на первых двух огромных ответах, но я все же хотел бы предложить свое решение.

У меня была настройка веб-проекта Eclipse + EGit при обнаружении описанной ошибки. Что мне помогло, так это простое использование приложения GitHub, которое, казалось, волшебным образом решило проблему. В то время как EGit всегда отказывался от пуша, настольное приложение GitHub просто пожало плечами и подтолкнуло мои изменения. Может быть, он обрабатывает ситуацию с несколькими входами более изящно.

1 голос
/ 11 сентября 2014

Я только что столкнулся с этой проблемой в репозитории git для развертывания на Heroku .

Я не знаю, почему у Heroku на их стороне находится непокрытое хранилище, но в качестве обходного пути я смог сбросить настройки удаленного хранилища и перезагрузить его.

Вы не должны использовать копию Heroku вашего хранилища в качестве единственного Git-хранилища для совместной работы, но на всякий случай я скажу ясно: Не делайте этого, если вы не уверены, что у вас есть полная копия вашего хранилище надежно хранится где-то, кроме Heroku. Выполнение сброса приведет к удалению содержимого хранилища.

Для сброса:

  1. Установите Heroku toolbelt (который содержит клиент командной строки), если вы этого еще не сделали.
  2. Установите плагин heroku-repo , если вы этого еще не сделали.

    heroku plugins:install https://github.com/heroku/heroku-repo.git
    
  3. Выполните сброс, который удаляет хранилище и создает новый пустой

    heroku repo:reset
    
  4. Нажмите на пульт Heroku, как обычно; все будет перезагружено.

0 голосов
/ 19 июня 2015

На всякий случай, если кто-то найдет это полезным. Для меня это была проблема с разрешениями на git-сервере. Я проверил проект с самого начала и отправил простой файл, а затем получил «Push rejected: Push to origin / master был отклонен»

0 голосов
/ 19 октября 2014

С Git два обычных (не голых) репозитория не могут напрямую перемещать / извлекать файлы назад и вперед. Должен быть промежуточный голый репозиторий. Видимо, это похоже на семейную пару, у которой есть ребенок, и пара разводится. Родители не будут разговаривать друг с другом, но они будут общаться через ребенка.

Итак, у вас есть один репозиторий, вы клонируете этот репозиторий в пустой репозиторий, а затем клонируете его в третий. Первый и третий могут обмениваться информацией через второй репозиторий, пустой. Я думаю, это имеет смысл, так как вы не хотели бы, чтобы кто-то мог проверять содержимое вашего хранилища без вашего согласия, так как это может вызвать конфликты слияния и тому подобное.

Итак, вот пример:

На ПК, в ~ / рабочей области

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

На ноутбуке, в ~ / рабочей области (не выполняйте git init и т. Д.)

git clone //LJZ-DELLPC/remote-repository.git/ .

// Затем выполняем различные коммиты и нажимаем на них:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push    

Затем на ПК, в ~ / рабочей области

git pull

// Затем выполняем различные коммиты и нажимаем на них:

git push

на ноутбуке git pull

и пр.

Вот абсолютно конкретный пример на одном компьютере, скопированный прямо из командного окна, так что мы будем знать, что не было пропущено ни одного шага, что оно действительно работает и т. Д .:

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
0 голосов
/ 28 июня 2014

Для меня рабочий раствор это:

НА УДАЛЕННОМ:

git checkout -b some_tmp_name

НА МЕСТНОМ:

git push

НА УДАЛЕННОМ:

git checkout master
git branch -d some_tmp_name

Но это не настоящее решение, это просто обходной путь.

0 голосов
/ 15 сентября 2013

Мое решение (используется)

  1. Оформить заказ "мастер" на удаленном сервере
  2. Работать локально на ветке "dev"
  3. Нажмите изменения на удаленном устройстве
  4. Объединить разработчика с мастером на пульте

лото

...