Если уже изменил автора локальных коммитов, то отправь их заново через push --force, тогда и Pull Request обновится тоже.
Но смущает сама формулировка вопроса. В Git нет аккаунтов, это утилита командной строки. Коммиты подписываются произвольным именем и e-mail, которые берутся из конфига. Если имелся в виду аккаунт Гитхаба, то он никак не влияет на автора коммитов. Сами коммиты никак не меняются при отправке в вышестоящий репозиторий. Аккаунт виден только в данных пулл-реквеста и не сохраняется в самих коммитах.
Ты пытаешься скачать ветку master, но в репозитории нет такой ветки. Там есть только main.
На этом шаге тебе и выдаёт ошибку, что не найдено искомой ревизии.
Могу ошибаться, но это называется слиянием поддеревьев
Идея в том, чтобы взять историю коммитов из внешнего проекта, и перенаправить её в подкаталог внутреннего. При этом используется стандартный гитовый механизм работы с внешними ветками.
Это метки неразрешенного конфликта. Сомневаюсь что на гитхаб подобное попало.
Скорее всего ты сам правил код и при обновлении возник конфликт, который ты забыл разрешить.
GotLib1, наверное ты не push сделал, а pull. Вот файлы и затёрлись входящими изменениями.
Откатить можно только то, что было закоммичено, либо сохранено в stash или changelist. Иначе считай потерял работу.
rastr, что не понятно? Там же написано «the remote contains work that you do not have locally»
Т. е. удалённая ветка содержит коммиты, которых нет у тебя локально. Их нужно сначала забрать оттуда и слить с твоей веткой и только потом отправлять в вышестоящий репозиторий.
MalekBV, это называется клонировать репозиторий и только один указатель на ветку.
Загрузится всё равно вся история и полный образ проекта.
В любом случае ты что-то усложняешь. Клонировать репозиторий можно же только в пустой каталог?
Значит тебе придётся всё удалить перед этим. А зачем? Простого switch или checkout достаточно.
Alex Ozerov, а что показывает гит статус и почему ты думаешь что он должен показывать то же самое?
А лишний файл нужно было сначала удалить из индекса git rm файл
Затем пересоздать последний коммит с ним git commit --amend
После можно пушить если ещё не делал это.
Тебе понадобится изначально получить весь репозиторий к себе на комп, а дальше при push и fetch по сети гоняется не весь проект, а только изменения. Причём в сжатом виде. Так что выигрыша ты не получишь никакого.
LoliDeveloper, и кстати так мы удалим файлы только из текущего состояния. Они останутся в истории и будут занимать место. Удалить их полностью немного сложнее ))
Слишком сложно.
Во первых .gitignore никак не влияет на наличие файлов в репозитории. Если файл уже добавили, то он продолжить быть отслеживаеемым независимо от того, какой сейчас .gitignore
Мы можем начать отслеживать (добавить в репозиторий) любой файл, даже добавленный в .gitignore.
Чтобы удалить файл из репозитория, но не удалять из рабочего каталога используется команда git rm --cached и затем коммит.
Тогда не придётся ничего восстанавливать потом. И гитигнор тут вообще не нужен.
Ты не удалил файл в локальном репозитории. Ты лишь удалил его из рабочего каталога, в котором лежит копия ветки master. Файл по прежнему остался и в локальном и во внешнем репозитории. Даже больше скажу — файл невозможно удалить из репозитория. Однажды закоммитив файл, он навсегда останется в истории и в любой момент его можно вытащить оттуда. Удалить файл можно только из какой-то версии ветки.
Хочешь восстановить? Восстанови! Git тебе даже подсказку написал какой командой файл восстановить.
Нет никакой нужды скачивать что-то с внешнего репозитория. Already up to date означает что ветка master в локальном репо полностью идентична ветке master вышестоящего репозитория.
Точно )) на картинке же pull.
Хотя какой смысл что-то скачивать из пустого репозитория? Конечно напишет что main не найден.
Тут явно с авторизацией проблема и push не заработает пока не починишь её.
Ключи не работают или не загружены куда надо.
Lynn «Кофеман», что-то странное ты говоришь. В удалённом репо нет ни main ни master, он же пока пустой?
Команда pull без параметров сработает только когда ветке предварительно привязана вышестоящая ветка (что делает ключ -u)
Но смущает сама формулировка вопроса. В Git нет аккаунтов, это утилита командной строки. Коммиты подписываются произвольным именем и e-mail, которые берутся из конфига. Если имелся в виду аккаунт Гитхаба, то он никак не влияет на автора коммитов. Сами коммиты никак не меняются при отправке в вышестоящий репозиторий. Аккаунт виден только в данных пулл-реквеста и не сохраняется в самих коммитах.