Git push error '[удаленный отказ] master → master (ветвь в настоящий момент выгружена)'

Ответ 1

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

Выполните следующую команду в папке удаленного репозитория:

git config --bool core.bare true

Затем удалите все файлы, кроме .git в этой папке. И тогда вы сможете выполнить git push в удаленном репозитории без каких-либо ошибок.

Ответ 2

У меня была такая же ошибка, когда я начал изучать Git. Некоторые другие ответы явно не для кого-то нового для Git!

(Я собираюсь использовать нетехнические термины, чтобы передать эту идею.) Во всяком случае, происходит то, что у вас есть два репозитория: один из них - это оригинал, который вы впервые создали, а другой - тот, который вы только что создали.

Сейчас вы находитесь в своем рабочем репозитории и используете ветвь "master". Но вы также оказались "вошедшими в систему" ​​в вашем исходном репозитории в том же "ведущем" филиале. Теперь, когда вы "вошли в систему" ​​в оригинале, Git боятся, что вы можете испортить, потому что вы можете работать над оригиналом и закручивать вещи. Поэтому вам нужно вернуться в исходный репозиторий и выполнить "git checkout someotherbranch", и теперь вы можете без проблем нажимать.

Надеюсь, это поможет.

Ответ 3

Сообщение об ошибке описывает, что произошло. Более современные версии Git отказываются обновлять ветвь с помощью push, если эта ветка проверена.

Самый простой способ работы между двумя не-голыми репозиториями - либо

• всегда обновлять репозитории путем pull (или извлечения и слияния) или, если вам нужно,

• нажав на отдельную ветку (ветвь импорта), а затем слияние этой ветки в главную ветвь на удаленной машине.

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

Это упростит случайное совершение изменения, которое отменяет все нажатые изменения, а также очень сложно отличить любые локальные изменения, которые не были зафиксированы, и различия между новыми HEAD, индекс и рабочее дерево, вызванные push move HEAD.

Ответ 4

Резюме

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

Поскольку в открытых хранилищах ни один филиал не проверен, вы всегда можете нажать на любую ветвь открытого репозитория.

В зависимости от ваших потребностей существует несколько решений.

Решение 1: используйте Bare Repostory

Как и было предложено, если на одной машине вам не нужен рабочий каталог, вы можете перейти в голый репозиторий. Чтобы избежать беспорядка с репозиторием, вы можете просто клонировать его:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

Теперь вы можете нажать все, что хотите, на тот же адрес, что и раньше.

Решение 2: нажмите на неконфигурированную ветвь

Но если вам нужно проверить код на удаленном <remote>, тогда вы можете использовать специальную ветвь для нажатия. Скажем, что в вашем локальном репозитории вы назвали свой удаленный origin, и вы находитесь на главном сервере. Тогда вы могли бы сделать

machine2$ git push origin master:master+machine2

Затем вам нужно объединить его, когда вы находитесь в удаленном репо origin:

machine1$ git merge master+machine2

Вскрытие проблемы

Когда ветвь вычеркнута, фиксация добавит новую фиксацию с текущей ветвью ветки в качестве ее родителя и переместит ветвь ветки в новую фиксацию.

Итак,

A ← B
    ↑
[HEAD,branch1]

становится

A ← B ← C
        ↑
    [HEAD,branch1]

Но если кто-то может нажать на эту ветку между ними, пользователь получит себя в том, что git вызывает отключенный головной режим:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Теперь пользователь больше не находится в ветке1, не запросив явно другую ветку. Хуже того, пользователь теперь вне любой ветки, и любая новая фиксация будет просто болтаться:

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

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

Ответ 5

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

[receive]
denyCurrentBranch = warn

или

[receive]
denyCurrentBranch = false

Первый позволит нажать, предупреждая о возможности испортить ветку, тогда как второй будет просто спокойно разрешать ее.

Это можно использовать для "разворачивания" кода на сервер, который не предназначен для редактирования. Это не лучший подход, но быстрый для развертывания кода.

Ответ 6

Мне нравится идея по-прежнему иметь полезный репозиторий в удаленном поле, но вместо фиктивной ветки мне нравится использовать:

git checkout --detach

Это, кажется, очень новая функция Git - я использую git версию 1.7.7.4.

Ответ 7

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Используйте это в репозитории сервера, а также обновите рабочее дерево, если не произойдет никакой перезаписи.

Он был добавлен в Git 2.3, как упоминается VonC в комментариях.

Я скомпилировал 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

Yay, b толкнул!

Ответ 8

У меня была такая же проблема. Для меня я использую Git push для перемещения кода на мои серверы. Я никогда не изменяю код на стороне сервера, так что это безопасно.

В репозитории вы нажимаете для ввода:

git config receive.denyCurrentBranch ignore

Это позволит вам изменить репозиторий, пока он является рабочей копией.

После запуска нажатия Git перейдите на удаленный компьютер и введите следующее:

git checkout -f

Это приведет к тому, что сделанные вами изменения будут отражены в рабочей копии удаленной машины.

Обратите внимание: это не всегда безопасно, если вы вносите изменения в рабочую копию, на которую вы нажимаете.

Ответ 9

Вы можете воссоздать свой серверный репозиторий и нажать от своего локального мастера ветки до мастера сервера.

На удаленном сервере:

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

ОК, из вашей локальной ветки:

git push origin master:master

Ответ 10

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

git push production

Это хорошо и просто, и вам не нужно заходить на удаленный сервер и делать что-либо или что-то в этом роде. Обратите внимание, что это будет работать лучше всего, если вы не используете свою производственную проверку в качестве рабочей ветки! (ОП работал в немного другом контексте, и я думаю, что решение @Robert Gould адресовало его хорошо. Это решение более подходит для развертывания на удаленном сервере.)

Сначала вам нужно настроить пустой репозиторий где-то на вашем сервере, вне вашего веб-сайта.

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/. Посмотрите там более подробное объяснение того, что происходит.

Ответ 11

Что вы, вероятно, сделали для этого:

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

machine1:~/proj1> git init

и вы начинаете добавлять/фиксировать. Но тогда проект начинает становиться все более активным, и вы хотите работать с ним с другого компьютера (например, вашего домашнего ПК или ноутбука), поэтому вы делаете что-то вроде

machine2:~> git clone ssh://machine1/~/proj1

и он клонирует и все выглядит хорошо, поэтому вы работаете над своим кодом с machine2.

Затем... вы пытаетесь вытолкнуть свои коммиты из machine2, и вы получите предупреждающее сообщение в заголовке.

Причиной этого сообщения является то, что репозиторий git, который вы вытащили, был предназначен для использования только для этой папки на machine1. Вы можете клонировать от него очень хорошо, но нажатие может вызвать проблемы. "Правильный" способ управления кодом в двух разных местах - с "голым" репо, как было предложено. Голый репо не предназначен для выполнения какой-либо работы в нем, он предназначен для координации коммитов из нескольких источников. Вот почему самый высокий ответ предлагает удалить все файлы/папки, отличные от папки .git, после git config --bool core.bare true.

Уточнение ответа с наивысшим рейтингом:. Многие комментарии к этому ответу говорят примерно так: "Я не удалял файлы без .git с машины1, и я все еще мог совершать machine2". Это так. Тем не менее, эти другие файлы полностью "разведены" из репозитория git. Попробуйте попробовать git status, и вы увидите нечто вроде "фатальный: эта операция должна выполняться в дереве работ". Таким образом, предложение об удалении файлов не так, чтобы коммит с machine2 работал; так что вы не смущаетесь и думаете, что git все еще отслеживает эти файлы. Но удаление файлов является проблемой, если вы все еще хотите работать с файлами на machine1, не так ли?

Итак, что вы на самом деле делаете?

В зависимости от того, сколько вы планируете работать на машинах1 и machine2...

Если вы закончили работу с machine1 и переместили всю свою разработку на machine2..., просто сделайте то, что предлагает лучший рейтинг: git config --bool core.bare true, а затем, при желании, удалите все файлы/папки, отличные от .git из этой папки, поскольку они не отслеживаются и могут вызвать путаницу.

Если ваша работа на machine2 была всего лишь разовой, и вам не нужно продолжать разработку там..., то не беспокойтесь о том, чтобы сделать голый репо; просто ftp/rsync/scp/etc. ваши файлы с машины * 2 * поверх файлов на машине * 1 *, зафиксировать/нажать с машины * 1 *, а затем удалить файлы с машины * 2 *. Другие предложили создать ветку, но я думаю, что немного беспорядочно, если вы просто хотите объединить некоторую разработку, которую вы делали на разовой основе с другой машины.

Если вам нужно продолжить разработку на машинах и машинах2..., вам нужно правильно настроить все. Вам нужно преобразовать свое репо на голый, тогда вам нужно сделать клон этого на machine1, чтобы вы могли работать. Вероятно, самый быстрый способ сделать это - сделать

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, вам нужно обновить его в файле .git/config на machine2. После этого вы можете перенести свои изменения с machine2. Наконец, я стараюсь держать мои голые репозитории в центральном месте, вдали от моих рабочих деревьев (т.е. Не ставьте "proj1.git" в ту же родительскую папку, что и "proj1" ). Я советую вам поступать аналогичным образом, но я хотел как можно более просто выполнить вышеуказанные шаги.

Ответ 12

Вы должны только нажимать на голый репозиторий. Голый репозиторий - это хранилище, в котором нет выделенных ветвей. Если вы хотите использовать cd в каталоге с открытым хранилищем, вы увидите только содержимое каталога .git.

Ответ 13

У вас есть 3 варианта

• Потяните и нажмите еще раз:

  git pull; git push
  

• Нажмите в другую ветку:

  git push origin master:foo
  

  и объединить его на удаленном (либо git, либо pull-request)

  git merge foo
  

• Принудительно (не рекомендуется, если вы не намеренно изменили фиксацию через rebase):

  git push origin master -f
  

  Если все еще отказано, отключите удаленный репозиторий denyCurrentBranch on:

  git config receive.denyCurrentBranch ignore
  

Ответ 14

На самом деле достаточно установить удаленный доступ к незанятой ветке. После того, как вы проверили свой пульт в другой ветке, вы можете нажать.

Ответ 15

У меня была такая же проблема, используя Git для синхронизации репозиториев на моем телефоне и ноутбуке Android. Решение для меня состояло в том, чтобы сделать тягу вместо толчка, как предположил @CharlesBailey.

git push origin master в репозитории Android не работает для меня с теми же сообщениями об ошибках, которые @hap497 получил из-за нажатия на несвязанный checkout репозиторий + рабочая копия.

git pull droid master в хранилище для ноутбука и рабочей копии для меня. Конечно, вам нужно было запустить что-то вроде git remote add droid /media/KINGSTON4GB/notes_repo/.

Ответ 16

Предыдущие версии Git, используемые для разрешения нажатия на текущую проверочную ветку не-голого репозитория.

Оказывается, это была ужасно запутанная вещь. Таким образом, они добавили предупреждающее сообщение, которое вы видите, что также ужасно запутывает.

Если первый репозиторий просто действует как сервер, тогда преобразовать его в голый репозиторий, так как другие ответы рекомендуют и делают с ним.

Если вам нужно иметь общую ветвь между двумя репозиториями, которые используются одновременно, вы можете выполнить ее с помощью следующей настройки

Repo1 - будет действовать как сервер, а также будет использоваться для разработки

Repo2 - будет только для разработки

Настройка Repo1 следующим образом

Создайте ветку для совместной работы.

git branch shared_branch

Чтобы быть в безопасности, вы также должны создать файл $(REPO).git/hooks/update, который отклоняет любые изменения ничем, кроме shared_branch, потому что вы не хотите, чтобы люди сбрасывали ваши частные ветки.

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 для работы с локальными ветвями, которые нажимают и тянут с shared_branch в repo1, без необходимости беспокоиться об этом сообщении об ошибке или о том, что рабочий каталог не синхронизируется в repo1. Независимо от того, какой нормальный рабочий процесс вы используете, должен работать.

Ответ 17

Вот один тест, который вы можете сделать, чтобы посмотреть, как работает сервер bare:

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

Инициализация

Создайте в нем каталог на вашем локальном компьютере и cd, затем выполните следующие команды:

# initialization
git init --bare server/.git
git clone server content
git clone server local

• Сначала вы создаете голый каталог server (обратите внимание на .git в конце). Этот каталог будет служить контейнером только для файлов вашего репозитория.
• Затем клонируйте ваш репозиторий сервера в только что созданный каталог content. Это ваш личный/производственный каталог, который будет обслуживаться вашим серверным программным обеспечением.
• Первые два каталога находятся на вашем сервере, третий - локальный каталог на вашей рабочей станции.

Workflow

Теперь вот основной рабочий процесс:

• Войдите в каталог local, создайте несколько файлов и скопируйте их. Наконец, нажмите их на сервер:

  # create crazy stuff
  git commit -av
  git push origin master
  

• Теперь войдите в каталог content и обновите содержимое сервера:

  git pull
  

• Повторите 1-2. Здесь content может быть другим разработчиком, который может нажать на сервер тоже, и local, как вы можете от него отстраниться.

Ответ 18

OK, если вы хотите создать обычный удаленный репозиторий, затем создайте дополнительную ветку и проверьте ее. Вставьте его в одну ветвь (которая не вычеркнута) и объедините ее с той, которая активна в данный момент позже после нажатия на локальном уровне.

Например, на удаленном сервере:

git branch dev
git checkout dev

В локальной настройке:

git push 

На удаленном сервере:

git merge dev

Ответ 19

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

У меня был проект Xcode под управлением Git, который я хотел нажать до Виртуальный распределенный Ethernet (VDE) У меня есть DC. 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-адрес. Для большей ясности я использую Gitosis на удаленном хосте с ключами SSH, поэтому я не запрашиваю пароли, когда я нажимаю. Статья Хостинг Git Репозитории, легкий (и безопасный) способ рассказывает вам, как установить все это.

Ответ 20

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

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

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

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

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

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

git push remoterepo master

Ответ 21

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

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

Ответ 22

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

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

Ответ 23

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

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

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

В reset:

0. Установите инструмент Heroku toolbelt (который содержит клиент командной строки), если вы еще этого не сделали.

1. Установите плагин heroku-repo, если вы еще этого не сделали.

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

2. Сделайте reset, который удаляет репозиторий и создает новый, пустой

   heroku repo:reset
   

3. Нажмите на свой пульт Heroku, как обычно. он будет reupload все.

Ответ 24

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

[email protected]:/home/git/repository/my-project# cat config 

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

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

Вы сделаете это голым для false, чтобы true, и я удалил logallrefupdates = true (не уверен в его использовании!)

to

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

Вы можете протестировать следующие

$ git remote show origin
* remote origin
Fetch URL: [email protected]:/home/XYZ/repository/XYZ
Push  URL: [email protected]:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

Эта ветвь HEAD: (неизвестно) будет отображаться, если вы не можете PUSH. Поэтому, если ветвь HEAD неизвестна, вы должны изменить значение "гореть" на "истина" и после успешного нажатия нажать "

git remote show origin

и вы увидите

 HEAD branch: master

Ответ 25

проверьте свой .git/config в проекте назначения:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

Если core. bare core. bare is 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

Ответ 26

Для меня рабочее решение:

ВКЛ. ДИСТАНЦИОННО:

git checkout -b some_tmp_name

В ЛОКАЛЬНОМ:

git push

ВКЛ. ДИСТАНЦИОННО:

git checkout master
git branch -d some_tmp_name

Но это не реальное решение, которое оно просто обходится.

Ответ 27

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

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

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

На ПК, в ~/workspace

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

На ноутбуке в ~/workspace (не делайте 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    

Затем вернитесь на ПК, в ~/workspace

git pull

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

git push

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

и т.д.

Здесь абсолютный конкретный пример на одной машине, скопированный прямо из окна команды, чтобы мы знали, что никаких шагов не было, что это действительно сработало и т.д.:

[email protected] ~
$ cd gitdir
/home/lylez/gitdir

[email protected] ~/gitdir
$ ls

[email protected] ~/gitdir
$ mkdir repo1

[email protected] ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

[email protected] ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

[email protected] ~/gitdir/repo1
$ echo "line 1" > afile.txt

[email protected] ~/gitdir/repo1
$ git add afile.txt

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

[email protected] ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

[email protected] ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

[email protected] ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

[email protected] ~/gitdir/repo1
$ cd ..

[email protected] ~/gitdir
$ ls
repo1  repo1-bare-clone

[email protected] ~/gitdir
$ mkdir repo1-remote

[email protected] ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

[email protected] ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

[email protected] ~/gitdir/repo1-remote
$ ls
afile.txt

[email protected] ~/gitdir/repo1-remote
$ cat afile.txt
line 1

[email protected] ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

[email protected] ~/gitdir/repo1-remote
$ git add afile.txt

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

[email protected] ~/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

[email protected] ~/gitdir/repo1-remote
$ cd ../repo1

[email protected] ~/gitdir/repo1
$ ls
afile.txt

[email protected] ~/gitdir/repo1
$ cat afile.txt
line 1

[email protected] ~/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(+)

[email protected] ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

[email protected] ~/gitdir/repo1
$ echo "line 3" >> afile.txt

[email protected] ~/gitdir/repo1
$ git add afile.txt

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

[email protected] ~/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

[email protected] ~/gitdir/repo1
$ cd ../repo1-remote/

[email protected] ~/gitdir/repo1-remote
$ ls
afile.txt

[email protected] ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

[email protected] ~/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(+)

[email protected] ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

[email protected] ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

[email protected] ~/gitdir/repo1-remote

Ответ 28

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

Ответ 29

Мое решение (при использовании)

• Оформить заказ "master" на удаленном сервере
• Работайте локально на ветке "dev"
• Нажмите изменения для удаленного dev
• Объединить dev в master на удаленном

лото