Git не видит изменений в файле

Обновлено: 02.07.2024

В предыдущем уроке по созданию репозитория Git мы научились создавать новый репозиторий git для проекта. Теперь, когда у нас есть проект Git, пришло время начать работать и с ним. Проект Git можно рассматривать как состоящий из трех частей:

Рабочий каталог: локальный репозиторий, где вы будете выполнять всю работу, такую как создание, редактирование, удаление и организация файлов проекта.
Промежуточная область: отслеживаемый локальный репозиторий, где вы будете перечислять изменения, внесенные в рабочий каталог.
Репозиторий: удаленный репозиторий, в котором Git постоянно хранит изменения в виде различных версий проекта.

Эта статья полностью посвящена работе с локальным репозиторием и отслеживаемыми / не отслеживаемыми изменениями. Мы будем охватывать следующие команды git:

Git add
Git status
Git remove

Прежде чем использовать вышеперечисленные команды, мы должны создать некоторые файлы в проекте репозитория git.

После этого репозиторий git будет выглядеть следующим образом:

Git Status

Git Status — это еще одна обязательная команда, которая возвращает информацию о текущем состоянии репозитория. Например, список измененных файлов, список отслеживаемых изменений на промежуточном этапе, неотслеживаемые изменения на локальном уровне и информация о текущей ветви и коммитах.

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

1) Теперь откройте командную строку и перейдите в репозиторий git

2) Просто введите git status в командной строке.

branch master: говорит о том, что рабочее дерево является главной ветвью.

no commits yet: дает информацию о коммитах, на данный момент их еще нет.

Untracked files: говорит о том, что Git видит файлы, но еще не начал отслеживать изменения и отметил их красным цветом.

Status messages: дает соответствующие инструкции для промежуточных / нестагнирующих файлов.

Git add

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

1) Давайте просто начнем с добавления одного файла к заявке. Чтобы использовать команду git add, просто введите git add filename. Слово filename здесь относится к имени файла, который вы редактировали, например CustomerData_IND.txt. Кроме того, используйте команду git status, чтобы увидеть, что git теперь может рассказать нам о состоянии репозитория.

Changes to be comitted: здесь отображается информация о отслеживаемых файлах, хранящихся на промежуточном этапе. Это тот самый, который мы добавили с помощью команды git add.

Untracked files: здесь отображается информация о неотслеживаемых файлах. Это те самые, которые добавили в проект раньше, но до сих пор не подтолкнули к постановке.

Команда Git Remove

Чтобы практиковать эту команду, давайте попробуем удалить тот же CustomerData_IND.txt, который был добавлен ранее.

Untracked files: CustomerData_IND.txt файл вернулся к списку игнорируемых изменения.

Добавление различных измененных файлов в промежуточную среду

Выше мы просто добавили один файл в staging. Что делать, если там будет несколько файлов для добавления. Это может быть легко достигнуто с помощью git add <file> <file>.

Чтобы добавить несколько файлов, введите

git add CustomerData_IND.txt CustomerData_UK.txt

Удаление различных файлов из промежуточного состояния

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

Чтобы удалить несколько файлов, введите

Вывод: упомянутые два файла в команде теперь удаляются из промежуточного состояния и возвращаются в неотслеживаемый список.

Добавим все измененные файлы в промежуточную версию

Выше мы добавили несколько файлов в staging, но что делать, если там будет много файлов для добавления? Это может быть легко достигнуто с помощью git add *.

Чтобы добавить все измененные файлы, введите git add *

Все измененные файлы теперь перемещаются в промежуточный режим.

Таким же образом все файлы могут быть удалены из промежуточного состояния и перемещены обратно в неотслеживаемый список.

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

"Клонирование" означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

О мастере филиала

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

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

Если вы уже совершили коммит, вам нечего будет коммитить, проверьте журнал git. Если git diff (или git status ) не показывает ничего, что объясняет, почему нечего добавить. Итак, вопрос действительно таков: «Почему git не распознает, что мой файл был изменен?»

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

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

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

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

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

git add -f path/to/the/file он принудительно добавит файлы для фиксации. Этот ответ был единственным, который помог решить мою проблему. Не уверен, что это связано с 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, я начал замечать измененные файлы.

Я скопировал некоторые файлы из другого каталога в рабочий каталог git. Обычно отображается под Untracked files . Однако они не появляются. Поэтому я не могу их добавить.

Когда я делаю git status , новые файлы не отображаются.

Я попытался добавить их, выполнив git add source.c , затем попробовал git status . Файл не был показан.

Итак, я открыл файл и ввел save as с тем же именем. git status все еще не смог увидеть файл.

Я сделал git ls-files , и новые файлы отображаются нормально.

Я проверил права доступа к файлам, и они такие же, как и все текущие файлы в моем каталоге git.

У меня никогда раньше не было такой проблемы.

Большое спасибо за любые предложения,

Если git ls-files показывает source.c , значит, он уже должен быть в индексе. Это означает, что он уже отслеживается и, возможно, уже зафиксирован. Если source.c вообще не отображается в git status , значит, файл был зафиксирован.

Кроме того, может выполняться одно или несколько из следующих утверждений:

Файл был изменен, но в индексе установлен бит «считать неизменным». Взгляните на вывод git ls-files -v source.c . Если первый столбец представляет собой строчную букву, то устанавливается бит «считать неизменным». Это предотвратит отображение любых изменений в git status . Вы можете отключить бит «считать неизменным», запустив git update-index --no-assume-unchanged source.c .
Файл был изменен, но в индексе установлен бит skip-worktree. Если первый столбец вывода git ls-files -v source.c равен s или S , то установлен бит 'skip-worktree'. Вы можете отключить бит 'skip-worktree', запустив git update-index --no-skip-worktree source.c .
Ваш индекс поврежден. Попробуйте удалить .git/index (при необходимости Git создаст его заново).
Проблемы с файловой системой мешают правильной работе stat() . Попробуйте запустить git update-index --really-refresh . Если ваш рабочий каталог находится на сетевом диске (NFS, sshfs и т. Д.), Попробуйте переместить репозиторий на локальный диск.

Возможно, стороннее приложение обновило ваш файл " gitignore_global.txt " (

/.gitignore_global в Linux / OS X). Со мной так и случилось. Я установил "Исходное дерево" и заметил, что после этого git не отслеживает новые файлы. Было обнаружено, что «Исходное дерево» изменило файл «gitignore_global.txt» и добавило несколько расширений, чтобы он не отслеживался. Попробуйте найти этот файл и посмотреть, нет ли там расширений файла, которые должны быть там.

Скорее всего, ваш файл .gitignore игнорирует его.

Позвоните git status --ignored и посмотрите, появится ли ваш файл.

Я создал пакет, заканчивающийся на image.gen, у которого был соответствующий каталог, заканчивающийся на image / gen. И была запись .gitignore, специфичная для Android gen /.

Это приводило к тому, что файл не добавлялся в git / отображался в статусе git.

Проверьте ниже, это помогло мне решить проблему.

Используйте команду git check-ignore для отладки файла gitignore (исключите файлы).

Приведенные выше выходные данные о совпадающем шаблоне (если есть) для каждого заданного имени пути (включая строку).

Так что, возможно, игнорируется не расширение вашего файла, а весь каталог.

Или используйте следующую команду для печати вашего .gitignore в папке пользователя и репозитория:

В качестве альтернативы используйте git add -f , который позволяет добавлять файлы, игнорируемые в противном случае.

См .: man gitignore , man git-check-ignore для получения более подробной информации.

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

У вас есть правило в .gitignore, которое игнорирует файлы
У вас есть каталог .git в одном из скопированных вами каталогов.

Из представленной информации трудно сказать, что не так, однако в качестве временного решения вы можете попробовать git add -f filename.c . Это добавит файл, даже если в противном случае он был бы проигнорирован.

git config --global status.showuntrackedfiles all - Решение для старого дела. Вы можете использовать git status untracked-files=all в терминале, но он длиннее, если установлен --global , код выше, ему потребуется только git status для файлов, появляющихся в неотслеживаемом месте.

Удаление файла .git / index помогло. Довольно неприятная ошибка, с которой я, кажется, сталкиваюсь, когда клонирую скелетные модули в свой проект zf2.

Android Repo - Та же проблема, с которой я столкнулся - Исправлено, как показано ниже

Как-то добавил "/app" in .gitignore file . Теперь после удаления "/app" все заработало.

Пожалуйста, проверьте свой .gitignore.

У меня такая же проблема. Git не показал никаких новых файлов, добавленных в мой проект.

Моя была вызвана следующим: каким-то образом основная папка моего проекта была добавлена в «список игнорирования для конкретного репозитория» (так он называется в SourceTree). Это файл «.gitignore» в корне основной папки моего проекта.

Я работаю над локальным филиалом, и я знаю, что файл, который мне придется внести, но изменил, был изменен другими разработчиками. Я хочу эти изменения, прежде чем сам начну менять файл. Я вижу, что файл был изменен, например, на веб-инструменте, который показывает наше репозиторий git. Я делал такие вещи, как git fetch remotes/origin/develop (это название ветки, на которую все разработчики нажимают), а затем git checkout changedFile.java. Я до сих пор не вижу последних изменений, когда я делаю журнал git или использую gitk, Что мне не хватает?

EDIT: Я считаю, что, если у вас есть локальный филиал, отличный от разработки, вы не можете обновить файл в этой ветке от удаленной разработки?

EDIT: git checkout origin/develop - путь /to/changedFile.java сделал, насколько я могу точно сказать, что хочу, и позвольте мне мотивировать это дальше: я работал над своим местным отделением и удаленным развитием (что не название локального ветки, над которым я работаю) отклонено. Я собираюсь изменить один из файлов, и этот файл изменился. Мне кажется, что я могу использовать версию файла без последующих изменений и позже слить, или получить изменения, и, возможно, упростить слияние. Так что проверка работала, и мой единственный вопрос: почему это когда-либо неправильно?

TL; DR

Если вы просто хотите просмотреть файл, используйте git show , например:

Если вы используете git checkout origin/develop -- changedFile.java , это будет извлекать его через ваш индекс в ваше дерево работы, но это часто не очень хорошая идея.

Что нужно знать о коммитах и индексе/промежуточной области

Гит - все о коммитах. Коммиты - это не файлы, хотя фиксации действительно содержат файлы. Точнее, каждая фиксация содержит полный моментальный снимок каждого файла в состоянии, которое оно имело в тот момент, когда вы (или кто бы то ни было) совершили коммит. (Даже это не совсем правильно.)

Чтобы совершать новые коммиты, Git предоставляет вам два места для работы с файлами. Один из них, называемый деревом, довольно очевиден. Файлы в вашем дереве имеют свою обычную форму, с которой ваш компьютер занимается все время. Они могут быть прочитаны, написаны, обновлены на месте, добавлены, что угодно. Другими словами, рабочее дерево - это то место, где вы выполняете свою работу.

По разным причинам Git позволяет иметь в вашем дереве файлы, которые не будут переданы. Это незатребованные файлы. Git ничего не делает с необработанными файлами, за исключением того, что постоянно жалуется, что они не отслеживаются. Чтобы закрыть его, вы можете перечислить определенные неподготовленные файлы в .gitignore , который не делает Git игнорировать их на самом деле, он просто закрывает их об их отсутствии и не делает их git add если вы используете массовое добавление все "операции. (Обратите внимание, что если файл уже отслеживается, его включение в .gitignore не влияет.)

Там другая копия каждого отслеживаемого файла. Эта дополнительная копия, называемая копией индекса или промежуточной области, на самом деле является тем, как Git знает, что это отслеживаемый файл. Эти копии всегда присутствуют, и на самом деле, когда вы делаете новую фиксацию, Git делает фиксацию из копий индекса, а не из копий рабочего дерева! Вот почему Git постоянно требует, чтобы вы git add вещи: команда git add означает "копировать из дерева работы в индекс". Это только делает это копирование в тот момент, когда вы говорите git add ; если вы снова измените файл, вам придется снова его скопировать.

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

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

Каждый фиксатор запоминает своего родителя; но поскольку коммиты неизменны, родители не помнят своих детей. Git поэтому должен (и делает) всегда работать назад. Название ветки, develop , хранит новейшую фиксацию, которую вы имеете при develop . Чтобы сделать новую фиксацию, просто добавьте ее в свою цепочку:

(поскольку внутренние стрелки всегда идут назад и никогда не меняются, мы можем в значительной степени прекратить рисовать их сейчас).

git show может показать что угодно

Запуск git show origin/develop:path/to/file.txt показывает содержимое path/to/file.txt в фиксации, указанной по origin/develop .

Теперь, когда вы знаете выше, здесь, как использовать его

Вы работаете над некоторым кодом. Возможно, вы совершили коммиты, а может и нет. У вас есть некоторые изменения в дереве. Кто-то другой сделал некоторые другие изменения, в каком-то другом репозитории, и совершил (сделав целые снимки) и нажал их фиксацию, чтобы он origin/develop .

Вы запустили git fetch origin который обновил ваше origin/develop чтобы записать новый коммит. Позвольте нарисовать, что:

То, что вы можете и должны сделать, это сделать свой собственный код сейчас. Позвольте нарисовать это тоже:

Теперь вы можете использовать git merge . То, что git merge делает, сочетает вашу работу с их работой и, по крайней мере, в этом случае, и пока Git сам думает, что слияние сработало - создайте новую фиксацию, которая сохраняет, как (в основном) постоянный и (полностью) неизменный моментальный снимок, результатом которого является объединение:

Или вместо этого вы можете использовать git rebase . То, что git rebase делает, это копирование, и после того, как оно закончило копирование их на новые и улучшенные коммиты, откажитесь от оригиналов. (Это означает, что нормальное постоянство коммитов отменяется.) Если вы скопируете фиксацию K в новый и улучшенный K' чей родительский J , мы можем сделать это следующим образом:

Объединять и переупаковывать и использовать машину слияния и объединять-как-глагол

Интересная вещь об этом процессе копирования заключается в том, что он использует один и тот же базовый код для объединения изменений файлов, которые использует git merge . Что другое - так называемое вычисление базы слияния, хотя для этого конкретного простого случая база слияния является фиксацией I в обоих случаях в любом случае.

Когда Git переходит на слияние вещей, он обнаруживает, какие файлы изменены с момента его слияния, и вычисляет "что вы сделали" (для этих файлов) и "что они сделали" (к тем же файлам).

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

Это действие, объединяющее два набора изменений с общей отправной точки (совместное принятие), является тем, что Git означает слияние при использовании в качестве глагола. Обратите внимание, что слияние также может использоваться в качестве прилагательного: фиксация слияния - это фиксация, которая записывает две родительские коммиты, такие как M в приведенном выше примере. Прилагательное даже становится существительным: это коммит является слиянием.

Объединение объединяет коммиты, а объединенные ветки - это только те ветки, даже если у них нет имен. Предположим, например, что вы считаете, что объединение слиянием M идеально. Он делает именно то, что вы хотите. Вы можете git push это на origin , после чего изображение становится:

В этом есть ветка, хотя нет имени ветки, указывающего на фиксацию J Commit M указывает на фиксацию J (у него есть два родителя, K и J ). В качестве слияния, M служит для связывания двух ветвей вместе.

Должны ли вы перебалансироваться или сливаться?

У этого вопроса нет единого правильного ответа. Rebasing делает вещи лучше в будущем, как будто вы даже не начинаете свои изменения до тех пор, пока не закончите их. После того как вы отказались от своего первоначального фиксации K в пользу пересмотренного/улучшенного K' , мы можем повернуть этот чертеж:

Затем мы можем отбросить символ маленькой отметки ("премьер") и надавить на фиксацию так, чтобы origin/develop теперь включал вашу фиксацию:

и история выглядит так просто, по сравнению с версией слияния. Но это не настоящая история, это пересмотренная/очищенная история. Это хорошо (легко работать) и плохо (если пересмотр чего-то переделал).

Что делать, если вы еще не закончили?

Если вы еще не закончили свои изменения, перезагрузка дает вам возможность закончить их позже. Или, вы можете просто не слиться. Пока вы не git push -ed фиксацию, вы можете использовать git commit --amend чтобы, по-видимому, изменить текущий/новейший на месте. Вы просто работаете, как обычно, git add свои файлы, а затем запустите git commit --amend вместо git commit . Git берет вашу текущую фиксацию и "отталкивает ее в сторону", делая вашу новую фиксацию, как ее родитель, совершает фиксацию перед вашей текущей фиксацией. Если K является вашей текущей фиксацией, мы можем сделать это как:

Вы можете повторять это столько раз, сколько хотите; каждый из них выкидывает другую фиксацию и вставляет новую в конец:

Обратите внимание, что вы можете сделать это с помощью коммитов, которые вы еще не git merge -ed (если K родительский I , потому что вы не git rebase либо). Если вы запустили git merge , git commit --amend не принесет вам никакой пользы, потому что новая фиксация будет вашей фиксацией слияния.

(Если вы объединились, но не нажали, вы можете "переустановить" слияние.Когда скопируйте копии, они явно пропускают комманды слияния. Однако в некоторых случаях это немного или даже много сложно.)

Будущее чтение

Обратите внимание, что Git предлагает интерактивный режим переустановки. Используя интерактивную переадресацию, вы можете повторно организовать и объединить фиксации, если они не были нажаты (не опубликованы). Это означает, что вы можете безопасно совершать моментальные снимки в процессе выполнения, даже небольшие изменения, для какой-либо конкретной цели. Позже, когда они действительно готовы, вы можете использовать интерактивную rebase, чтобы объединить их все в одну большую фиксацию или несколько небольших, но автономных коммитов. Вы можете сделать так, чтобы вы знали, что делали все это время, даже если вам пришлось попробовать кучу вещей и отменить некоторые из них.

Читайте также: