Не работает команда git add

Git happens! 6 типичных ошибок Git и как их исправить

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

Если вы только начинаете путь с Git, обучитесь основам работы с ним в командной строке. А здесь я расскажу о том, как можно исправить шесть наиболее распространённых ошибок в Git.

1. Упс… Я ошибся в сообщении к последнему коммиту

После нескольких часов кодинга легко допустить ошибку в сообщении коммита. К счастью, это легко исправить:

С этой командой откроется текстовый редактор и позволит внести изменения в сообщение к последнему коммиту. И никто не узнает, что вы написали «addded» с тремя «d».

2. Упс… Я забыл добавить файл к последнему коммиту

Другая популярная ошибка в Git — слишком поспешный коммит. Вы забыли добавить файл, забыли его сохранить или должны внести небольшое изменение, чтобы коммит стал осмысленным? Вашим другом снова будет —amend .

Добавьте недостающий файл и выполните эту верную команду:

Теперь вы можете либо откорректировать сообщение, либо просто сохранить его в прежнем виде (с добавленным файлом).

3. Упс… Я добавил файл, который не должен быть в этом репозитории

Но что, если у вас обратная ситуация? Что, если вы добавили файл, который не хотите коммитить? Обманчивый ENV-файл, директорию сборки или фото с котом, что было случайно сохранено в неправильном каталоге… Всё решаемо.

Если вы сделали только stage для файла и ещё не коммитнули его, всё делается через простой reset нужного файла (находящегося в stage):

Если же вы всё-таки коммитнули изменение, потребуется дополнительный предварительный шаг:

Коммит будет откачен, картинка удалена, а затем сделан новый коммит.

Прим. перев.: Как замечено в комментариях к оригинальной статье, эту проблему тоже можно решить с помощью уже упомянутого —amend . По всей видимости, данным пунктом автор хотел показать, какие ещё есть способы изменения истории коммитов для исправления ошибки.

4. Упс… Я коммитнул изменения в master

Итак, вы работаете над новой фичей и поспешили, забыв создать новую ветку для неё. Вы уже коммитнули кучу файлов и все эти коммиты оказались в master’е. К счастью, GitLab может предотвращать push’ы прямо в master. Поэтому мы можем откатить все нужные изменения в новую ветку следующими тремя командами:

Примечание: Убедитесь, что сначала коммитнули или stash‘нули свои изменения — иначе все они будут утеряны!

Будет создана новая ветка, в master’е — произведён откат до состояния, в котором он был до ваших изменений, а затем сделан checkout новой ветки со всеми вашими изменениями.

5. Упс… Я сделал ошибку в названии ветки

Самые внимательные могли заметить в предыдущем примере ошибку в названии ветки. Уже почти 15:00, а я всё ещё не обедал, поэтому мой голод назвал новую ветку (branch) как future-brunch. Вкуснотища!

Переименуем эту ветку аналогичным способом, что используется при переименовании файла с помощью команды mv, то есть поместив её в новое место с правильным названием:

Если вы уже push’нули эту ветку, понадобится пара дополнительных шагов. Мы удалим старую ветку из remote и push’нем новую:

Прим. перев.: Удалить ветку из remote ещё можно с помощью:

6. Oops… I did it again!

Последняя команда на тот случай, когда всё пошло не так. Когда вы накопировали и навставляли кучу решений со Stack Overflow, после чего в репозитории всё стало ещё хуже, чем было в начале. Все мы однажды сталкивались с подобным…

git reflog показывает список всех выполненных вами операций. Затем он позволяет использовать магические возможности Git’а по путешествию во времени, т.е. вернуться к любому моменту из прошлого. Должен отметить, что это ваша последняя надежда — не стоит прибегать к ней в простых случаях. Итак, чтобы получить список, выполните:

Каждый наш шаг находится под чутким наблюдением Git’а. Запуск команды на проекте выше выдал следующее:

Обратите внимание на самый левый столбец — это индекс. Если вы хотите вернуться к любому моменту в истории, выполните следующую команду, заменив на соответствующее значение (например, dfa27a2 ):

Итак, теперь у вас есть шесть способов выбраться из самых частых Gitfalls (игра слов: pitfall переводится как «ловушка, ошибка» — прим. перев.).

Бонус от переводчика

Во-первых, ценное замечание ко всему написанному выше (кроме пункта 5). Нужно учитывать, что эти действия меняют историю коммитов, поэтому их следует проводить, только если изменения не были отправлены в remote (push’нуты). В противном случае старый плохой коммит уже будет на remote-ветке и придётся либо выполнять git pull (который сделает merge, и тогда попытка «почистить» историю приведёт к худшим последствиям), либо git push —force , что чревато потерей данных при работе с веткой нескольких человек…

Теперь — небольшие полезные дополнения из нашего опыта:

• Если вы (случайно или нет) сменили ветку и вам нужно вернуться на предыдущую, самый быстрый способ — использовать git checkout — .
• Если вы случайно добавили к коммиту файл, который не должен быть туда добавлен, но ещё не сделали коммит — используйте git reset HEAD path/to/file . Похожая ситуация описана в пункте 3, но в действительности она шире, т.к. относится к любым ненужным изменениям в коммите (не только к случаю лишнего файла).
• Хорошей практикой, чтобы не закоммитить лишнего, является использование параметра -p при добавлении файла к коммиту ( git add -p ). Это позволяет сделать review каждого изменения, которое уйдёт в коммит. Но стоит помнить, что он не добавляет к коммиту untracked-файлы — их нужно добавлять без этого параметра.
• Ряд хороших рекомендаций (в том числе и более сложных), можно найти в статье 2014 года «Git Tutorial: 10 Common Git Problems and How to Fix Them». В частности, обратите внимание на использование git revert и git rebase -i .

Источник

Почему git не распознает, что мой файл был изменен, поэтому git add не работает

Я пытаюсь отправить свои файлы в github с помощью bash. Они уже там, и я загружаю более новую версию с новыми строками, кодом и т. Д. Но когда я пытаюсь, git add а потом появляется сообщение git status :

ничего не фиксировать, рабочий каталог чист

И файл, который я использую, был только что изменен.

У меня была проблема, когда однажды я установил для индекса git значение «считать неизменным» в моем файле.

Вы можете указать git, чтобы он перестал игнорировать изменения в файле:

Если это не поможет, сброса может быть достаточно для других странных случаев.

На практике я обнаружил, что удалил кешированный файл и заставил его работать:

В git rm —cached средстве для только удалить файл из индекса, и reset говорит мерзавец перезагрузить индекс GIT от последней фиксации.

Проверьте свой .gitignore файл . Вы можете обнаружить, что файл или расширение файла, или путь к файлу, с которым вы пытаетесь работать, совпадает с записью .gitignore , что объясняет, почему этот файл игнорируется (и не распознается как измененный файл).

Это случилось со мной, когда у меня была аналогичная проблема.

Как уже говорилось, файлы, вероятно, были помечены флажком «предположить-без изменений», который в основном сообщает git, что вы не будете изменять файлы, поэтому ему не нужно отслеживать изменения с их помощью. Однако это может повлиять на несколько файлов, и если это большое рабочее пространство, вы можете не захотеть проверять их все по одному. В этом случае вы можете попробовать: git update-index —really-refresh

По сути, это заставит git отслеживать изменения всех файлов, независимо от флагов «предполагать без изменений».

Звучит безумно, но иногда вы не в правильном репо, даже если думаете, что это так. Например, вы могли переместить родительский каталог, но забыли переключить репозиторий в текстовом редакторе. Или наоборот: вы находитесь в правильном репозитории в текстовом редакторе, но не в том репозитории в командной строке. В первой ситуации вы вносите изменения в правильный файл, но это не та папка, которая открыта в вашей командной строке, поэтому на самом деле это не тот файл. Во второй ситуации вы действительно отредактировали правильный файл, но git вашей командной строки не распознает изменение, потому что вы находитесь не в правильном каталоге в командной строке.

Что ж, у нас недостаточно ответов на этот вопрос, поэтому я дам вам несколько предположений:

1) вы сохранили свои изменения, чтобы исправить тип: git stash pop

2) у вас были изменения и вы их зафиксировали, вы должны увидеть свою фиксацию в git log

3) у вас были какие-то git reset —hard изменения, ваши изменения могут быть там в журнале ссылок, введите, git reflog —all а затем проверьте или выберите ссылку, если вы когда-нибудь ее найдете.

4) вы проверяли одно и то же репо несколько раз и ошиблись.

Произошла такая странная вещь. Плагин Eclipse Kepler git автоматически отмечал все мои папки проекта как игнорируемые в папке .gitignore.

Когда я заходил commit в Team меню, все они снова игнорировались. Насколько я могу судить, это произошло потому, что я установил их как производные в родительском проекте. Снятие отметки с них как dervied исправлено. Я никогда раньше не видел этого на Индиго. Надеюсь, это кому-то поможет.

TL; DR; Вы вообще находитесь в правильном репозитории?

Моя история немного забавна, но я подумал, что это может случиться с кем-то, у кого может быть похожий сценарий, поэтому поделитесь ею здесь.

На самом деле на моей машине, у меня было два отдельных GIT репозиториев repo1 и repo2 настроен в том же корневом каталоге с именем source . Эти два репозитория по сути являются репозиториями двух продуктов, над которыми я работаю в своей компании. Дело в том, что, как правило, структура каталогов исходного кода всех продуктов в моей компании одинакова.

Поэтому, не осознавая, я изменил файл с точно таким же именем, в repo2 котором я должен был изменить repo1 . Таким образом, я просто продолжал работать команду git status на repo1 и продолжал давать то же сообщение

ничего не фиксировать, рабочий каталог чист

в течение получаса. Затем мой коллега заметил это как независимую пару глаз и обратил на это мое внимание, что я был в неправильном, но очень похожем хранилище. В тот момент, когда я переключился на repo1 Git, я начал замечать измененные файлы.

Источник

не работает git add

Пытаюсь добавить проект в git, создала .gitignore
произвела следующие действия:
git init
git status
git add .
и вот git add . у меня не прошел
пишет
error: ‘site_tests/’ does not have a commit checked out
fatal: adding files failed

site_tests — это просто папка, где у меня складируются автотесты проекта
уже перепробовала все, что смогла и все никак
причем, добавляла обычный .txt файл и загружала только его, и все получалось, но как только пытаюсь загрузить все — ничего не выходит

буду очень благодарна за помощь в моей проблеме

2 ответа 2

У меня была подобная ситуация.

У меня папка в которой лежат куча файлов. И я хочу эту папку проиндексировать. Но вылетела ошибка: error: ‘JS/’ does not have a commit checked out fatal: adding files failed

1. В папке JS/ у меня была скрытая папка .git/ ( которая отвечает за структуру Git-репозитория ) . Она была лишней и я ее удалил. Отмечу, что у меня была папка .git на уровне проекта (в папке my_project), а папка .git в папке JS была лишней.
2. Затем согласно данной книги: Pro Git: Основы Git — Запись изменений в репозиторий . Сказано: «Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет все файлы из указанного каталога в индекс.».

То есть нужно для каталогов указывать путь: Для меня команда выглядела так: git add C:\Users\User\my_project\JS , и все корректно проиндексировалось.

Источник

Почему не выполняется команда git add. ?

Столкнулся с этим впервые, другой проект нормально залился в репозиторий.
Вот порядок действий:

Захожу в локальную папку проекта
cd

Инициализирую гит
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.

После чего выполняю коммит и он пишет:

В гите новичок. Гуглил, способы решения не подошли.

• Вопрос задан более трёх лет назад
• 22354 просмотра

Инициализируем новый репозиторий
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):

Но он не делает этого:

Или он изменяет это в слепках файлов проекта?

Связанно это с тем что переносы строк были в Unix-формате, так как дело происходило под Windows.
Простые решения:

Очень просто конвертировать переносы строк в Windows-формат помогает текстовый редактор Notepad++: Правка→EOL конверсия→Преобразовать в WIN-формат.
Подробнее.
Вручную преобразовать символы перевода строки из виндовых в линуксовые, открыть файл, еще раз визуально все проконтролировать и сохранить.
Быстро заменить CRLF на LF можно утилитой dos2unix, входящей в MINGW, с которым поставляется git для win32:

Источник