{"draftJsState":{"blocks":[{"data":{},"depth":0,"entityRanges":[{"key":0,"length":1,"offset":15},{"key":1,"length":38,"offset":16}],"inlineStyleRanges":[],"text":"Вопросы здесь \uD83D\uDC49 10 вопросов по GIT (вопросы 501 - 510)","type":"header-three","key":"2be48"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 501. В чем заключается ключевое различие между командами git fetch и git pull, и какая из них считается более \"безопасной\" для использования в командной работе?","type":"header-three","key":"17g25"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: B","type":"unstyled","key":"aqro1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"33uov"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Хотя обе команды используются для синхронизации с удаленным репозиторием, они работают по-разному. Понимание этой разницы критически важно для предсказуемой и безопасной работы с Git.","type":"unstyled","key":"7c2sh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":11,"offset":161,"style":"BOLD"}],"text":"git fetch: Эта команда подключается к удаленному репозиторию и загружает все новые данные (коммиты, ветки, теги), которых у вас еще нет. Важно то, что git fetch не изменяет вашу локальную рабочую ветку. Она только обновляет ваши удаленно-отслеживаемые ветки (например, origin/main). Это позволяет вам сначала просмотреть изменения, прежде чем решать, как их интегрировать.","type":"unordered-list-item","key":"fu8v3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":25,"offset":202,"style":"BOLD"}],"text":"git pull: Эта команда по сути является комбинацией двух других команд: git fetch, за которой следует git merge (или git rebase в зависимости от конфигурации). Она не только загружает новые данные, но и немедленно пытается слить их с вашей текущей локальной веткой. Это может привести к автоматическому созданию коммита слияния или к возникновению конфликтов.","type":"unordered-list-item","key":"f2ei6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"c8to"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Неверно. Определения перепутаны.","type":"unordered-list-item","key":"4pge3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Верно. Это наиболее точное описание разницы.","type":"unordered-list-item","key":"9jr1r"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Команды не являются синонимами; git pull выполняет дополнительное действие (слияние).","type":"unordered-list-item","key":"a1ene"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Для отправки изменений используется git push.","type":"unordered-list-item","key":"6mbhu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":32,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Безопасность: git fetch считается более \"безопасной\" командой, потому что она не вносит автоматических изменений в вашу локальную рабочую ветку. Вы получаете возможность проанализировать изменения (git log main..origin/main) перед тем, как вручную их слить (git merge origin/main).","type":"unordered-list-item","key":"ffqmu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":35,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Рабочий процесс: git pull — это удобный шорткат, но он может скрыть от вас детали слияния. Использование git fetch + git merge дает больше контроля над процессом.","type":"unordered-list-item","key":"g7q9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"2gsv7"},{"data":{"image":{"id":"687cb1244c9cc30092fdb0a5"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"tfo4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ B является правильным, так как git fetch загружает изменения из удаленного репозитория, но не применяет их к локальной рабочей ветке, в то время как git pull загружает изменения и немедленно пытается их слить (merge) с текущей веткой, что делает git fetch более \"безопасной\" операцией.","type":"unstyled","key":"3fg80"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 502. Вы только что сделали коммит, но сразу поняли, что забыли добавить в него один важный файл. Какую последовательность команд следует использовать, чтобы добавить этот файл в самый последний коммит, не создавая при этом нового коммита в истории?","type":"header-three","key":"dptc1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"8aihs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"838vt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для модификации самого последнего коммита в Git предназначена команда git commit с флагом --amend. Это позволяет \"дополнить\" или \"исправить\" предыдущий коммит, добавив в него новые изменения или изменив его сообщение.","type":"unstyled","key":"2ldgm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":18,"offset":0,"style":"BOLD"},{"length":49,"offset":220,"style":"BOLD"}],"text":"git commit --amend: Эта команда берет все изменения, которые находятся в \"staging area\" (проиндексированные изменения), и объединяет их с изменениями из последнего коммита. Фактически, она не \"изменяет\" старый коммит, а создает новый коммит, который заменяет предыдущий.","type":"unordered-list-item","key":"fhgau"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":14,"offset":0,"style":"BOLD"}],"text":"Флаг --no-edit: Этот полезный флаг позволяет выполнить amend без открытия редактора для изменения сообщения коммита. Сообщение останется таким же, как и у \"исправляемого\" коммита.","type":"unordered-list-item","key":"ccma0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"f0ik"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. Это стандартный и наиболее прямой способ решить поставленную задачу.","type":"unordered-list-item","key":"31qp7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"},{"length":5,"offset":54,"style":"ITALIC"}],"text":"B. Неверно. git revert не изменяет историю, а создает новый коммит, который является \"анти-коммитом\" и отменяет изменения указанного коммита. Это не подходит для исправления ошибки в последнем коммите.","type":"unordered-list-item","key":"2ouk0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Команды git update для этой цели не существует, это вымышленный вариант.","type":"unordered-list-item","key":"81gb7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Этот подход излишне сложен и приведет к созданию лишних коммитов слияния, засоряя историю.","type":"unordered-list-item","key":"57et7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":38,"offset":0,"style":"BOLD"},{"length":22,"offset":85,"style":"ITALIC"}],"text":"Ключевой аспект 1: Перезапись истории: git commit --amend является командой, которая перезаписывает историю. Это означает, что хеш замененного коммита изменится. Поэтому её следует использовать только для локальных коммитов, которые еще не были отправлены (push) в общий репозиторий.","type":"unordered-list-item","key":"eiisu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":32,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Staging Area: Перед вызовом git commit --amend необходимо добавить нужные изменения в staging area с помощью git add. Команда amend работает именно с этими проиндексированными изменениями.","type":"unordered-list-item","key":"f5p44"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"9n6aj"},{"data":{"image":{"id":"687cb124519d1865a2783189"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"fp7hf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как сначала нужно добавить забытый файл командой git add , а затем выполнить git commit --amend --no-edit, чтобы обновить последний коммит, не создавая нового.","type":"unstyled","key":"aq177"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 503. Какую роль играет \"staging area\" (или \"index\") в рабочем процессе Git, и каково его основное предназначение?","type":"header-three","key":"2khae"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: B","type":"unstyled","key":"63ohn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"buj6l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Staging area (также известная как \"index\" или \"область подготовленных файлов\") — это одна из трех фундаментальных \"зон\" в Git, наряду с рабочим каталогом (Working Directory) и репозиторием (Repository). Её основное предназначение — служить \"черновиком\" для вашего следующего коммита.","type":"unstyled","key":"9s14k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"},{"length":16,"offset":54,"style":"BOLD"},{"length":12,"offset":159,"style":"BOLD"},{"length":12,"offset":233,"style":"BOLD"},{"length":11,"offset":283,"style":"BOLD"}],"text":"Рабочий процесс:\nВы вносите изменения в файлы в своем рабочем каталоге.\nС помощью команды git add вы добавляете нужные изменения из рабочего каталога в staging area.\nС помощью команды git commit вы берете все, что находится в staging area, и сохраняете это как новый коммит в репозитории.","type":"unordered-list-item","key":"fhfq9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":15,"offset":0,"style":"BOLD"}],"text":"Предназначение: Главная польза staging area заключается в том, что она дает вам полный контроль над тем, что войдет в следующий коммит. Вы можете изменить 10 файлов, но добавить в staging area только 3 из них, которые относятся к одной логической задаче, и сделать коммит только с ними. Это позволяет создавать атомарные, логически завершенные коммиты и поддерживать историю проекта чистой и понятной.","type":"unordered-list-item","key":"1ebk6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"35jeh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"},{"length":6,"offset":144,"style":"ITALIC"}],"text":"A. Неверно. Для временного сохранения незавершенных изменений используется команда git stash. Staging area предназначена для изменений, которые готовы к коммиту.","type":"unordered-list-item","key":"dmdqn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Верно. Это наиболее точное описание роли и предназначения staging area.","type":"unordered-list-item","key":"aad40"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Конфликты слияния отображаются и разрешаются непосредственно в рабочем каталоге, а не в какой-то специальной ветке или области.","type":"unordered-list-item","key":"ecrcb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"},{"length":10,"offset":108,"style":"ITALIC"}],"text":"D. Неверно. Полную историю хранит сам репозиторий (в папке .git), а staging area содержит лишь \"снимок\" для следующего коммита.","type":"unordered-list-item","key":"d6365"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":28,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Контроль: Staging area позволяет отделить готовые к коммиту изменения от тех, которые еще находятся в процессе разработки.","type":"unordered-list-item","key":"9tsn5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":37,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Атомарные коммиты: Благодаря этой области можно группировать связанные изменения в один коммит, даже если одновременно в работе находятся и другие, не связанные с ними правки.","type":"unordered-list-item","key":"cd4ff"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"8qvkj"},{"data":{"image":{"id":"687cb1242745f95d4a4b416c"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"etfgd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ B является правильным, так как \"staging area\" - это промежуточная область, куда разработчик помещает готовые изменения (git add), чтобы сформировать из них следующий коммит, позволяя включать в коммит только часть изменений из рабочего каталога.","type":"unstyled","key":"a4g81"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 504. В чем заключается принципиальное различие в результате применения команд git merge и git rebase для интеграции изменений из одной ветки в другую, и какой из подходов создает более линейную историю коммитов?","type":"header-three","key":"84qen"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"cn775"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"6vd5k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"И git merge, и git rebase решают одну и ту же задачу — интеграцию изменений из одной ветки в другую, — но делают это совершенно разными способами, что приводит к разному виду истории коммитов.","type":"unstyled","key":"375fh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":21,"offset":0,"style":"BOLD"},{"length":32,"offset":155,"style":"BOLD"},{"length":10,"offset":231,"style":"BOLD"}],"text":"git merge (Слияние):\nЭта команда берет все коммиты из указанной ветки и объединяет их с текущей веткой.\nРезультатом является создание нового, специального \"коммита слияния\" (merge commit), у которого есть два родительских коммита.\nРезультат: История коммитов сохраняется в точности так, как она происходила, со всеми параллельными ветвлениями. Это честный, но иногда \"шумный\" способ, так как в истории появляется много коммитов слияния.","type":"unordered-list-item","key":"3tpeq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":30,"offset":0,"style":"BOLD"},{"length":12,"offset":85,"style":"BOLD"},{"length":10,"offset":153,"style":"BOLD"},{"length":8,"offset":192,"style":"BOLD"},{"length":22,"offset":348,"style":"BOLD"}],"text":"git rebase (Перебазирование):\nЭта команда берет все коммиты из вашей текущей ветки и \"перемещает\" их, применяя по одному поверх указанной целевой ветки.\nРезультат: История коммитов становится линейной, как будто все изменения делались последовательно, одно за другим. Это делает историю более чистой и легкой для чтения. Важно понимать, что rebase перезаписывает историю, создавая новые коммиты с новыми хешами для каждого из перенесенных коммитов.","type":"unordered-list-item","key":"290q2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"80tkl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. Это наиболее точное и полное описание разницы между двумя подходами.","type":"unordered-list-item","key":"defbi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Неверно. Определения перепутаны местами.","type":"unordered-list-item","key":"cpiqt"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Обе команды работают с изменениями в коде на уровне коммитов, а не с конкретными типами файлов.","type":"unordered-list-item","key":"958f3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Это утверждение является полной противоположностью правды. git rebase часто сложнее в разрешении конфликтов (так как они могут возникать на каждом переносимом коммите) и считается \"опасной\" операцией для общих веток из-за перезаписи истории.","type":"unordered-list-item","key":"4ta3g"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":38,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Линейность истории: git rebase создает чистую и линейную историю, в то время как git merge сохраняет нелинейную историю с явными точками слияния.","type":"unordered-list-item","key":"dmfuq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":42,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Золотое правило Rebase: Никогда не используйте git rebase для веток, на которые ссылаются другие разработчики (например, main, develop). Перезапись истории в общей ветке создаст хаос для всей команды. rebase безопасно использовать только для ваших локальных, еще не опубликованных веток.","type":"unordered-list-item","key":"1id79"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"b1t74"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Допустим, у нас есть ветка main и ветка feature:","type":"unstyled","key":"ff05m"},{"data":{"image":{"id":"687cb1247116a31c68b634af"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"ajba9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":42,"offset":0,"style":"BOLD"}],"text":"После git merge feature (находясь в main):","type":"unstyled","key":"9pajp"},{"data":{"image":{"id":"687cb124cda633575159a361"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"btmob"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":36,"offset":0,"style":"ITALIC"}],"text":"История сохранена, но она нелинейна.","type":"unstyled","key":"fskjb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":43,"offset":0,"style":"BOLD"}],"text":"После git rebase main (находясь в feature):","type":"unstyled","key":"e66ih"},{"data":{"image":{"id":"687cb1243493b64abab19799"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"9gutv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":87,"offset":0,"style":"ITALIC"}],"text":"Коммиты A, B, C были пересозданы (A', B', C') и применены поверх main. История линейна.","type":"unstyled","key":"6rge8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как git merge создает специальный \"коммит слияния\", который объединяет истории двух веток, сохраняя их параллельное развитие, а git rebase переносит коммиты из одной ветки в начало другой, создавая линейную историю.","type":"unstyled","key":"e4p2s"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 505. Вы работаете над задачей в своей ветке, и у вас есть несколько измененных, но еще не готовых к коммиту файлов. Внезапно вас просят срочно исправить критический баг в ветке main. Какой из следующих подходов является наиболее правильным и стандартным для временного сохранения вашей текущей работы, переключения на другую ветку и последующего возвращения к своим изменениям?","type":"header-three","key":"b96r8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"12cuq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"2vflf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Для решения именно такой задачи в Git существует специальный механизм — git stash (в переводе \"спрятать\" или \"заначка\"). Он позволяет временно сохранить все изменения в отслеживаемых файлах, которые еще не были закоммичены, возвращая ваш рабочий каталог в \"чистое\" состояние (соответствующее последнему коммиту HEAD).","type":"unstyled","key":"2bg00"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":9,"offset":0,"style":"BOLD"}],"text":"git stash: Эта команда берет ваши измененные отслеживаемые файлы и незавершенные проиндексированные изменения и сохраняет их в специальном стеке. После этого ваш рабочий каталог становится чистым.","type":"unordered-list-item","key":"7vtia"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":13,"offset":0,"style":"BOLD"}],"text":"git stash pop: После того как вы закончили срочную работу и вернулись в свою ветку, эта команда берет последние сохраненные изменения из стека stash и применяет их к вашему рабочему каталогу, одновременно удаляя их из стека.","type":"unordered-list-item","key":"3usqi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"3e3us"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. Это стандартный, безопасный и наиболее эффективный способ решения данной проблемы, для которого и был создан git stash.","type":"unordered-list-item","key":"cdaj5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Неверно. Хотя этот подход технически возможен, он считается плохой практикой. Он создает \"грязные\", неполноценные коммиты в истории, которые потом приходится удалять, что усложняет историю проекта.","type":"unordered-list-item","key":"dlsv2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"},{"length":50,"offset":84,"style":"BOLD"}],"text":"C. Неверно. Этот вариант очень опасен. Флаг -f (или --force) при переключении веток отбросит все ваши локальные изменения безвозвратно. Они не будут сохранены.","type":"unordered-list-item","key":"dhiud"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Это \"ручной\" и крайне неэффективный способ, который полностью игнорирует встроенные возможности Git. Он подвержен ошибкам (можно забыть скопировать файл) и не является версионируемым.","type":"unordered-list-item","key":"dklcd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":42,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Чистый рабочий каталог: Git не позволяет переключаться между ветками, если у вас есть незакоммиченные изменения, которые могут конфликтовать с веткой назначения. git stash решает эту проблему, временно \"очищая\" ваш каталог.","type":"unordered-list-item","key":"fsom7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":34,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Стек изменений: git stash может хранить несколько наборов изменений в виде стека. Вы можете просмотреть их с помощью git stash list и применить не только последний, но и любой другой.","type":"unordered-list-item","key":"3365u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"3lan1"},{"data":{"image":{"id":"687cb1263493b64abab19803"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"3c0oa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как использование команды git stash позволяет временно сохранить все отслеживаемые измененные файлы, переключиться на ветку main, а после исправления бага вернуться в свою ветку и применить изменения командой git stash pop.","type":"unstyled","key":"8ng6h"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 506. Вы отправили важный коммит в общий удаленный репозиторий (git push), но позже обнаружили в нем ошибку. Какой командой следует \"отменить\" изменения этого коммита, сохранив при этом историю безопасной и понятной для всей команды?","type":"header-three","key":"f65qu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"ipue"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"2oo13"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Когда \"плохой\" коммит уже попал в общий репозиторий, перезапись истории (которую делают git reset и git commit --amend) становится очень опасной, так как это может привести к серьезным проблемам у других членов команды, которые уже могли получить этот коммит. Для безопасной отмены изменений в таких случаях предназначена команда git revert.","type":"unstyled","key":"eu9rp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":0,"style":"BOLD"},{"length":12,"offset":141,"style":"BOLD"}],"text":"git revert : Эта команда не удаляет и не изменяет существующую историю. Вместо этого она анализирует указанный коммит и создает новый коммит, который является его точной противоположностью. Если старый коммит добавлял строку, revert-коммит ее удалит. Если удалял — добавит обратно.","type":"unordered-list-item","key":"d26lk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":28,"offset":0,"style":"BOLD"}],"text":"Безопасность и прозрачность: Так как revert просто добавляет новый коммит, история проекта остается целостной и понятной. Все видят, что был сделан ошибочный коммит, а затем был сделан коммит, который его исправляет.","type":"unordered-list-item","key":"90lnb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"60gfa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. git revert — это стандартный и безопасный способ отмены изменений в общих ветках.","type":"unordered-list-item","key":"43nbb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"},{"length":23,"offset":16,"style":"BOLD"}],"text":"B. Неверно. Это крайне опасная практика для общих веток. git reset --hard и git push --force переписывают историю, что может сломать репозитории у ваших коллег и привести к потере данных.","type":"unordered-list-item","key":"7af04"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. git commit --amend также переписывает историю и применим только к самому последнему коммиту. Использовать его для уже опубликованных коммитов так же опасно, как и reset.","type":"unordered-list-item","key":"dbv4r"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Команды git delete commit не существует в Git. Это вымышленный вариант.","type":"unordered-list-item","key":"dcrn8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":61,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Сохранение истории vs. Перезапись истории: git revert добавляет новые коммиты (сохраняет историю), в то время как git reset и git commit --amend удаляют или изменяют существующие (перезаписывают историю).","type":"unordered-list-item","key":"95phs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":51,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Публичная vs. Локальная история: Правило гласит: безопасно перезаписывать только ту историю, которая еще не была опубликована (не была отправлена через push). Для опубликованной истории следует использовать git revert.","type":"unordered-list-item","key":"6qc79"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"8khak"},{"data":{"image":{"id":"687cb1268c5df052272dcd87"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"crnjk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как команда git revert создает новый коммит, отменяющий изменения указанного коммита, и при этом не изменяет существующую историю, что является безопасным для общих репозиториев.","type":"unstyled","key":"djggp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 507. Для чего предназначена команда git cherry-pick и в каком сценарии ее использование будет наиболее оправданным?","type":"header-three","key":"35s4g"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"bhbtq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"1b2gj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":14,"offset":215,"style":"BOLD"}],"text":"Команда git cherry-pick (в переводе \"срывать вишенку\") — это мощный инструмент, который позволяет точечно применять изменения из конкретных коммитов. Она берет указанный коммит из любой ветки и применяет его в виде нового коммита поверх текущей ветки, в которой вы находитесь.","type":"unstyled","key":"b6l24"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":0,"style":"BOLD"}],"text":"Основное предназначение: Вместо того чтобы сливать целую ветку со всеми ее коммитами, cherry-pick позволяет вам выбрать только те \"вишенки\" (коммиты), которые вам нужны.","type":"unordered-list-item","key":"2a5ar"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":40,"offset":0,"style":"BOLD"},{"length":35,"offset":303,"style":"BOLD"}],"text":"Типичный сценарий использования:\nHotfix: Разработчик находит и исправляет баг в своей feature-ветке. Этот фикс нужен в основной ветке main немедленно, но вся остальная feature-ветка еще не готова к слиянию. С помощью git cherry-pick можно взять только коммит с исправлением бага и применить его к main.\nПеренос небольшой функциональности: В одной ветке была реализована полезная утилитарная функция. Другой ветке нужна эта же функция, но не все остальные изменения из первой ветки. Коммит с этой функцией можно \"перенести\" с помощью cherry-pick.","type":"unordered-list-item","key":"4cl4v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"b59hn"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. Это точное описание работы и основного предназначения команды.","type":"unordered-list-item","key":"e5768"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Неверно. Это описание команды git rebase.","type":"unordered-list-item","key":"3n05s"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. cherry-pick не создает коммитов слияния; он создает обычный, новый коммит, который является копией выбранного.","type":"unordered-list-item","key":"c5vl0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Для сравнения коммита с рабочим каталогом используется команда git diff .","type":"unordered-list-item","key":"b5jps"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":39,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Точечное применение: В отличие от merge или rebase, которые работают с целыми ветками, cherry-pick работает с отдельными коммитами.","type":"unordered-list-item","key":"330s2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":43,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Создание нового коммита: Важно понимать, что cherry-pick не \"перемещает\" коммит, а создает его копию. У нового коммита будет новый хеш, но тот же автор, дата и сообщение (если не указано иное).","type":"unordered-list-item","key":"c1c2q"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"39t83"},{"data":{"image":{"id":"687cb1264a82000e6ffa2653"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"2j32d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как git cherry-pick применяет один или несколько выбранных коммитов из одной ветки в другую, что особенно полезно для переноса конкретных исправлений (hotfix) без необходимости слияния всей ветки.","type":"unstyled","key":"82p35"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 508. Вы случайно выполнили команду git reset --hard и потеряли несколько последних локальных коммитов, которые еще не были отправлены в удаленный репозиторий. Существует ли в Git механизм для восстановления этих \"потерянных\" коммитов, и если да, то какая команда для этого используется?","type":"header-three","key":"fk9me"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: B","type":"unstyled","key":"3lg0o"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"7570v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Хотя команда git reset --hard кажется очень опасной, Git спроектирован так, чтобы данные не терялись легко. Большинство действий, изменяющих историю (такие как reset, rebase, amend), на самом деле не удаляют коммиты немедленно. Git хранит \"журнал\" всех состояний, на которые указывал HEAD, и этот журнал можно просмотреть с помощью команды git reflog.","type":"unstyled","key":"265pi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":28,"offset":0,"style":"BOLD"}],"text":"git reflog (Reference Log):\nЭта команда выводит лог всех изменений ссылок в локальном репозитории (например, HEAD, имена веток). Каждая запись в reflog показывает, куда указывала ссылка в определенный момент времени.\nЭто локальный механизм, он не синхронизируется с удаленным репозиторием и предназначен для \"спасения\" от локальных ошибок. Записи в reflog хранятся ограниченное время (по умолчанию 90 дней).","type":"unordered-list-item","key":"3jmq4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":0,"style":"BOLD"},{"length":2,"offset":163,"style":"ITALIC"}],"text":"Процесс восстановления:\nВыполнить git reflog, чтобы увидеть список всех недавних действий и состояний HEAD.\nНайти в этом списке хеш коммита, который был последним до выполнения git reset --hard.\nВосстановить это состояние, создав новую ветку от этого коммита (git checkout -b recovered-branch ) или сбросив текущую ветку к нему (git reset --hard ).","type":"unordered-list-item","key":"7iqio"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"c4101"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Неверно. Хотя reset --hard опасен, он не является абсолютно необратимым благодаря reflog.","type":"unordered-list-item","key":"47s0b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Верно. Это стандартный и правильный способ восстановления потерянных локальных коммитов.","type":"unordered-list-item","key":"9085u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Команды git restore --lost-commits не существует, это вымышленный вариант.","type":"unordered-list-item","key":"28dln"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. Клонирование репозитория не поможет восстановить коммиты, которых никогда не было на удаленном сервере.","type":"unordered-list-item","key":"7q39"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":33,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Журнал ссылок: git reflog — это ваша \"страховочная сетка\" при выполнении опасных операций, изменяющих локальную историю.","type":"unordered-list-item","key":"5mdua"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":40,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Доступность коммитов: Коммит в Git не удаляется до тех пор, пока на него не перестанут указывать какие-либо ссылки (включая ссылки из reflog) и пока не сработает сборщик мусора Git (git gc).","type":"unordered-list-item","key":"7vfng"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"c1utl"},{"data":{"image":{"id":"687cb127519d1865a27834c3"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"3jcab"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ B является правильным, так как можно использовать git reflog, чтобы найти хеши \"потерянных\" коммитов и восстановить их, создав новую ветку от нужного коммита.","type":"unstyled","key":"a8ols"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 509. Что представляет собой команда git bisect, и какой основной алгоритм лежит в её основе для эффективного поиска коммита, который внес ошибку в код?","type":"header-three","key":"e9lss"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: A","type":"unstyled","key":"4umf2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"eo5su"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":26,"offset":200,"style":"BOLD"}],"text":"git bisect — это чрезвычайно мощный инструмент для отладки, который помогает быстро найти коммит, который внёс ошибку в проект. Его основное преимущество — скорость, достигаемая за счет использования алгоритма бинарного поиска.","type":"unstyled","key":"97ska"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":18,"offset":0,"style":"BOLD"},{"length":6,"offset":702,"style":"ITALIC"}],"text":"Как это работает:\nВы запускаете процесс командой git bisect start.\nВы указываете \"плохой\" коммит, где ошибка уже точно есть (обычно это HEAD или последний известный коммит с ошибкой) — git bisect bad .\nВы указываете \"хороший\" коммит, где ошибки еще точно не было (например, хеш старого коммита или тег версии) — git bisect good .\nGit автоматически переключается на коммит, находящийся посередине между \"хорошим\" и \"плохим\".\nВы проверяете код на наличие ошибки в этом коммите и сообщаете Git результат: git bisect good (если ошибки нет) или git bisect bad (если ошибка есть).\nGit сужает диапазон поиска в два раза и повторяет шаг 4.\nПроцесс продолжается до тех пор, пока не будет найден первый коммит, который был помечен как \"плохой\".\nВы завершаете сессию командой git bisect reset.","type":"unordered-list-item","key":"2ok56"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"aak8a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Верно. Это точное описание механизма работы git bisect и его основы — бинарного поиска.","type":"unordered-list-item","key":"idpj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Неверно. Это описание линейного поиска, который был бы гораздо медленнее. git bisect использует более эффективный бинарный поиск.","type":"unordered-list-item","key":"8itfa"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. Это описание команды git blame, которая используется для другого вида анализа.","type":"unordered-list-item","key":"93qh8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. git bisect не создает новые ветки для тестирования, а временно переключает HEAD на существующие коммиты. Это вымышленный сценарий.","type":"unordered-list-item","key":"d9jbv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":34,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Бинарный поиск: Вместо того чтобы проверять сотни коммитов по одному, git bisect позволяет найти нужный коммит за логарифмическое время. Например, для 1024 коммитов потребуется всего около 10 проверок.","type":"unordered-list-item","key":"eb2st"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":33,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Автоматизация: Весь процесс можно автоматизировать, передав команде git bisect run скрипт, который будет сам проверять наличие бага и возвращать код выхода (0 для \"good\", 1 для \"bad\").","type":"unordered-list-item","key":"5nu80"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"fp0mu"},{"data":{"image":{"id":"687cb127ff15683da770885d"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"bqie4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ A является правильным, так как git bisect - это инструмент, который автоматически выполняет бинарный поиск по истории коммитов, чтобы найти первый коммит, внесший ошибку, сужая диапазон поиска путем пометки коммитов как «хорошие» (good) и «плохие» (bad).","type":"unstyled","key":"bkti9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вопрос 510. Как файл .gitignore влияет на файлы, которые уже отслеживаются системой контроля версий Git, и какая последовательность действий необходима, чтобы заставить Git перестать отслеживать такой файл, не удаляя его из локальной файловой системы?","type":"header-three","key":"dppt1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":19,"offset":0,"style":"BOLD"}],"text":"Правильный ответ: B","type":"unstyled","key":"2anls"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Объяснение:","type":"unstyled","key":"499s7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":41,"offset":155,"style":"BOLD"},{"length":9,"offset":204,"style":"BOLD"}],"text":"Это один из самых частых \"подводных камней\" при работе с .gitignore. Ключевой принцип заключается в том, что .gitignore указывает Git, какие файлы и папки игнорировать при добавлении в репозиторий, но он не влияет на файлы, которые уже отслеживаются.","type":"unstyled","key":"o2hu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":0,"style":"BOLD"},{"length":15,"offset":52,"style":"ITALIC"}],"text":"Как работает .gitignore: Он предотвращает попадание неотслеживаемых (untracked) файлов в staging area при использовании таких команд, как git add ..","type":"unordered-list-item","key":"7fr7k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":44,"offset":0,"style":"BOLD"}],"text":"Что происходит с уже отслеживаемыми файлами: Если файл был когда-то добавлен (git add) и закоммичен, Git будет продолжать отслеживать изменения в нем, даже если вы позже добавите его в .gitignore.","type":"unordered-list-item","key":"cbhn7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Решение проблемы: Чтобы заставить Git \"забыть\" про файл, но оставить его в вашем рабочем каталоге, необходимо:\nУдалить файл из индекса (staging area) Git. Для этого используется команда git rm --cached . Флаг --cached критически важен, так как он предотвращает удаление файла из вашей файловой системы.\nДобавить имя файла в .gitignore (если это еще не сделано).\nЗакоммитить эти изменения (.gitignore и удаление из индекса).","type":"unordered-list-item","key":"dltn6"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":17,"offset":0,"style":"BOLD"}],"text":"Разбор вариантов:","type":"unstyled","key":"7ndve"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"A. Неверно. Это самое распространенное заблуждение. Git не перестанет отслеживать файл автоматически.","type":"unordered-list-item","key":"dtvc0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"B. Верно. Это полный и правильный порядок действий для решения задачи.","type":"unordered-list-item","key":"2nnot"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"C. Неверно. .gitignore прекрасно работает как для файлов, так и для папок.","type":"unordered-list-item","key":"55kr3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":0,"style":"BOLD"}],"text":"D. Неверно. git reset уберет файл из индекса, но не остановит его отслеживание. При следующем git add . (если файл не в .gitignore) он снова будет добавлен. git rm --cached — это правильная команда для полного прекращения отслеживания.","type":"unordered-list-item","key":"e39lr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":47,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 1: Область действия .gitignore: Влияет только на неотслеживаемые файлы.","type":"unordered-list-item","key":"e04f0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":43,"offset":0,"style":"BOLD"}],"text":"Ключевой аспект 2: Команда git rm --cached: Это стандартный способ убрать файл из-под контроля версий, сохранив его локально.","type":"unordered-list-item","key":"e4dp7"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":0,"style":"BOLD"}],"text":"Пример:","type":"unstyled","key":"bappj"},{"data":{"image":{"id":"687cb1276f92306e0a910868"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"6tleu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Таким образом, ответ B является правильным, так как .gitignore не влияет на уже отслеживаемые файлы, и чтобы перестать отслеживать файл, нужно сначала удалить его из индекса Git с помощью git rm --cached , а затем закоммитить это изменение.","type":"unstyled","key":"8032o"},{"data":{},"depth":0,"entityRanges":[{"key":2,"length":6,"offset":17}],"inlineStyleRanges":[],"text":"Блок вопросов на github","type":"unstyled","key":"4mg11"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Подпишись, чтобы не пропустить","type":"unstyled","key":"boru2"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Удачи!","type":"unstyled","key":"53kl9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"marker","key":"tcjdB67Kf8ZmnVu0HKHd"}],"entityMap":{"0":{"data":{"badSeoLink":"true","url":"https://dzen.ru/a/aHywf5nfswk5igda"},"mutability":"MUTABLE","type":"LINK"},"1":{"data":{"badSeoLink":"true","url":"https://dzen.ru/a/aHywf5nfswk5igda"},"mutability":"MUTABLE","type":"LINK"},"2":{"data":{"url":"https://pikabu.ru/story/10_voprosov_po_git_voprosyi_501__510_otvetyi_12980816?u=https%3A%2F%2Fgithub.com%2Fhypo69%2F1001-python-ru%2Ftree%2Fmaster%2Finterview-kit-ru%2F1%2520-%2520500%2Fchapter-5%2Fgit&t=github&h=85036bc14ff698607e5b856bc654703350608f54"},"mutability":"MUTABLE","type":"LINK"}}},"mentions":[]}