Что делать, это именно то, что говорит вам Git: либо совершить public/appName/js/password-change.js, либо убрать его с дороги.
Разве git reset --hard HEAD не должен сбросить все, что я сделал в моей ветке, до того, что было раньше?
Не совсем. Вернее, именно это, но просто это не то, что вы хотите и / или имеете в виду.
Git всегда имеет три"активных" версии каждого отслеживаемого файла. В текущем коммите есть одна копия файла, где он замораживается в той форме, в которой он находился, когда кто-либо делал коммит, делал это. Здесь он также сжимается и сохраняется в форме только для Git, чтобы занимать меньше (может быть, намного меньше) места. Существует вторая копия в месте, которое Git вызывает, по-разному, index , промежуточная область или иногда кеш , в зависимости от о том, кто / какая часть Git выполняет вызов. Индексная копия также находится в форме Git-only, но не совсем заморожена - более слякотная, готовая к замораживанию. Наконец, третья копия - это та, которую вы можете использовать и увидеть: ту, что находится в вашем рабочем дереве, которая имеет свою нормальную форму и, следовательно, вы можете работать с ней или с ней.
Что делает git reset --hard, так это переустанавливает все три копии каждого из этих трех файлов, чтобы они все совпадали с копией в текущем (HEAD) коммите. Ну, это может сделать еще больше, но в этом случае это то, что он делает. Но это не относится к чему-то важному.
Если некоторые файлы отслеживаются , это означает, что другие файлы не отслеживаются . И вот на что Git жалуется: неотслеживаемый файл . Итак: что именно это значит? Что такое отслеживаемый файл?
A отслеживаемый файл - это файл, который в данный момент находится в индексе. Вот и все - это действительно так просто. Файл, который был в коммите, который вы извлекли, попал в индекс из этого коммита и, вероятно, все еще там. Таким образом, файл, который был в коммите, находится в индексе и рабочем дереве. Использование git reset --hard приведет к переустановке индекса и копий рабочего дерева.
неотслеживаемый файл , напротив, является файлом, которого нет в индексе . (Он должен быть в вашем рабочем дереве, иначе он просто не существует вокруг. Если он находится в коммите, git reset --hard вернет его и к индексу, и к рабочему дереву.)
В любом случае, если его сейчас нет в индексе, то либо вы удалили его из индекса, либо его там никогда не было. Последнее имеет тенденцию быть более распространенным, поскольку обычно вы удаляете файлы из индекса, используя git rm <em>file</em>, который удаляет его как из индекса, так и из рабочего дерева. И мы можем быть уверены, что это не входит в ваш HEAD коммит, потому что если бы это было так, git reset --hard вернул бы его в ваш индекс (и переписал бы копию рабочего дерева с подтвержденной копией).
Итак, у вас есть файл, который вы - или кто-то или что-то - создали в рабочем дереве, то есть, конечно, не ни в индексе, ни в текущем коммите. И теперь, запустив git pull, вы сказали Git запустить git merge. (Обратите внимание, что git pull означает run git fetch, затем выполните вторую команду Git, обычно git merge. Вывод, который вы показываете, показывает, что вы получаете не только git merge, но, в частности, fast-forward слияние, которое на самом деле не является слиянием, но имеет много общего.)
Слияние должно взять вашу текущую работу, что бы это ни было, и слить ее с работой другого человека, кем бы он ни был. Чтобы сделать это, Git должен выяснить, что они сделали, и объединить это с тем, что вы сделали. Хотя мы не можем точно увидеть, что они сделали из того, что вы опубликовали, они добавили добавление нового файла .
Новый файл, который они добавили, это тот, который у вас есть как неотслеживаемый. То есть у вас есть:
public/appName/js/password-change.js
белыйich не отслеживается - не в вашем индексе. Они сообщают версию этого файла. У Git нет замороженной копии вашей версии этого файла, чтобы сохранить ее в безопасности. Использование git merge просто перезапишет вашу копию public/appName/js/password-change.js их копиями. Итак, git merge говорит вам, что этот файл в пути: вы должны зафиксировать его, чтобы у вас была замороженная копия, которая хранит его в безопасности, или убрать его с пути, чтобы git merge мог написать их Копировать на место.