Типичным объявлением переменной является
extern int x;
. Поскольку это только объявление, требуется одно определение. Соответствующим определением будет:
int x;
Например, следующее генерирует ошибку:
extern int x;
int main()
{
x = 0;
}
//int x; // uncomment this line for successful definition
Аналогичные замечания относятся к функциям. Объявление функции без ее определения приводит к ошибке:
void foo(); // declaration only
int main()
{
foo();
}
//void foo() {} //uncomment this line for successful definition
Будьте осторожны, чтобы выполняемая вами функция точно соответствовала той, которую вы объявили. Например, у вас могут быть несогласованные cv-квалификаторы:
void foo(int& x);
int main()
{
int x;
foo(x);
}
void foo(const int& x) {} //different function, doesn't provide a definition
//for void foo(int& x)
Другие примеры несоответствий включают
Сообщение об ошибке из компилятора часто дает вам полное объявление переменной или функции, которая была объявлена, но не определена. Сравните его с определением, которое вы указали. Убедитесь, что каждая деталь соответствует.
У меня была аналогичная проблема, и я использовал шаг выше , чтобы удалить файл. Он отлично работал.
Затем я получил ошибку во втором файле, который мне нужно удалить: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB
Я попробовал тот же шаг, получил ошибку: "A previous backup already exists in <path/filename>"
Из исследования этого веб-сайта я использовал команду: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all
Работал отлично, и большие файлы были удалены.
Невероятно, все еще не удалось с другой ошибкой: error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly
Это я исправил, напрямую изменив конфигурационный файл .git - postBuffer = 999999999
. После этого нажатие прошло!
Если файл был добавлен с вашей последней фиксацией, и вы не нажали на GitHub, вы можете удалить файл и внести поправки в commit, взятый из здесь :
git rm --cached giant_file
# Stage our giant file for removal, but leave it on disk
git commit --amend -CHEAD
# Amend the previous commit with your change
# Simply making a new commit won't work, as you need
# to remove the file from the unpushed history as well
git push
# Push our rewritten, smaller commit
Я нашел squashing более полезным, чем filter-branch
. Я сделал следующее:
git reset
--soft HEAD~3
git commit -m
"New message for the combined commit"
Вы можете использовать
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD
. Это приведет к удалению всего в истории этого файла. Проблема в том, что файл присутствует в истории.
Git хранит всю историю вашего проекта, поэтому даже если вы удалите файл из своего проекта, Git repo все еще есть копия файла в его истории, и если вы попытаетесь нажать на другой репозиторий (например, один в GitHub), то для Git требуется , удаленное репо имеет ту же историю, что и в вашем локальном репо ( т.е. те же самые большие файлы в его истории).
Вам нужно очистить историю Git вашего проекта локально, удалив нежелательные большие файлы из всей истории, а затем использовать только «очищенную» историю в будущем.
Лучший инструмент для очистки нежелательных больших файлов из истории Git BFG Repo-Cleaner - это более простая и быстрая альтернатива git-filter-branch
, специально разработанная для удаления нежелательных файлов из истории Git.
Тщательно следуйте инструкциям по использованию , основная часть - это:
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git
Любые файлы размером более 100 МБ (которые не входят в ваш последний коммит ) будут удалены из вашего репозитория Git история. Затем вы можете использовать git gc
для удаления мертвых данных:
$ git gc --prune=now --aggressive
BFG обычно не менее 10-50x быстрее, чем запуск git-filter-branch
, и обычно
Полное раскрытие: я являюсь автором BFG Repo-Cleaner.
У меня такая же проблема, и ни один из ответов не работает для меня. Я решил следующие шаги:
git log --all -- 'large_file`
Нижняя фиксация является самой старой фиксацией в списке результатов.
git log
Предположим, что вы получили:
commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
Советы:
drop
для коммитов, содержащих большой файл. git rebase --continue
, чтобы продолжить, пока не закончите. git rebase --abort
, чтобы отменить его.