Я пытаюсь отправить свои файлы на github, используя bash. Они уже есть, и я загружаю более новую версию с новыми строками, кодом и т.д. Но когда я пытаюсь сделать git add а затем git status он говорит:
На ветке мастер
нечего коммитить, рабочий каталог чистый
И файл, который я использую, был только что изменен.
У меня была проблема, когда однажды я установил для индекса git значение "принимать без изменений" в моем файле.
Вы можете сказать git прекратить игнорировать изменения в файле с помощью:
git update-index --no-assume-unchanged path/to/file
Если это не поможет, то reset может быть достаточно для других странных случаев.
На практике я обнаружил удаление кэшированного файла и сброс его на работу:
git rm --cached path/to/file
git reset path/to/file
git rm --cached означает только удалить файл из индекса, а reset сообщает git перезагрузить индекс git от последнего коммита.
Еще одна возможная причина (которая оказалась верной в моем текущем случае). Проверьте ваш файл .gitignore. Вы можете обнаружить, что файл или расширение файла, с которым вы пытаетесь работать, зачислен в .gitignore что объясняет, почему он не распознается как измененный файл.
Ну, нам не достаточно, чтобы ответить на этот вопрос, поэтому я дам вам несколько догадок:
1) вы спрятали свои изменения, чтобы исправить тип: git stash pop
2) у вас были изменения, и вы их совершили, вы сможете увидеть свою фиксацию в git log
3) у вас были какие-то изменения git reset --hard или другие, ваши изменения могут быть там в reflog, введите git reflog --all, а затем проверите или выберите cherry-pick ref, если вы когда-нибудь его найдете.
4) вы проверили одно и то же репо несколько раз, и вы ошибаетесь.
У нас была такая забавная вещь, как это происходит. Плагин Eclipse Kepler git автоматически маркировал все папки моего проекта как проигнорированные в папке .gitignore.
Когда я перейду к commit в меню Team, все они вернутся к игнорированию. Насколько я могу судить, это было потому, что я бы установил их как полученные в родительском проекте. Отметив их как dervied, исправлено это. Я никогда не видел этого раньше на Индиго. Надеюсь, это поможет кому-то.
У меня была похожая проблема при использовании Sublime Text-3. После внесения новых изменений в код и его сохранения, когда я попробовал команды git add./status, ответ был "уже обновлен". Я выяснил, что независимо от сохранения обновлений в текстовом редакторе, файл фактически не изменился. Открытие файла в другом редакторе и сохранение изменений работало для меня.
Звучит безумно, но иногда вы не в правильном репо, даже если вы так думаете. Например, вы, возможно, переместили родительский каталог, но забыли переключить репозитории в своем текстовом редакторе. Или наоборот: вы находитесь в правильном репо в текстовом редакторе, но не в репо в командной строке. В первой ситуации вы вносите изменения в правильный файл, но это не та папка, которая открывается в командной строке, поэтому это на самом деле неправильный файл. Во второй ситуации вы действительно отредактировали нужный файл, но ваша командная строка git не распознает это изменение, потому что вы находитесь не в правильном каталоге в командной строке.
Как это уже обсуждалось, файлы, вероятно, были помечены как "предположим, что они не изменены", что в основном говорит git, что вы не будете изменять файлы, поэтому им не нужно отслеживать изменения вместе с ними. Однако это может повлиять на несколько файлов, и если это большое рабочее пространство, вы можете не захотеть проверять их все по одному. В этом случае вы можете попробовать: git update-index --really-refresh
в соответствии с документами:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
Это в основном заставит git отслеживать изменения всех файлов независимо от флагов "предположить, что они не изменены".
TL; DR; Вы даже в правильном хранилище?
Моя история немного смешная, но я подумал, что это может случиться с кем-то, у кого может быть похожий сценарий, поэтому делюсь им здесь.
На самом деле на моей машине у меня было два отдельных репозитория git repo1 и repo2 настроенных в одном корневом каталоге с именем source. Эти два репозитория по сути являются репозиториями двух продуктов, над которыми я работаю в своей компании. Теперь дело в том, что в качестве стандартного руководства структура каталогов исходного кода всех продуктов в моей компании точно такая же.
Поэтому, не понимая, я изменил точно такой же файл в repo2 который я должен был изменить в repo1. Итак, я просто продолжал выполнять команду git status на repo1 и она продолжала выдавать одно и то же сообщение
На ветке мастер
нечего коммитить, рабочий каталог чистый
в течение получаса. Тогда мой коллега заметил, что это независимая пара глаз, и обратил внимание на то, что я был в неправильном, но очень похожем хранилище. В тот момент, когда я переключился на repo1 Git начал замечать измененные файлы.
Не очень распространенный случай. Но вы никогда не знаете!
Это происходило в Windows при изменении файлов путем передачи различий с помощью инструмента WinMerge. Очевидно, что WinMerge (по крайней мере, так, как он настроен на моем компьютере) иногда не обновляет временные метки файлов, которые он изменяет.
В Windows git status использует, среди прочего, метку времени файла и изменения размера файла, чтобы определить, изменился ли файл. Таким образом, поскольку отметка времени не обновлялась, у нее был только размер файла. К сожалению, рассматриваемый файл был простым файлом версии, содержимое которого изменилось с 7.1.2 до 7.2.0. Другими словами, размер файла также остался неизменным. Другие файлы, которые также были изменены WinMerge и не обновили свои метки времени, но имели другой размер после того, как изменения были обнаружены git status очень хорошо.
В общем, с этой проблемой, сначала проверьте, что вы редактируете файл, который, как вы думаете, вы! У меня была эта проблема, когда я редактировал файл с расширением JavaScript вместо исходного файла (версия с расширением не находилась под контролем источника).
Какой файл вы пытаетесь загрузить? Теперь я просто потрачу почти час, чтобы загрузить мою модификацию css. Но этот css составлен из стильного файла, поэтому git просто проигнорировал его. Когда я сменил стильный источник, все сработало.
Надеюсь, что это поможет.
У меня была эта проблема. Моя работа не работала, потому что я помещал свои файлы в папку .git внутри моего проекта.
Мой Git клиент (Gitg) вызвал эту проблему для меня. Обычные команды, которые я обычно запускал, не работали. Даже касание каждого файла в проекте не работает.
Я нашел способ исправить это, и я все еще не уверен, что вызвало его. Скопируйте каталог проекта. Недопустимые файлы будут отображаться в скопированном каталоге git status. Переименование может сделать то же самое.
Вы переместили каталог из-под своей оболочки? Это может произойти, если вы восстановили свой проект из резервной копии. Чтобы это исправить, просто cd и вернитесь:
cd ../
cd -
Иногда зависят и от версии git, и если вы забудете сделать git add. ,
Чтобы проверить изменения в репозитории, всегда используйте git status котором отображаются все неотслеживаемые и измененные файлы. Потому что git diff показывает только добавленные файлы.
Не создавайте символические ln -s source dest (ln -s source dest) внутри Git Bash для Windows.
Это НЕ делает символические ссылки, но делает ГЛУБОКУЮ копию источника к месту назначения
Я испытал то же поведение, что и OP на терминале MINGW64 из Git Bash для Windows (версия 2.16.2), чтобы понять, что мои "отредактированные" изменения действительно были в исходном каталоге, а мои команды git bash были из глубокой копии, которая осталась без изменений.
У меня такая же проблема. Оказывается, у меня было две копии проекта, и мой терминал был в неправильной папке проекта!
Столкнулся с проблемой, но это были только две директории, и мне было неизвестно, что обе эти директории были настроены как подмодули git. Как это произошло, я понятия не имею, но процесс состоял в том, чтобы следовать некоторым инструкциям по этой ссылке, но НЕ удалять каталог (как он это делает в конце), а сделать git add path/to/dir
Когда вы редактируете файл в Visual Studio, он сразу же попадает в список изменений git, даже если файл не сохранен. Поэтому все, что вам нужно сделать, это просто сохранить файл вручную (Ctrl + S для текущего отображаемого файла или Ctrl + Shift + S для всех файлов проекта), и git bash подберет их.
попробуйте использовать git add *
то git commit