Я намагаюся надсилати свої файли до github за допомогою bash. Вони вже там, і я завантажую нову версію з новими рядками та кодом і т. Д. Але коли я намагаюся, git addа потім git statusпише:
На майстрі гілки
нічого не фіксувати, робочий каталог чистий
І файл, який я використовую, був щойно змінений.
git diff(або git status) не показує нічого, що пояснює, чому немає чого додати. Тож питання насправді: "Чому git не визнає, що мій файл змінено?"
Відповіді:
У мене була проблема, коли колись давно я встановив git-індекс на `` приймати незмінним '' у своєму файлі.
Ви можете сказати git припинити ігнорувати зміни у файлі за допомогою:
git update-index --no-assume-unchanged path/to/file
Якщо це не допомагає, скидання може бути достатньо для інших дивних випадків.
На практиці я виявив видалення кешованого файлу та відновлення його роботи:
git rm --cached path/to/file
git reset path/to/file
Засіб git rm --cachedлише видалити файл з індексу та resetговорить git перезавантажити git index з останнього коміту.
git add -f path/to/the/fileвін примусово додасть файли для коміту.
git add -fфайл, який знаходився у такому "припустимо незмінному" стані, і він не спрацював - мусив або, git update-indexабо git rm --cachedпісля нього a, git resetщоб він працював.
git rm --cached -r .а потім git reset ..
git update-index --no-skip-worktree path/to/fileтаким чином я вирішив свою проблему
Перевірте свій .gitignoreфайл . Ви можете виявити, що файл, або розширення файлу, або шлях до файлу, з яким ви намагаєтесь працювати, відповідає запису .gitignore, що пояснює, чому цей файл ігнорується (а не розпізнається як змінений файл).
Це виявилося для мене, коли у мене була подібна проблема.
lib/, що змушує git ігнорувати цю папку. З цим немає проблем - принаймні, якщо ця папка не є основною папкою вашого проекту, як, наприклад, те, що сталося зі мною.
Звучить божевільно, але іноді ви не в правильному репо, хоча думаєте, що є. Наприклад, ви могли перенести батьківський каталог, але забули змінити репозиторії у текстовому редакторі. Або навпаки: ви знаходитесь у правильному репо в текстовому редакторі, але неправильне репо в командному рядку. У першій ситуації ви вносите зміни у потрібний файл, але це не та сама папка, яка відкрита у вашому командному рядку, тому насправді це неправильний файл. У другій ситуації ви насправді відредагували правильний файл, але ваш командний рядок git не розпізнає зміни, оскільки ви знаходитесь не у правильному каталозі в командному рядку.
Як вже було обговорено, файли, ймовірно, були позначені позначкою "взяти-не змінити", що в основному говорить git, що ви не будете модифікувати файли, тому йому не потрібно відстежувати зміни з ними. Однак це може впливати на кілька файлів, і якщо це велика робоча область, ви, можливо, не захочете перевіряти їх усі по одному. У цьому випадку ви можете спробувати: git update-index --really-refresh
згідно з документами:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
Це в основному змусить git відстежувати зміни всіх файлів незалежно від прапорів "припустити незмінним".
git statusкажуть, що файли не змінюються, але git add .додає два файли і git update-index --really-refreshкаже, що ці два потребують оновлення, але, здається, нічого не роблять. Будь-яка ідея?
git ls-files -v | grep '^[[:lower:]]'Якщо нічого не допомагає, створіть запитання з додатковою інформацією, щоб ми могли допомогти ви.
ну, у нас недостатньо, щоб відповісти на це питання, тому я дам вам кілька здогадок:
1) Ви сховали свої зміни, щоб виправити тип: git stash pop
2) у вас були зміни, і ви їх здійснили, ви мали б змогу побачити своє комітування в git log
3) у вас були якісь зміни, якісь git reset --hardабо інші, ваші зміни можуть бути там у перегляді, введіть текст із git reflog --allподальшим виїздом або вибором виправлення, якщо ви коли-небудь знайдете його.
4) ви перевіряли одне і те ж репо кілька разів, і ви потрапили не в те.
git commit --amendякі внесуть ваші нові зміни у ваш останній коміт , не робіть цього, якщо ви вже поділилися своїм комітом.
Було таке забавне, як це. Git-плагін Eclipse Kepler автоматично позначав усі мої папки проекту як проігноровані в папці .gitignore.
Коли я отримав commitв Teamменю, вони всі готові повернутися до проігноровані. Наскільки я можу зрозуміти, це було тому, що я встановив їх як похідні в батьківському проекті. Позначення їх як derviedвиправлене. Я ніколи раніше не бачив цього на "Індіго". Сподіваюся, це комусь допоможе.
TL; DR; Ви навіть у правильному сховищі?
Моя історія трохи смішна, але я думав, що це може трапитися з кимось, у кого може бути схожий сценарій, тому ділюсь цим тут.
Насправді на моїй машині я мав два окремі сховища git repo1і repo2настроював їх в одному кореневому каталозі source. Ці два сховища - це, по суті, сховища двох продуктів, які я розробляю та працюю у своїй компанії. Зараз справа в тому, що як стандартна настанова, структура каталогів вихідного коду всіх продуктів абсолютно однакова в моїй компанії.
Отже, не підозрюючи, я змінив точно такий самий файл, в repo2якому я повинен був змінитись repo1. Таким чином, я просто продовжував працювати команду git statusна repo1і продовжував давати те саме повідомлення
На майстрі гілки
нічого не фіксувати, робочий каталог чистий
півгодини. Потім мій колега спостерігав за нею як за незалежну пару очей і довів це до відома, що я потрапив у неправильне, але схоже схоже сховище. У той момент, коли я перейшов на repo1Git, я почав помічати змінені файли.
Не такий поширений випадок. Але ніколи не знаєш!
Це траплялося в Windows під час зміни файлів шляхом передачі відмінностей за допомогою інструмента WinMerge. Очевидно, WinMerge (принаймні так, як це налаштовано на моєму комп'ютері) іноді не оновлює позначки часу файлів, які він змінює.
У Windows git status , серед іншого, використовує позначку часу файлу та зміни розміру файлу, щоб визначити, змінився файл чи ні. Отож, оскільки мітка часу не була оновлена, вона мала лише розмір файлу. На жаль, файл, про який йде мова, був простим файлом версії, вміст якого змінився з 7.1.2 на 7.2.0 . Іншими словами, розмір файлу також залишився незмінним. Інші файли, які також були змінені WinMerge і не оновлювали мітки часу, але мали інший розмір після того, як зміни були виявлені за допомогою стану git .
У мене була подібна проблема під час використання Sublime Text-3 . Після внесення нових змін у код та збереження його, коли я спробував команди git add ./status, відповідь була "гілка вже оновлена". Я зрозумів, незалежно від збереження оновлень у текстовому редакторі, файл фактично не змінився. Відкриття файлу в іншому редакторі та збереження змін у мене спрацювали.
Ви перемістили каталог з-під вашої оболонки? Це може статися, якщо ви відновили проект із резервної копії. Щоб виправити це, просто cdвийдіть і поверніться:
cd ../
cd -
Загалом із цією проблемою спершу перевірте, чи редагуєте ви файл, яким вважаєте себе! У мене була ця проблема, коли я редагував перекладений файл JavaScript замість вихідного файлу (перекладена версія не перебувала під контролем джерела).
Мій клієнт Git (Gitg) спричинив цю проблему для мене. Звичайні команди, які я зазвичай виконую, не працювали. Навіть торкання кожного файлу в проекті не спрацювало.
Я знайшов спосіб це виправити, і досі не впевнений, що це спричинило. Скопіюйте каталог проекту. Відсутні файли відображатимуться у скопійованому каталозі git status. Перейменування може зробити те саме.
Натрапив на проблему, але це було лише два каталоги, і мені невідомо, що в кінцевому підсумку обидва ці каталоги були налаштовані як підмодулі git. Як це сталося, я не маю уявлення, але процес полягав у тому, щоб слідувати деяким інструкціям за цим посиланням, але НЕ видаляти каталог (як це робить наприкінці), а навпакиgit add path/to/dir
Коли ви редагуєте файл у Visual Studio, він негайно відображається у git, навіть якщо файл не збережено. Отже, все, що вам потрібно зробити, це просто зберегти файл вручну (Ctrl + S для поточно відображається файлу або Ctrl + Shift + S для всіх файлів проекту), і git bash їх підбере.
.jsфайлу, роботи з Visual Studio Code. Дякую.
Переконайтеся , що НЕ створювати символічні посилання ( ln -s source dest) з внутрішньої Git Bash для Windows.
Він НЕ робить символічних посилань, але робить ГЛИБОКУ копію джерела до dest
Я відчув таку ж поведінку, як OP на терміналі MINGW64 від Git Bash для Windows (версія 2.16.2), зрозумівши, що мої `` відредаговані '' зміни насправді були у вихідному каталозі, а мої команди git bash були з глибокої копії, яка залишилася без змін.
Це трапилось і зі мною, я спробував вищезазначені методи і нічого не допомогло. Тоді рішенням було змінити файл через термінал, а не через графічний інтерфейс. Я не знаю, чому це працювало, але працювало. Після того, як я відредагував файл через nano із терміналу, git розпізнав його як змінений, і я зміг додати його та здійснити.
у мене така ж проблема тут VS2015 не розпізнав зміни моїх файлів js, видаливши пульти з налаштувань сховища, а потім повторне додавання віддаленого шляху URL-адреси вирішило мою проблему.
У моєму випадку виконую git reset --hardвидалені файли і залишаю кілька порожніх папок. Перевіривши вміст, я помітив, що каталоги порожні.
Однак git ігнорує порожні папки. (Виправлення, git ігнорує всі каталоги, оскільки відстежує вміст, порожні папки не є вмістом.)
спробуйте використати git add *
тодіgit commit