Загрузки отключены для загрузки файлов требуется push доступ к этому репозиторию
Обновлено: 05.07.2024
Команда git push при выполнении перемещает изменения, внесенные пользователем на локальном компьютере, в удаленный репозиторий. После того как пользователи клонировали удаленный репозиторий и внесли необходимые изменения в свое локальное устройство, эти изменения должны быть перенесены в удаленный репозиторий. Причина в том, что они являются общими и используются другими пользователями. Команда git push делает это. Эти изменения представляют собой обязательства, выполненные в репозитории, а не незафиксированные изменения (если таковые имеются).
Кроме того, изменения, которые пользователь вносит в локальную систему, не имеют никакой ценности для участников и зрителей, если облако GitHub не отражает их.
Чтобы иметь возможность перейти в удаленный репозиторий, вы должны убедиться, что все ваши изменения в локальном репозитории зафиксированы.
Рассмотрим git push как часть процесса синхронизации в Git. Синхронизация происходит между локальным и удаленным хранилищем, где источник и приемник могут отличаться. Есть много других частей для синхронизации, и git push-это одна из частей, потому что она загружает изменения, сделанные в локальном репозитории, чтобы поддерживать удаленный репозиторий в актуальном состоянии. В этом нет ничего сложного, и концепция проста, как и ее синтаксис.
Приведенного выше изображения достаточно для понимания концепции в двух словах.
Пользователь клонирует репозиторий в качестве первого шага, чтобы внести некоторые изменения в репозиторий.
После этого он приступает к внесению изменений в локальную систему и добавляет эти изменения в промежуточную область.
После завершения всех изменений пользователь затем фиксирует все изменения в локальном репозитории.
А затем передает эти изменения на удаленный сервер. Наконец, он синхронизирует локальный и удаленный репозитории.
Синтаксис команды git Push в Git
Выполнение команды git push происходит путем ввода следующей команды:
git push <remote_repo> <branch_name>
remote_repo: это имя (или псевдоним) удаленного репозитория, в который мы переносим изменения.
branch_name: это ветвь, которую пользователь толкает в удаленный репозиторий.
Представьте себе, что ветвь (branch) в Git подобна ветвям в дереве. Каждая ветвь представляет собой новую функцию или модификацию, находящуюся в стадии разработки. Кроме того, основная ветвь — это стабильный код, подобный стволу дерева, также называемый master branch (главной ветвью). Что, в свою очередь, помогает нестабильному коду ветвей держаться подальше от стабильного основного кода.
Как перенести изменения из локального репозитория в удаленный репозиторий в Git
Чтобы протолкнуть некоторые изменения в удаленный репозиторий, этот репозиторий должен, прежде всего, содержать некоторые коммиты в локальной системе. Поэтому в этом разделе мы сначала создадим некоторые изменения в репозитории. Во-вторых, мы зафиксируем эти изменения и, наконец, отразим их в удаленном репозитории.
Перед созданием изменений в репозитории убедитесь, что вы выполнили следующие операции:
- У вас раздвоенный репозитория на GitHub.
- Вы клонировали один и тот же репозиторий на локальную машину.
Примечание: в этом уроке мы будем использовать репозиторий ToolsQA, который уже был разветвлен и клонирован в предыдущих уроках. Пользователь может свободно использовать любой публичный репозиторий. Однако рекомендуется использовать один и тот же репозиторий для этого урока.
В качестве хорошей практики сначала проверьте, что у вас есть чистый репозиторий с помощью команды git status (никаких ожидающих изменений для фиксации).
После выполнения команды git status появятся следующие строки:
On branch master: означает, что в данный момент мы находимся в главной ветви. Поскольку других ветвей пока нет, мы по умолчанию находимся в главной ветви.
Your branch is up to date with origin/master: Origin — это имя удаленного репозитория, которое мы дали при подключении локального репозитория к удаленному репозиторию.
Последовательность действий
- Перечислите все файлы с командой ls в репозитории.
Так как существует только один файл (README.md это всего лишь инструкция), давайте внесем некоторые изменения в его содержание.
- Откройте файл с помощью вашего любимого редактора и внесите в него любые изменения.
- Мы изменили файл на следующий код.
- Добавьте внесенные изменения в промежуточную область и зафиксируйте их.
- Введите следующую команду, чтобы перенести эти изменения в репозиторий GitHub, и нажмите клавишу enter.
git push origin master
- Пользователь получает приглашение предоставить учетные данные с помощью GitHub в качестве части безопасности. Введите свои учетные данные и нажмите на кнопку входа в систему.
Примечание: последние две строки выглядят следующим образом:
1в4522а..285f559: показывает хэш-значение обеих ветвей. Таким образом, хэш-значение конечного коммита, отраженного на GitHub, равно 285f559.
Строка Writing Objects: 100% имеет важное значение. В Git можно сказать, была ли команда push выполнена успешно или нет, только взглянув на эту строку. Если она показывает 100%, то все изменения успешно перенесены в облако.
Наряду с простой и понятной командой, которую мы обсуждали выше, как и любую другую команду в Git, мы можем использовать параметры при выполнении команды для достижения конкретной задачи. Например, если вы хотите протолкнуть все ветви, вы будете использовать опцию all и так далее. Давайте рассмотрим некоторые из вариантов в Git.
Варианты Git Push
В git push command доступно множество опций, которые помогают нам достичь определенных конкретных задач всего за одно выполнение. В этом разделе мы рассмотрим основные и наиболее часто используемые параметры команды git push.
Prune Option
Использование: git push –prune remote XYZ
Dry Run Option
Эта опция будет выполнять и показывать выполнение команды git push, но не будет отправлять никаких обновлений в удаленный репозиторий.
Использование: git push –dry-run <remote> <local_branch>
Atomic Option
Эта опция в git Push обеспечивает атомарную операцию на удаленном репозитории, т. е. либо каждую ссылку обновляет, либо вообще ничего.
git push –atomic <remote_repo> <working_branch>
All Option
Все опции будут выталкивать все ветви и их зафиксированные изменения в удаленный репозиторий.
Использование: git push-all <remote>
В последнем уроке мы познакомились с командой Git fetch и Read more
В одной из последних статей мы узнали о команде Git Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more
"Клонирование" означает создание идентичных особей естественным или искусственным путем. Клонирование Read more
Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more
Все данные, доступные в локальном репозитории, могут быть загружены в Read more
Недавно меня добавили в качестве участника /участника проекта Github. Я клонировал этот проект на локальной машине.
Мне не хватает разрешения для внесения изменений, чтобы я мог спросить оригинального автора проекта?
- нажмите кнопку форка на исходной странице проекта github
- клонируйте ваш разветвленный репозиторий вместо оригинального
- нажмите на него
- нажмите кнопку "Подтянуть запросы" в своем хранилище
- создайте его
- дождитесь, пока оригинальный автор примет его
Раньше у меня была такая же ошибка, когда я менял адрес электронной почты пользователя git config --global user.email и нашел мое решение здесь: Перейдите: Панель управления -> Аккаунты пользователей -> Управляйте своими учетными данными -> Учетные данные Windows
В разделе Общие учетные данные есть некоторые учетные данные, связанные с Github Нажмите на них и нажмите " Удалить ".
и когда вы пытаетесь что-то нажать, вам нужно снова войти в систему. надеюсь, это будет полезно для вас
In смог решить эту проблему, указав имя пользователя и пароль в URL ниже.
Пожалуйста, замените имя пользователя и пароль на свои учетные данные на github
Редактирование URL-адреса [remote "origin"] в .git/config file для указания URL-адреса SSH, проблем не было:
Надеюсь, это поможет!
На основании информации, предоставленной оригинальным постером, возможно, владельцы проекта EasySoftwareLicensing /software-licensing-php будет принимать запросы на получение только от вилок, поэтому вам может потребоваться форкнуть основное репо и перейти на форк, а затем сделать запросы на извлечение из основного репо. /р>
Другой способ получить эту ошибку, если у вас есть дубликаты или конфликтующие записи
/.ssh/* . Сначала проверьте, что находится в вашей цепочке ключей ssh:
Как видите, есть два одинаковых электронных письма, которые легко запутать. Затем проверьте файл config :
Здесь вы видите, что у вас есть две разные учетные записи электронной почты для github, но одна и та же HostName . Кто-то обязательно запутается, в том числе и ваш мерзавец.
Чтобы устранить проблему, вручную удалите (после копирования) файлы (по умолчанию):
Теперь скопируйте обратно тот, который вы хотите использовать, например, Host github :
Тогда попробуйте еще раз.
По какой-то причине удаление ключей с помощью ssh-add -d id_rsa не сработало должным образом, так как цепочка ключей кэшируется.
Затем я прочитал об исправлении здесь: Fix Это сработало для следующего нажатия, поскольку все файлы были правильной группы, но в следующий раз, когда кто-то подтолкнул изменение, он сделал новый элемент в папке объектов, в которой группа по умолчанию была группой. Единственное, что я могу придумать, это изменить всю группу разработчиков по умолчанию для элементов, которые они проверяют, но это похоже на взлома. Есть идеи? Спасибо.
ОТВЕТЫ
Ответ 1
Разрешения на ремонт
После того, как вы определили и устранили основную причину (см. Ниже), вы захотите восстановить разрешения:
Обратите внимание: если вы хотите, чтобы все могли изменять репозиторий, вам не нужен chgrp и вы захотите изменить chmod на sudo chmod -R a+rwX.
Если вы не исправите основную причину, ошибка продолжит возвращаться, и вам придется снова и снова повторять -R отмену вышеуказанных команд.
Основные причины
Ошибка может быть вызвана одним из следующих:
Репозиторий не настроен для использования в качестве общего репозитория (см. core.sharedRepository в git help config ). Если на выходе:
не является group или true или 1 или какой-то маской, попробуйте выполнить:
а затем повторно -R un рекурсивные chmod и chgrp (см. "Разрешения на восстановление" выше).
Операционная система не интерпретирует бит setgid для каталогов, поскольку "все новые файлы и подкаталоги должны наследовать владельца группы".
Когда core.sharedRepository имеет значение true или group , Git использует функцию операционных систем GNU (например, каждый дистрибутив Linux), чтобы гарантировать, что вновь созданные подкаталоги принадлежат правильной группе (группе, в которой находятся все пользователи репозитория). Эта функция описана в документации GNU coreutils:
. [Если] установлен бит set-group-ID каталога, вновь созданные подфайлы наследуют ту же группу, что и каталог, а вновь созданные подкаталоги наследуют бит set-group-ID родительского каталога. [Этот механизм позволяет] пользователям легче обмениваться файлами, уменьшая необходимость использовать chmod или chown для обмена новыми файлами.
Однако не все операционные системы имеют эту функцию (NetBSD является одним из примеров). Для этих операционных систем вы должны убедиться, что все ваши пользователи Git имеют одинаковую группу по умолчанию. В качестве альтернативы, вы можете сделать хранилище доступным для записи в мире, запустив git config core.sharedRepository world (но будьте осторожны - это менее безопасно).
Ответ 2
Для Ubuntu (или любого Linux)
Из корня проекта
Вы можете указать, что должно быть у вашего имени и вашей группы, посмотрев разрешения на большую часть вывода из этой команды ls -al
Примечание: помните звезду в конце строки sudo
Ответ 3
sudo chmod -R ug+w .;
В принципе, файл .git/objects не имеет разрешений на запись. Вышеупомянутая строка предоставляет разрешение всем файлам и папкам в каталоге.
Ответ 4
используйте следующую команду, работает как magic
введите команду точно так, как она есть (с дополнительными пробелами и одной точкой в конце)
Ответ 5
Я просто хотел добавить свое решение. У меня было репо на OS X, у которого было право на root в некоторых каталогах и Home (это мой каталог пользователей) на других, которые вызвали ту же ошибку, что и выше.
Решение было просто благодарно. От терминала:
Ответ 6
Хороший способ отладки - это в следующий раз, когда это произойдет, SSH в удаленное репо, cd в папку с объектами и выполните ls -al .
Если вы видите 2-3 файла с разными правами пользователя: группа, то это проблема.
В прошлом мне случалось, что некоторые устаревшие скрипты обращались к нашему репозиторию git и обычно означает, что другой (unix) пользователь вставлял/модифицировал файлы последним, и у вашего пользователя нет разрешений на перезапись этих файлов. Вы должны создать общую группу git, в которой находятся все git -enabled пользователи, а затем рекурсивно chgrp папка objects , и это содержимое, так что это групповое владение является общей группой git .
Вы также должны добавить липкий бит в папку, чтобы все файлы, созданные в папке, всегда имели группу git .
Обновление: я не знал о core.sharedRepository. Полезно знать, хотя он, вероятно, просто делает это.
Ответ 7
Решенный для меня. только это:
Ответ 8
Это может произойти, если вы запустили git init с другим пользователем из того, который вы планируете использовать при нажатии изменений.
Если вы слепо следуете инструкциям в [1], это произойдет, поскольку вы, вероятно, создали git -user как root, а затем сразу же перешли к git init без изменения пользователя между ними.
Ответ 9
Чтобы решить эту проблему, вы должны иметь в виду систему разрешений операционной системы, поскольку в этом случае вы ограничены ею. Чтобы лучше понять проблему, проверьте папку с объектами git (.git/objects). Вы, вероятно, увидите что-то подобное:
* Обратите внимание, что эти права доступа к файлам были предоставлены только вашим пользователям, никто никогда не сможет их изменить. *
Если у вас есть разрешение суперпользователя, вы можете перейти вперед и изменить все разрешения самостоятельно, выполнив второй шаг. В любом другом случае вам нужно будет спросить всех пользователей, объекты которых созданы с их пользователями, используйте следующую команду, чтобы узнать, кто они:
Теперь вам и всем пользователям-владельцам файлов придется изменить разрешение на эти файлы, выполнив:
После этого вам нужно будет добавить новое свойство, которое эквивалентно --shared = group, для нового репозитория, в соответствии с документацией, это сделает репозиторий доступным для записи в группу, выполнив его:
Ответ 10
где name - ваше имя пользователя, а group - это группа, к которой принадлежит ваше имя пользователя.
Ответ 11
В моем случае ни один из предложений не работал. Я нахожусь в Windows, и это сработало для меня:
- Копирование удаленного репо в другую папку
- Разделите папку и укажите соответствующие разрешения.
- Убедитесь, что вы можете получить доступ к папке с локальной машины.
- Добавьте это репо в качестве другого удаленного репо в вашем локальном репо. ( git remote add foo //SERVERNAME/path/to/copied/git )
- Нажмите на foo. git push foo master . Это сработало? Большой! Теперь удалите нерабочее репо и переименуйте его во все, что было раньше. Удостоверьтесь, что права и свойство share остаются прежними.
Ответ 12
Он начинал с git -demon как пользователь ' nobody, поэтому не было права на запись.
(Я сомневаюсь, что другие вызовут их inetd conf файл git -gpv. Обычно это было бы непосредственно в/etc/inetd.conf)
Ответ 13
Вам нужны достаточные права на запись в каталоге, на который вы нажимаете.
В моем случае: сервер Windows 2008
щелкните правой кнопкой мыши каталог git repo или родительский каталог.
Свойствa > вкладка "Общий доступ" > "Расширенный доступ" > "Разрешения" > убедитесь, что у пользователя есть соответствующие права доступа.
Ответ 14
Возможно, вы случайно вложили git-репозитории
Ответ 15
выполните следующую команду для .git:
chmod -R 777 .git
Ответ 16
Также возможно, что вы добавили другой локальный репозиторий с тем же псевдонимом. Например, теперь у вас есть 2 локальные папки, называемые origin поэтому при попытке отправки удаленный репозиторий не примет ваши учетные данные.
Возможно, вы можете оставить 1 локальный репозиторий по своему вкусу как origin а другие переименовать их, например, из origin в anotherorigin . Помните, что это просто псевдонимы, и все, что вам нужно сделать, это запомнить новые псевдонимы и их соответствующие удаленные ветки.
Ответ 17
Ответ 18
Работает для меня
Ответ 19
Я получил это при подключении к проекту Rstudio. Я понял, что забыл сделать:
при запуске программы. На самом деле, поскольку у меня есть еще одна ошибка, мне нужно сделать:
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Удаленный репозиторий может находиться на вашем локальном компьютере.Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:
Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url> :
Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :
Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config --global pull.rebase "false"
Если хотите использовать перебазирование при получении изменений: git config --global pull.rebase "true"
Отправка изменений в удаленный репозиторий (Push)
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.
Просмотр удаленного репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote> . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .
Удаление и переименование удалённых репозиториев
Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :
Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Я создал новый репозиторий и столкнулся с странной ошибкой. Раньше я использовал Git на Bitbucket, но я только что переформатировал и теперь не могу заставить Git работать. После фиксации мне пришлось добавить свой адрес электронной почты и имя в глобальные переменные, но потом все было нормально.
Когда я пытаюсь использовать команду
Я здесь в растерянности. Мой друг, с которым я делюсь этим репозиторием, получил к нему доступ и просто нажал на него, но я не могу заставить его работать.
Для тех, кто хочет решить настоящую проблему, следуйте приведенным ниже инструкциям:
Как можно быстрее устранить проблему с SSH
Это набор инструкций, полученных из URL-адреса, на который ссылается VonC. Он был изменен, чтобы сделать его максимально гибким и лаконичным.
Не вводите $ строки или строки, которые не начинаются с $ (это $ означает, что вы вводите это в GitBash).
Установите глобальную информацию, если вы еще этого не сделали:
Видите что-то подобное?
- Да: продолжить.
- Нет: перейдите в раздел ДЛЯ ЛЕНИВШИХ или следуйте связанной статье от VonC.
Посмотрите, сгенерировали ли вы уже ключи:
Если файлов два, следующий шаг можно пропустить.
Оставьте все по умолчанию, введите кодовую фразу. Теперь вы должны увидеть результаты с помощью этой команды:
Проверьте существующий файл конфигурации:
Если вы получили результат, проверьте этот файл на наличие ошибочной информации. Если файла нет, сделайте следующее:
Убедитесь, что вы запускаете агент SSH каждый раз при запуске GitBash:
- Если вы видите вызываемую функцию start_agent , этот шаг уже выполнен.
- Если файла нет, продолжайте.
- Если есть файл, который не содержит этой функции, у вас неприятная ситуация. Возможно, добавить к нему безопасно (используя приведенные ниже инструкции), но может и не быть! Если вы не уверены, сделайте резервную копию вашего .bashrc перед тем, как следовать приведенным ниже инструкциям, или перейдите к разделу ДЛЯ ЛЕНИВШИХ .
Введите в GitBash следующее, чтобы создать файл .bashrc:
Убедитесь, что файл был успешно создан (ваш файл должен отличаться только там, где появляется «yourusername»):
Если бы вы не ввели кодовую фразу, вы бы увидели что-то подобное при запуске GitBash:
И следующее должно вернуть результаты:
Однако, если вы получите следующее из ssh-add -l :
Это не породило агент SSH, и, вероятно, причиной является ваш .bashrc.
Если при запуске GitBash вы увидите следующее:
Это означает, что вы забыли экранировать $ с помощью \ при выводе на файл (т.е. переменные были расширены). Чтобы решить эту проблему, заново создайте свой .bashrc.
Убедитесь, что агент запущен и ваши ключи добавлены:
Должен вернуть что-то подобное:
Выполните следующую команду, чтобы получить свой открытый ключ:
(он должен вернуть что-то, начинающееся с "ssh-rsa . "
Настройте свой закрытый ключ с помощью BitBucket, выполнив следующие действия:
Global Public Key Теперь вход должен быть виден в списке ключей.
- Вернуться в GitBash
- cd в каталог, содержащий ваш проект
- Измените источник на вариант SSH (этого не будет, если вы выполнили шаги FOR THE LAZY )
Проверьте свои пульты:
Переключитесь на URL-адрес SSH:
Проверить, что все в рабочем состоянии:
Вы должны увидеть что-то вроде этого:
СДЕЛАННЫЙ!
ДЛЯ ЛЕНИННЫХ
Использование инструмента с графическим интерфейсом, такого как TortoiseGit или инструментов командной строки .
Командная строка для добавления источника, если он не существует:
Командная строка для изменения существующего источника:
ПРИМЕЧАНИЕ: имя вашей учетной записи не является вашим адресом электронной почты.
Вы также можете указать свою глобальную информацию:
Затем повторите попытку (повторная фиксация не требуется)
Иногда бывает, что вы добавили все, что упомянуто выше,/.bashrc но все же при запуске команды ssh-all -l Она все еще отображается. No agent В этом случае попробуйте эту команду, ssh-agent /bin/bash и она будет Initializing new SSH agent.
Просто любопытно, и это новый вопрос. Предполагается, что SSH_ENV и SSH_AGENT_PID должны быть заменены нашей собственной информацией? где мы можем это найти? Я думаю, что у меня пробел в информации, чем у вас. @JGallardo - Хороший вопрос! Хорошая новость - нет. Это переменные в сценариях оболочки bash - они похожи на переменные среды в пакетных файлах.Эта ошибка также возникает, если вы забыли добавить закрытый ключ в ssh-agent . Сделайте это с помощью:
Это был ответ в моем случае, о чем я всегда забываю, когда создаю новый ключ.Переформатирование означает, что вы, вероятно, удалили свой открытый и закрытый ключи ssh (в
Вам необходимо регенерировать их и опубликовать свой открытый ключ ssh в своем профиле BitBucket, как описано в разделе « Использование протокола SSH с Bitbucket » после « Настройка SSH для Git с помощью GitBash ».
Учетные записи-> Управление учетными записями-> Ключи SSH:
Я решил это, удалив пульт с помощью команды:
Он запрашивает учетные данные github. Введите учетные данные, а затем попробуйте нажать на git, используя:
это помогло мне. это правильный ответ в моем случае. спасибо Спасибо за прямой ответ. Работает как шарм - это именно то, что я искал.Просто нужен файл конфигурации в каталоге
У меня такая же проблема. Мои ключи SSH были установлены правильно. Я исправил эту проблему вот так.
После создания нового проекта в Bitbucket используйте clone. Введите команду клонирования в терминале, и он должен клонировать пустой проект на ваш компьютер. После этого вы можете скопировать свои файлы в этот каталог и начать фиксацию и отправку в битбакет.
Как странно. Сегодня у меня та же проблема, что и с OP, но без переустановки или каких-либо системных изменений мои ключи были в порядке. Этот git remote add процесс просто не работал сегодня - я получил ошибку аутентификации при попытке нажать - но удаление .git, а затем использование git clone и повторное копирование моего источника (просто README.md) вместо этого работает нормально. Спасибо, Рафаэль - я бы точно не подумал попробовать это, если бы не твой ответ.Два небольших уточнения, которые могут спасти кого-то от путаницы, через которую я прошел:
однако при подключении через SSH имя учетной записи всегда "git"
Попытка подключиться к SSH с именем вашей учетной записи впереди приведет к ошибке, полученной исходным плакатом. Вот как вы можете выполнить тест, подключившись к git @, а затем по ошибке попробовать ввести свое имя пользователя и увидеть ошибку.
Если вы настраиваете ключи SSH для групповых учетных записей, они рекомендуют переключить их на личные учетные записи. Полезный совет, чтобы избежать е
Если вы используете SourceTree (я использую 2.4.1), я нашел более простой способ сгенерировать ключ SSH и добавить его в свои настройки Bitbucket. Это решило проблему для меня.
- В SourceTree перейдите в Настройки.
- Перейдите на вкладку Учетные записи и выберите свою учетную запись.
- Должна быть возможность сгенерировать и скопировать SSH-ключ в буфер обмена.
- После того, как вы скопируете это, перейдите в Bitbucket в своем браузере. Перейдите в [аватар] -> Настройки Bitbucket.
- Перейдите к SSH-ключам.
- Нажмите Добавить ключ
- Вставьте ключ, который вы скопировали.
Я получил электронное письмо от Bitbucket с подтверждением того, что в мою учетную запись был добавлен SSH-ключ.
Для справки: в macOS с помощью терминала вы можете использовать следующую команду, чтобы просмотреть ключи, созданные для вашего устройства. Здесь хранится сгенерированный вами ключ.
Как заявляли другие, эта документация мне помогла: используйте протокол SSH с Bitbucket Cloud
Выполните ssh, как в руководстве по Atlassian, и убедитесь, что закрытый ключ вставлен в профиль, а не в репозиторий :)
Не могли бы вы дать ссылку на изложенное Atlassian tutorial ? Какие шаги нужно выполнить, чтобы вставить ключ в профиль и как узнать, вставлен ли он в репозиторий?Я получил ту же ошибку для одного репозитория - внезапно все остальные были и продолжают работать нормально, когда я пытаюсь нажать коммиты. Проблема оказалась с ключом SSH (как вы уже знаете из предыдущих комментариев) - на битбакете перейдите к, View Profile затем нажмите Manage Account .
Слева нажмите на, SSH Keys затем добавьте тот, который у вас есть в вашей системе, в каталог
После того, как вы добавили свой локальный ключ в свою учетную запись на bitbucket, вы сможете начать взаимодействие с вашим репозиторием.
Я нашел решение, которое лучше всего сработало для меня, - разбить толчок на более мелкие части.
и удаление больших файлов изображений скриншотов (10 МБ +) из коммитов
Безопасность не была проблемой в конце концов, больше об ограничениях файлов bin
Вы получили указанную выше ошибку, отмеченную OP, и это не было проблемой аутентификации / безопасности? Это был размер вашего коммита?Эта ошибка также появляется, когда репозиторий не существует. Я пробовал все ответы, пока не увидел, что в названии репо отсутствует тире
[ошибка] доступ к репозиторию запрещен. доступ через ключ развертывания доступен только для чтения. фатальный: не удалось прочитать из удаленного репозитория. Убедитесь, что у вас есть правильные права доступа и репозиторий существует.
[ошибка] фатальный: не удалось прочитать из удаленного репозитория.
Я решил выполнить следующие шаги:
Сначала установите эти зависимости:
Затем удалите git:
Теперь соберите и установите Git в последней версии, в этом случае:
Затем для настройки:
И, наконец, установите так:
если вы настроили ключ ssh на удаленном сервере, вам необходимо его удалить.
Я получил эту ошибку
Тогда я попробовал
git config --global user.email "you@example.com"
работал без кавычек.
Я обнаружил, что командной строке git не нравятся ключи, сгенерированные моим конкурсом (Windows 10).
Я использую macOS, и хотя я установил свой открытый ключ в битбакете, в следующий раз, когда я попытался нажать, я получил
доступ к репозиторию запрещен.
фатальный: не удалось прочитать из удаленного репозитория.
Убедитесь, что у вас есть правильные права доступа и репозиторий существует.
Что мне нужно было сделать, так это шаг 2. Добавьте ключ к ssh-agent, как описано в руководстве по настройке SSH-ключей Bitbucket и особенно на третьем шаге:
(только для macOS) Чтобы ваш компьютер запомнил ваш пароль при каждом перезапуске, откройте (или создайте) файл
/ .ssh / config и добавьте в него следующие строки:
Хост *
UseKeychain да
Надеюсь, это поможет пользователю Mac с той же проблемой.
Вероятно, это вызвано наличием нескольких ключей SSH в агенте SSH (и / или BitBucket). Обратитесь к документации Atlassian для решения этой проблемы.
У меня была эта проблема, и я думал, что сошел с ума. Пользуюсь SSH 20 лет. и git через SSH с 2012 года . но почему я не могу получить свой репозиторий bitbucket на своем домашнем компьютере?
ну, у меня есть две учетные записи Bitbucket и 4 ключа SSH, загруженных в мой агент. даже если мой .ssh / config был настроен на использование правильного ключа. когда ssh инициализировал соединение, он использовал их в порядке загрузки в агент. поэтому я входил в свою личную учетную запись Bitbucket.
затем появляется Запрещенная ошибка при попытке получить репо. имеет смысл.
Я выгрузил ключ у агента
тогда я мог бы получить репозиторий.
. Позже я узнал, что могу заставить его использовать только указанную личность
Я не знал об этом последнем варианте IdentitiesOnly
из самой документации bitbucket
Git изменил некоторые из своих инструкций репо - убедитесь, что вы подключили локальное репо к облаку Git - проверьте каждый из этих шагов, чтобы увидеть, не пропустили ли вы какой-либо.
Мой контрольный список Git: -
- Основная ветка изменилась на главную
- Если вы инициализировали свое репо и хотите начать с нуля, отключите git, с помощью $rm -rf .git которого рекурсивно удаляет git
- Убедитесь, что вы не используете «Apple Git». Типа which git должно быть сказано /usr/local/bin/git - если вы устанавливаете git с Homebrew $brew install git
- Настройте свое имя и адрес электронной почты для коммитов (обязательно используйте адрес электронной почты, который вы зарегистрировали в Github):
- Настройте git для отслеживания изменений регистра в именах файлов:
Если вы допустили ошибку, вы можете обновить файл, $ls -a чтобы найти файл, а затем $open .gitignore отредактировать его, сохранить и закрыть.
- Свяжите свой локальный компьютер с репо с помощью ключа SSH. Ключи SSH - это способ идентификации доверенных компьютеров без использования паролей.
Шаги по созданию нового ключа
Вы также можете найти его, щелкнув изображение своего профиля и клавишу редактирования под ним в левой навигационной панели.
Скопируйте свой ключ в буфер обмена с помощью команды терминала: pbcopy <
В поле Название укажите что-нибудь, что идентифицирует ваш компьютер, например MacBook Air YOUR_NAME.
В поле Ключ просто нажмите cmd +, V чтобы вставить ключ, который вы создали ранее - не добавляйте и не удаляйте символы и или пробелы к ключу.
Следуйте инструкциям, которые вы теперь получаете в своем репо - GitHub добавил дополнительный шаг для создания ветки (время написания октябрь 2020 г.).
Если вы ошиблись, вы всегда можете начать все сначала, удалив инициализацию из папки git на вашем локальном компьютере $rm -rf .git и начав заново, но полезно сначала проверить, что ни один из вышеперечисленных шагов не пропущен, и всегда лучший источник истины документацию - даже если ее читать и понимать дольше!
Читайте также: