nothing to commit working tree clean что делать
Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Nothing to commit working tree clean
Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать “снимки” состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта (snapshot); они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged). Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что вы только взяли их из хранилища (checked them out) и ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения, а затем цикл повторяется. Этот жизненный цикл изображён на рисунке 2-1.
Рисунок 2-1. Жизненный цикл состояний файлов.
Определение состояния файлов
Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию; в этой главе это не важно. В следующей главе будет подробно рассказано про ветки и ссылки.
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в benchmarks.rb до фиксации. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Игнорирование файлов
Шаблон **/ доступен в Git, начиная с версии 1.8.2.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл benchmarks.rb и затем изменили его, вы можете использовать git diff для просмотра как индексированных изменений в этом файле, так и тех, что пока не проиндексированы:
Теперь вы можете используя git diff посмотреть непроиндексированные изменения
а также уже проиндексированные, используя git diff —cached :
Фиксация изменений
В редакторе будет отображён следующий текст (это пример окна Vim’а):
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и торчит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Обратите внимание на то, что в данном случае перед коммитом вам не нужно выполнять git add для файла benchmarks.rb.
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции “Changes not staged for commit” (“Изменённые но не обновлённые” — читай не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или glob-шаблоны. Это означает, что вы можете вытворять что-то вроде:
Эта команда удаляет все файлы, чьи имена заканчиваются на
Перемещение файлов
В отличие от многих других систем версионного контроля, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git’е, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git’е команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git’е, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Делал по инструкции настройку git, документация.
И когда уже хочу сделать коммит в IntelliJidea, он находит изменные файлы, но не хочет коммитить.
1 ответ 1
Так написано же серым по темно-серому: «nothing to commit, working directory clean»
Если видит, что ты что-то изменил то добавь это в измененные, а только потом комменть.
Всё ещё ищете ответ? Посмотрите другие вопросы с метками git intellij-idea git-commit или задайте свой вопрос.
Связанные
Похожие
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2019 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2019.11.15.35459
Добрый день, клонировал проект, создал ветку
Сделал в ней изменения, закомитил
Далее выполнил команду:
git push origin mybranch
В графике коммитов, все добавилось, ветка помечена как origin/mybranch
Но человек который делает слияния, говорит что моего коммита нет, и он его не видит, в чем может быть проблема, и что я делаю не так?
Копируйте команду которую вам предлагают и выполняйте.
После этих действий в вашей ветке на ориджин гарантированно будет ваш коммит с изменениями
Git: Игнорирование отслеживания файлов, которые уже есть в удаленном репозитории
Если внести файл в .gitignore, то он не будет отслеживаться гитом лишь в том случае, если этого файла нет в удаленном репозитории.
Update: Если конфиг изменили
Если всё же кто-то изменил структуру файла конфига, то git не даст сделать pull, т.к. все-равно будет считать, что файл конфига с нашими паролями отличается от того, что прийдет с командой pull.
Чтобы все-таки получить новые изменения, но и свои пароли сохранить в конфиге нужно сделать следующее:
1. Сохранить текущие конфиги (с нашими локальными паролями) в отдельную папку например.
3. На данном шаге команда git status покажет, что файл application/config/database.php был изменен, но еще не проиндексирован. Именно эти изменения и мешают нам забрать командой git pull новые изменения. Учитывая, что на шаге 1 мы сохранили наши конфиги в отдельную папку — мы можем сейчас отменить эти изменения.
git checkout application/config/database.php
4. Сейчас git status покажет, что изменений нет ( nothing to commit, working tree clean ). Забираем новые изменения:
git pull
5. Опционально: Если мы привыкли работать в отдельной ветке (не в master), то переходим в эту ветку (например: dev-branch) для последующей работы:
git checkout dev-branch
и вливаем в ветку dev-branch новые изменения из ветки master (куда мы их уже получили командой git pull ):
git merge master
6. Изменяем теперь наши обновленные конфиги, возвращая туда наши локальные пароли и все то, что мы желаем там видеть, но не хотим это хранить в репозитории (для этого мы сохранили все в шаге 1). После чего команда git status естественно покажет, что конфиги изменены, но не проиндексированы.
После чего git status покажет, что все чисто ( nothing to commit, working tree clean ) и мы сможем снова работать, делать коммиты и переключаться между ветками.
Рабочий процесс — Введение в Git
Перед тем как погружаться в детали, пройдём поверхностно весь путь от создания проекта в git до начала отслеживания изменений. Затем, в следующих уроках поговорим подробнее про все этапы. В процессе изучим большое количество новых терминов и команд, которые нужны для понимания работы git.
Команда git init создает репозиторий — директорию .git, которая содержит все необходимые для работы git файлы.
С помощью команды git status можно посмотреть статус репозитория:
В этом выводе указано, что репозиторий пустой (No commits yet) и в него нечего добавить, так как нет новых или изменённых файлов. Давайте попробуем добавить несколько файлов:
Теперь снова смотрим на статус:
Git увидел, что в проекте появились новые файлы, о которых ему ничего не известно. Они помечаются как неотслеживаемые (untracked files). Git не следит за изменениями в таких файлах, так как они не добавлены в репозиторий. Добавление в репозиторий происходит в два шага. Первым шагом выполняется команда подготовки файлов git add :
Смотрим что произошло:
Файл README.md теперь находится в состоянии «готов к фиксации изменений» или, другими словами, файлы попадают в индекс. Под фиксацией понимается окончательное добавление в репозиторий, когда git запоминает файл навсегда и следит за всеми последующими изменениями.
Все изменения, готовые к фиксации, попадают в репозиторий с помощью коммита. Коммит — это операция, которая берёт все подготовленные изменения (они могут включать любое количество файлов) и отправляет их в репозиторий как единое целое. Вот, как он выполняется:
Может возникнуть вопрос: зачем так сложно, зачем отдельно нужен индекс (куда попадают файлы после git add ), и почему нельзя добавлять все изменённые файлы сразу в коммит? Как ни странно, такой процесс создан как раз для удобства программистов. Дело в том, что во время разработки может меняться и добавляться много файлов. Но это не значит, что мы хотим добавить все эти изменения в один коммит.
Со смысловой точки зрения, коммит — это какое-то логически завершённое изменение внутри проекта. Его размер бывает очень маленьким, например, исправлением опечатки в одном файле, а иногда и большим, например, при внедрении новой функциональности. Главное в коммите — его атомарность, то есть он должен выполнять ровно одну задачу.
Узнайте, как отменять изменения в Git с помощью Bitbucket Cloud
Узнайте, как отменить изменения на локальной машине и в репозитории Bitbucket Cloud во время совместной работы с коллегами.
Краткое описание основной задачи
| Время | Аудитория | Обязательные условия | ||||||
|---|---|---|---|---|---|---|---|---|
| Команда | Определение | |||||
| Элемент | Описание | |||
| Фильтр | Описание | Пример команды | Результаты выполнения |
| — |