Обычно на маке держу винду в виртуалке, на всякий случай. А там руфус создаёт идеальные загрузчики.
Но возможно и стандартная маковская дисковая утилита умеет образы закатывать на флешку. Надо проверить ))
Vlad1m1r95, remote origin это не больше чем некая переменная, в которой хранится URL репозитория. Git remote не находит репозиторий, эта команда показывает содержимое переменных раздела конфига remote.
Наличие URL в переменной origin не гарантирует наличие самого репозитория по этому адресу, и тем более не гарантирует наличия прав на запись.
Подозреваю что Git пытается выполнить Push, получает ошибку и не разбираясь пишет «not found».
Открытые репозиториии можно скачать по любому протоколу, авторизации и ключей не требуется чтобы стянуть проект. Ключи, либо другие способы авторизации, требуются только чтобы отправить изменения обратно в репозиторий.
Прописывать ключи считаю бесполезной тратой времени. Какие-то сложные телодвижения. Сам GitHub продвигает работу через токены и по https-протоколу. Никаких паролей не требуется и заморачиваться с созданием и сохранением ключей не нужно. Причём токену можно присвоить ограниченные права, ровно столько, сколько нужно для работы.
Судя по ошибке — нет прав на запись, либо ключи не установил. Зачем вообще ssh? Через https надёжнее и проще.
И просто push без параметров резонно сказал тебе что не знает куда отправлять. Каждой ветке персонально привязывается вышестоящая. Только после этого можно не указывать куда отправлять, Git вытащит эту инфу из настроек. Странно что ты этого не знаешь.
Pull Request не синхронизирует форк, он же для того чтобы изменения из форка предложить в оригинал?
А форк сихронизируется парой команд, закинь их в планировщик и будет тебе автомат. Но только до первого конфликта.
Вам нужно подключить к системе контроля версий инструменты сравнения и слияния файлов docx
Графическая оболочка TortoiseGit умеет сравнивать и сливать документы средствами самого Word.
Зачем забирать файлы напрямую с рабочего сервера? Синхронизируйте через Git. Можно пуллить сразу на домашний комп, работать и пушить обратно в основной репозиторий.
Если у вас уже есть локальная ветка localb и вы хотите настроить ее на слежение за удалённой веткой upstream2/master, то воспользуйтесь параметрами `-u` или `--set-upstream-to` для команды `git branch`, чтобы явно установить отслеживание.
Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. В репозитории фактически удаляется старый файл и создаётся идентичный новый, но с другим именем.
git status показывает что файл переименован, только после того, как вы проиндексируете ваши изменения. git mv автоматически индексирует переименовынный файл.
Подробнее...
это эквивалентно выполнению следующих команд mv 1.txt 2.txt
git rm 1.txt
git add 2.txt
А после git reset head^ индекс чист, поэтому статус показывает так.
Вам поможет команда git reset --soft head^, которая как раз восстанавливает индекс тоже.
И статус уже сразу покажет что файл переименован.
Ключи подхватываются автоматически и не привязаны ни к какой почте. Не очень понятно что пытаешься переключить и зачем. Если надо подписывать коммиты разной почтой в разных репозиториях, то запиши эти параметры непосредственно в репозитории. Не --global, а git config --local user.email...
И какое отношение сайт твоей почтовой системы имеет к подписям коммитов? Ты же можешь туда написать абсолютно любое мыло, хоть gates@microsoft.com. Для это не надо нигде авторизовываться.
А вместо танцев с бубном с ключами, проще работать через https.
Лучше покажи что не получается в самом клонировании.