Здесь происходит то, что git думает, что история локального хранилища не совпадает с историей удаленного хранилища. Если вы поймете, как на самом деле работает git, маловероятно, что это неправильно, поэтому я предполагаю, что вы внесли изменения в удаленный репозиторий с тех пор, как выполнили последнюю команду git pull.
Эта цитата подтверждает это:
РЕДАКТИРОВАТЬ: Спасибо, ребята, я удалил файл из удаленного репо после извлечения. Я снова потянул, снова внес изменения и нажал без проблем.
Поскольку теперь вы знаете, в чем причина, вы понимаете, что можете избежать ее, только делая локальные изменения, когда вы знаете, что пульт не был изменен, но это не похоже на очень хороший рабочий процесс, особенно если несколько люди работают над хранилищем. Кроме того, предполагается, что одной из сильных сторон git является то, что несколько человек могут одновременно работать в одном и том же репозитории и все они перемещаются в один и тот же удаленный репозиторий.
Давайте посмотрим, какие команды у вас есть, которые можно использовать, чтобы лучше справиться с этим в будущем:
fetch
Вы всегда можете безопасно fetch внести изменения из удаленного репозитория, не затрагивая вашу рабочую копию или локальные ветви. Это позволит загрузить новую историю из удаленного репозитория в так называемую «ветвь отслеживания», но она не будет применена ни к одной из ваших локальных ветвей и не затронет вашу «рабочую копию».
merge
Слияние попытается применить изменения в другой ветви к заголовку ветви, в которой вы находитесь. Его можно использовать между локальными ветвями или объединять изменения из отслеживающих веток в локальную ветвь. Однако он делает это с помощью 'коммит-слияния', что позволяет вести нелинейную историю. У Git нет никаких проблем с этим, и в небольших дозах люди обычно не слишком обеспокоены этим:
Однако чем больше вы это делаете, тем сложнее становится история, и простым людям может быть сложно отслеживать вещи по мере увеличения сложности:
pull
Это действительно fetch, за которым следует merge:
rebase
Это форма переписывания истории. По сути, вы объединяете изменения из одной ветви в другую, однако, в отличие от обычного слияния, вы не просто связываете две ветви вместе и называете это хорошо, вместо этого вы снимаете изменения, сделанные в одной ветви после двух. ветки разделены, примените изменения из другой ветви, затем повторно примените изменения, которые вы сняли, оставив красивую линейную историю.
До:
После того, как:
pull --rebase
Это (как обычный pull) использует fetch для получения удаленных изменений, но вместо merge он делает rebase, так что вы можете легко использовать только чтобы выполнить одну команду, а также иметь хорошую линейную историю, когда вы оглядываетесь назад на то, что сделали.
[Все изображения в этом ответе также являются ссылкой на то, откуда я их получил.]