Git add не добавляет файлы
Я прошу прощения, если это вопрос новичка, но я искал вокруг, и я ошеломлен, почему это так.
У меня есть несколько файлов, которые я хотел бы добавить и зафиксировать.
git add . Я также пытался git add -A , git add -f -A
git commit -m 'message'
git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp (чтобы убедиться, что моя основная ветвь находится на последнем коммите)
git push origin master
Пока нет никаких изменений. Толчок был успешным. Но файлы не добавляются в мой репозиторий. Что может быть причиной?
Я попытался заново создать папку с помощью rm -rf .git , а затем повторил все шаги. Но когда я делаю git add -A снова, новые файлы все еще не добавляются! Моя папка кажется проклятой или что-то в этом роде.
Результаты ls -la
Результаты git ls-tree HEAD
Я нашел проблему. Я использую Ubuntu, и новые файлы не имеют прав доступа. Мне пришлось дать текущему пользователю права доступа к этим новым файлам с chmod 755 , и после этого он работает.
Извините, я не упомянул об этом в первоначальном вопросе. Спасибо всем, кто предоставил ответы.
3 ответа
Давайте проясним несколько понятий git:
Ваш локальный каталог - это git-репозиторий. Все команды git так или иначе взаимодействуют с локальным хранилищем. Некоторые команды также взаимодействуют с удаленным хранилищем
git add . переместит все файлы в текущем каталоге в промежуточную область вашего локального репозитория. Всякий раз, когда вы делаете это, git всегда добавляет файлы , потому что именно так работает git. Обратите внимание, что «добавление» файлов только ставит их в очередь для следующего git commit .
git commit создает коммит в вашем локальном git-репозитории с файлами, которые вы ранее добавили в промежуточную область. Опять же, эта команда всегда будет делать это. Фактически, вывод git ls-files в вашем посте доказывает, что все ваши файлы были добавлены и переданы в ваш локальный репозиторий.
Ваше локальное хранилище может быть подключено к удаленному хранилищу на GitHub или любом другом сервере, на котором запущен git. Если вы сделаете git clone , у вашего локального репо будет удаленный сервер с именем origin , который указывает на репо, который вы клонировали. Если вы делаете git init вместо этого, вы можете использовать git remote add для добавления пульта с любым именем, которое вы пожелаете.
После настройки удаленного репо в локальном репо вы можете использовать git push для передачи коммитов из локального репо в удаленный. Кроме того, git pull будет передавать коммиты с удаленного в локальное хранилище.
Если он не обнаруживает изменения, то вы можете начать все сначала. Просто удалите файл .git из каталога и повторите инициализацию. Это не может быть хорошей практикой, но если вы новичок в git, то иногда такое исправление помогает.
Также убедитесь, что ваши учетные данные для доступа установлены правильно.
I'm having issues where I can't add files to my repository.
I'm using GIT on windows, in Aptana Studio for some Ruby development.
I've managed to push a few files up to GitHub, but then after this, everything's stopped working. I have for example a new sub-folder in my master directory, with 2 ruby files inside. If I call "git add .", and then "git status" and it keeps saying "working directory clean" and has nothing to commit.
I've tried "git add folder/myfile.rb" and still nothing.
Anyone any idea's what I can try?
It was some foolish mistake on my side, I'm using tortoise git and there is checkbox when you commit any changes, it was unchecked on my side and I have some new files locally only, so be careful with it!
amazingly manojlds suggestion of restarting worked for me. one file was being excluded all of a sudden. after restart it magically worked
31 Answers 31
I found myself in a similar situation as the poster:
If I call "git add .", and then "git status" and it keeps saying "working directory clean" and has nothing to commit.
But I had a different solution than what's here. Since I came to this first, I hope to save others some time.
- Ensure there are actually saved changes on the file in question
- Ensure the file doesn't meet your exclude rules in .gitignore and .git/info/exclude
- Ensure you're not trying to add an empty folder. Git won't track those. Standard solution is to place a blank file named .gitkeep as a placeholder so git will track the folder.
In my case, I had originally tried to create a git repo around an existing repo (not knowing it was there). I had removed the .git folder from this sub repo a while ago, but I didn't realize that it was too late, and git was already tracking it as a submodule. You can read more about how these behave and how to remove them here, but
- the solution for me was to simply run git rm --cached path_to_submodule .
Lifesaver! I simply had to type git rm --cached name_of_former_submodule and it got the path automatically.
I think some files was never added but there had, so a git ls-files showed them and I understand why my git add doesn't had them
To add to the possible solutions for other users:
Make sure you have not changed the case of the folder name in Windows:
I had a similar problem where a folder called Setup controlled by Git and hosted on GitHub, all development was done on a Windows machine.
At some point I changed the folder to setup (lower case S). From that point on when I added new files to the setup folder they were stored in the setup folder and not the Setup folder, but I guess because I was developing on a Windows machine the existing Setup folder in git/github was not changed to setup .
The result was that I couldn't see all of the files in the setup in GitHub. I suspect that if I cloned the project on a *nix machine I would have seen two folders, Setup and setup .
So make sure you have not changed the case of the containing folder on a Windows machine, if you have then I'd suggest:
- Renaming the folder to something like setup-temp
- git add -A
- git commit -m "Whatever"
- Rename the folder back to what you want
- git add -A
- git commit -m "Whatever"
This happened to me with a file name as well. Using git mv -f newFileCase oldFileCase will correct the repository
I had a case issue on osx, unfortunately even though it is a *nux file system it is generally set up as case-insensitive which can cause issues with *nux tools like git.
if you have pending changes in files with "same name" but with a different Case this might also cause the same problem
If the file is excluded by .gitignore and you want to add it anyway, you can force it with:
Thanks a lot! This really helped me. For some reason, my file was excluded (was not in .gitignore so not sure why!), and this fixed my problem!
Odd, but I fought with git all night to add a file. Turns out it was already added. Git wasn't picking up my changes, as the changes weren't being saved, as the file was inaccessible by my account, and my IDE wasn't reporting this over SSH.
In short, check to make sure you don't have it already added to the repository.
. thinking of this, git could add a message if any of the given paths is entirely already in the repository. it would have saved at least 13 people a few minutes.
I just had this issue and the problem was that I was inside a directory and not at the top level. Once I moved to the top level it worked.
I'm sure I could have used git add .. or whatever required to get to the level under which my changes existed and it also would have worked. This is just a gotcha problem here (my user error).
Double check your .gitignore file to make sure that the file is able to be seen by Git. Likewise, there is a file .git/info/exclude that 'excludes' files/directories from the project, just like a .gitignore file would.
Best bet is to copy your folder. Delete the original. Clone the project from github, copy your new files into the new cloned folder, and then try again.
This worked for me using git on CygWin and getting some "permissions out of order" messages. I didn't even need to clone and copy the changed files, I just duplicated the directory as it was. I think forcing Windows to re-write everything means that it corrects the permissions problems.
I had this problem with the first program in the folder. I did "git add" then "git commit". "git status" gave the error described i.e. "nothing to commit, working directory clean"
I ended up deleting the .git file from the program folder. Then I did a new git init, git add and git commit and it worked.
For me it was the other way around. I was in a merge (rebase) conflict and I had to cd into the folder to git add the file.
This will add the folder and all it's files with a single command.
Please note, git is not able to store empty folders.
If commit didn't worked, the first place you should check is probably .gitignore .
Here you can find an answer to the same problem:
basically in this case the problem was the global_git ignore
In my case the issue was enabled SafeCrLf option. I am on windows with tortoise git. After disabling the option adding the files was not an issue anymore.
Another issue can be file permissions. Try issuing : chmod 755 file1
I had a similar issue.
The problem was, on Windows, in the index, the file was added in a case different from what was in the unstaged area. For example, in the index, the file was name xx.txt and in the unstaged area, the file was names Xx.txt .
Removed the file with the incorrect case from the index ( xx.txt ). Then, I have been able to add the file with the correct case ( Xx.txt ).
I am still a beginner at git, and it was just a stupid mistake I made, long story in one sentence. I was not in a subfolder as @gaoagong reported, but the other way round, in a parent folder. Strange enough, I did not get the idea from that answer, instead, the idea came up when I tested git add --all , see the long story below.
Example in details. Actual repo:
The Parent folder that I had opened mistakenly on parent level (vscode_git in my case):
I had cloned a repo, but I had a parent folder above this repo which I had opened instead, and then I tried adding a file of the subfolder's repo with git add 'd:\Stack Overflow\vscode_git\vscode-java\.github\ISSUE_TEMPLATE.md' , which simply did nothing, no warning message, and the git status afterwards said:
nothing added to commit but untracked files present (use "git add" to track)
Running git add --all gave me the yellow notes:
warning: adding embedded git repository: vscode-java the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use: git submodule add vscode-java
hint: If you added this path by mistake, you can remove it from the index with git rm --cached vscode-java
See "git help submodule" for more information.git
To fix this, I reverted the git add --all with git rm --cached -r -f -- "d:\Stack Overflow\vscode_git\vscode-java" rm 'vscode-java' :
Then, by simply opening the actual repo folder instead,
the git worked as expected again. Of course the ".git" folder of the parent folder could be deleted then:
Столкнулся с этим впервые, другой проект нормально залился в репозиторий.
Вот порядок действий:
Захожу в локальную папку проекта
cd ~/project
Инициализирую гит
git init
Фоловлю файлы
git add .
И тут он пишет мне:
warning: LF will be replaced by CRLF in *file_name*
The file will have its original line endings in your working directory.
После чего выполняю коммит и он пишет:
В гите новичок. Гуглил, способы решения не подошли.
Инициализируем новый репозиторий
git init
Добавляем файлы (все)
git add .
Если файлы не добавляются, то добавляем каждый вручную
git add README.md
Делаем коммит
git commit -m "First commit"
Пушим
git push -u origin master
warning: LF will be replaced by CRLF in *file_name*
The file will have its original line endings in your working directory.
В GitBash (Windows)
Пишет что заменит LF на CRLF (will be):
Но он не делает этого:
Или он изменяет это в слепках файлов проекта?
FoxInSox: в конечном итоге мне надо сделать коммит, но он не хочет этого делать, так как файлы находятся в статусе "untracked", и, как следствие, надо выполнить git add . , но он не выполняется
Сергей Шилов, вопрос как-то решился? я пока что тоже не могу ничего добавить, пересоздавать папки не охото. Помогает только коммит через GitHub Desktop
Связанно это с тем что переносы строк были в Unix-формате, так как дело происходило под Windows.
Простые решения:
Очень просто конвертировать переносы строк в Windows-формат помогает текстовый редактор Notepad++: Правка→EOL конверсия→Преобразовать в WIN-формат.
Подробнее.
Вручную преобразовать символы перевода строки из виндовых в линуксовые, открыть файл, еще раз визуально все проконтролировать и сохранить.
Быстро заменить CRLF на LF можно утилитой dos2unix, входящей в MINGW, с которым поставляется git для win32:
У меня возникают проблемы, когда я не могу добавлять файлы в свой репозиторий.
Я использую GIT в Windows в Aptana Studio для разработки на Ruby.
Я пробовал "git add folder / myfile.rb" и все равно ничего.
Кто-нибудь знает, что я могу попробовать?
С моей стороны это была какая-то глупая ошибка, я использую черепаховый git, и когда вы фиксируете какие-либо изменения, есть флажок , он не был отмечен на моей стороне, и у меня есть некоторые новые файлы только локально, так что будьте осторожны с этим!
Я оказался в ситуации, похожей на плакат:
Если я вызываю «git add.», А затем «git status», он продолжает говорить «рабочий каталог чист» и мне нечего фиксировать.
Но у меня было другое решение, чем здесь. Поскольку я пришел к этому первым, я надеюсь сэкономить время другим.
- Убедитесь, что в рассматриваемом файле действительно сохранены изменения.
- Убедитесь, что файл не соответствует вашим правилам исключения в .gitignore и .git/info/exclude
- Убедитесь, что вы не пытаетесь добавить пустую папку. Git их не отслеживает. Стандартное решение - поместить пустой файл с именем- .gitkeep заполнителем, чтобы git отслеживал папку.
В моем случае я изначально пытался создать репозиторий git вокруг существующего репо (не зная, что он там был). .git Некоторое время назад я удалил папку из этого вспомогательного репо, но я не осознавал, что было слишком поздно, и git уже отслеживал его как подмодуль . Вы можете узнать больше о том, как они себя ведут и как их удалить, здесь , но
- решение для меня было просто бежать git rm --cached path_to_submodule .
Спасатель! Мне просто нужно было ввести, git rm --cached name_of_former_submodule и путь был получен автоматически.
@MuhammadUmer На странице подмодулей официального файла readme Git более подробно объясняется, что они из себя представляют.
Чтобы добавить к возможным решениям для других пользователей:
Убедитесь, что вы не изменили регистр имени папки в Windows:
У меня была аналогичная проблема, когда папка, называемая Setup управляемой Git и размещенная на GitHub, вся разработка выполнялась на машине Windows.
В какой-то момент я изменил папку на setup (нижний регистр S). С этого момента, когда я добавил новые файлы в папку установки, они хранились в setup папке, а не в Setup папке, но я предполагаю, что, поскольку я разрабатывал на машине Windows, существующая Setup папка в git / github не была изменена на setup .
В результате я не мог видеть все файлы setup в GitHub. Я подозреваю, что если бы я клонировал проект на машине * nix, я бы увидел две папки Setup и setup .
Поэтому убедитесь, что вы не изменили регистр содержащейся в папке папки на компьютере с Windows, если да, то я бы предложил:
- Переименование папки во что-то вроде setup-temp
- git add -A
- git commit -m "Whatever"
- Переименуйте папку обратно в то, что вы хотите
- git add -A
- git commit -m "Whatever"
Это случилось со мной и с именем файла. Использование git mv -f newFileCase oldFileCase исправит репозиторий
У меня была проблема с osx, к сожалению, хотя это файловая система * nux, она обычно настроена без учета регистра, что может вызвать проблемы с инструментами * nux, такими как git.
если у вас есть ожидающие изменения в файлах с «тем же именем», но с другим случаем, это также может вызвать ту же проблему
Если файл исключен .gitignore и вы все равно хотите добавить его, вы можете принудительно добавить его:
Большое спасибо! Это мне действительно помогло. По какой-то причине мой файл был исключен (не был, .gitignore поэтому не знаю почему!), И это устранило мою проблему!
Странно, но я всю ночь боролся с git, чтобы добавить файл. Оказывается, он уже был добавлен. Git не улавливал мои изменения, поскольку изменения не сохранялись, так как файл был недоступен для моей учетной записи, и моя IDE не сообщала об этом через SSH.
Короче говоря, убедитесь, что он еще не добавлен в репозиторий.
Дважды проверьте свой .gitignore файл, чтобы убедиться, что он доступен для просмотра Git. Точно так же есть файл, .git/info/exclude который «исключает» файлы / каталоги из проекта, как и .gitignore файл.
У меня была эта проблема, и проблема заключалась в том, что я находился внутри каталога, а не на верхнем уровне. Когда я перешел на верхний уровень, все заработало.
Я уверен, что мог бы использовать git add .. или все необходимое, чтобы добраться до уровня, на котором существовали мои изменения, и это тоже сработало бы. Это просто проблема (моя ошибка пользователя).
Лучше всего скопировать вашу папку. Удалите оригинал. Клонируйте проект из github, скопируйте новые файлы в новую клонированную папку и повторите попытку.
У меня была такая проблема с первой программой в папке. Я сделал «git add», затем «git commit». "git status" выдает описанную ошибку, т.е. "ничего не фиксировать, рабочий каталог чист"
В итоге я удалил файл .git из папки программы. Затем я сделал новый git init, git add и git commit, и он сработал.
Для меня все было наоборот. У меня был конфликт слияния (перебазирования), и мне пришлось перейти cd в папку с git add файлом.
Как насчет стандартной процедуры:
Это добавит папку и все файлы с помощью одной команды.
Обратите внимание, что git не может хранить пустые папки.
Если фиксация не сработала, возможно, в первую очередь вам следует проверить .gitignore .
Вот вы можете найти ответ на ту же проблему:
в основном в этом случае проблема заключалась в игнорировании global_git
В моем случае проблема заключалась в включенной опции SafeCrLf. Я нахожусь в окнах с черепаховым мерзавцем. После отключения опции добавление файлов больше не было проблемой.
Другой проблемой могут быть права доступа к файлам. Попробуйте выдать: chmod 755 file1
Невозможно (для меня) добавить первый файл в пустой репозиторий, клонированный с GitHub . Вам нужно перейти по ссылке README, которую предлагает создать GitHub. После того, как вы создадите свой первый файл в Интернете , вы сможете нормально работать с git.
Это случилось со мной 17 ноября 2016 года.
Я все еще новичок в git, и это была просто глупая ошибка, которую я сделал, длинная история в одном предложении. Я был не во вложенной папке, как сообщил @gaoagong, а, наоборот, в родительской папке. Как ни странно, я не понял эту идею из этого ответа, вместо этого идея возникла во время тестирования git add --all , см. Длинную историю ниже.
Пример в деталях. Фактическое репо:
Родительская папка, которую я по ошибке открыл на родительском уровне (в моем случае vscode_git):
ничего не добавлено для фиксации, но присутствуют неотслеживаемые файлы (для отслеживания используйте "git add")
Бег git add --all дал мне желтые записки:
предупреждение: добавление встроенного репозитория git: vscode-java встроенный репозиторий и не будет знать, как его получить.
Подсказка: если вы хотели добавить подмодуль, используйте: git submodule add vscode-java
совет: если вы добавили этот путь по ошибке, вы можете удалить его из индекса с помощью git rm --cached vscode-java
См. "Подмодуль git help" для получения дополнительной информации. Git
Затем, просто открыв вместо этого фактическую папку репо,
git снова работал, как ожидалось. Конечно, тогда можно удалить папку ".git" родительской папки:
О мастере филиала
ничего не фиксировать, рабочий каталог чист
И файл, который я использую, был только что изменен.
Если git diff (или git status ) не показывает ничего, что объясняет, почему нечего добавить. Итак, вопрос действительно таков: «Почему git не распознает, что мой файл был изменен?»
У меня была проблема, когда однажды я установил для индекса git значение «считать неизменным» в моем файле.
Вы можете указать git, чтобы он перестал игнорировать изменения в файле:
Если это не поможет, сброса может быть достаточно для других странных случаев.
На практике я обнаружил, что удалил кешированный файл и заставил его работать:
В git rm --cached средстве для только удалить файл из индекса, и reset говорит мерзавец перезагрузить индекс GIT от последней фиксации.
Этот ответ был единственным, который помог решить мою проблему. Не уверен, что это связано с Windows (у меня никогда не было подобных проблем в прошлом, ни в OSX, ни в Linux). Так что спасибо @ThorSummoner. Между прочим, я попробовал git add -f файл, который находился в этом состоянии «предположить неизменным», и он не сработал - нужно было либо, git update-index либо git rm --cached после него, git reset чтобы он заработал.
Кроме того, если вы действительно не уверены в текущем состоянии своего репо, сделайте следующее: git rm --cached -r . а затем git reset . .
Есть еще один вариант, чтобы попробовать, git update-index --no-skip-worktree path/to/file вот как я решил свою проблему
Проверьте свой .gitignore файл . Вы можете обнаружить, что файл или расширение файла, или путь к файлу, с которым вы пытаетесь работать, совпадает с записью .gitignore , что объясняет, почему этот файл игнорируется (и не распознается как измененный файл).
Это случилось со мной, когда у меня была аналогичная проблема.
Я использовал gitignore.io для создания своего .gitignore и нашел строку с lib/ , что заставляет git игнорировать эту папку. С этим нет проблем - по крайней мере, если эта папка не является основной папкой вашего проекта, как то, что случилось со мной.
Сначала это не сработало. Но я заставил его работать. В моем случае вещь, которую нужно игнорировать, дважды упоминалась в файле gitignore. Всегда ищите все вхождения и заменяйте все.
Как уже говорилось, файлы, вероятно, были помечены флажком "предположить-без изменений", который в основном сообщает git, что вы не будете изменять файлы, поэтому ему не нужно отслеживать изменения с их помощью. Однако это может повлиять на несколько файлов, и если это большое рабочее пространство, вы можете не захотеть проверять их все по одному. В этом случае вы можете попробовать: git update-index --really-refresh
По сути, это заставит git отслеживать изменения всех файлов, независимо от флагов «предполагать без изменений».
Для меня git status говорит, что файлы не меняются, но git add . добавляет два файла и git update-index --really-refresh говорит, что эти два нуждаются в обновлении, но, похоже, ничего не делает. Любая идея?
Звучит безумно, но иногда вы не в правильном репо, даже если думаете, что это так. Например, вы могли переместить родительский каталог, но забыли переключить репозиторий в текстовом редакторе. Или наоборот: вы находитесь в правильном репозитории в текстовом редакторе, но не в том репозитории в командной строке. В первой ситуации вы вносите изменения в правильный файл, но это не та папка, которая открыта в вашей командной строке, поэтому на самом деле это не тот файл. Во второй ситуации вы действительно отредактировали правильный файл, но git вашей командной строки не распознает изменение, потому что вы находитесь не в правильном каталоге в командной строке.
2) у вас были изменения и вы их зафиксировали, вы должны увидеть свою фиксацию в git log
3) у вас были какие-то git reset --hard изменения, ваши изменения могут быть там в журнале ссылок, введите, git reflog --all а затем проверьте или выберите ссылку, если вы когда-нибудь ее найдете.
4) вы проверяли одно и то же репо несколько раз и ошиблись.
1) тайник не найден 2) Я внес изменения и зафиксировал, могу ли я сделать коммит еще раз? 3) Я этого не делал 4) Я
если у вас были изменения и вы их зафиксировали, тогда вы можете перейти к следующему шагу, нажать или что бы там ни было . Вы можете зафиксировать еще раз, если у вас есть больше изменений, вы даже можете, git commit --amend что поместит ваши новые изменения в вашу последнюю фиксацию , не делайте этого, если вы уже поделились своим коммитом.
Произошла такая странная вещь. Плагин Eclipse Kepler git автоматически отмечал все мои папки проекта как игнорируемые в папке .gitignore.
Когда я заходил commit в Team меню, все они снова игнорировались. Насколько я могу судить, это произошло потому, что я установил их как производные в родительском проекте. Снятие отметки с них как dervied исправлено. Я никогда раньше не видел этого на Индиго. Надеюсь, это кому-то поможет.
TL; DR; Вы вообще находитесь в правильном репозитории?
Моя история немного забавна, но я подумал, что это может случиться с кем-то, у кого может быть похожий сценарий, поэтому поделитесь ею здесь.
На самом деле на моей машине, у меня было два отдельных GIT репозиториев repo1 и repo2 настроен в том же корневом каталоге с именем source . Эти два репозитория по сути являются репозиториями двух продуктов, над которыми я работаю в своей компании. Дело в том, что, как правило, структура каталогов исходного кода всех продуктов в моей компании одинакова.
О мастере филиала
ничего не фиксировать, рабочий каталог чист
в течение получаса. Затем мой коллега заметил это как независимую пару глаз и обратил на это мое внимание, что я был в неправильном, но очень похожем хранилище. В тот момент, когда я переключился на repo1 Git, я начал замечать измененные файлы.
Читайте также: