[TASK] STASH (https://github.com/SENATOROVAI/intro-cs/issues/3) #350
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Comment on lines
+1
to
+79
| # 1. Что делает команда git stash? | ||
| # | ||
| # Сохраняет незакоммиченные изменения (modified и staged файлы) во временное хранилище, возвращая рабочую директорию к состоянию последнего коммита. | ||
| # | ||
| # 2. Как просмотреть список всех сохранённых изменений (стэшей)? | ||
| # | ||
| # git stash list | ||
| # | ||
| # 3. Какая команда применяется для использования верхнего стэша? | ||
| # | ||
| # git stash pop | ||
| # | ||
| # 4. Как применить конкретный стэш по его номеру? | ||
| # | ||
| # git stash apply stash@{n} | ||
| # | ||
| # где n - номер стэша (например, stash@{2}) | ||
| # | ||
| # 5. Чем отличается команда git stash apply от git stash pop? | ||
| # | ||
| # apply - применяет стэш, но сохраняет его в списке | ||
| # | ||
| # pop - применяет стэш и удаляет его из списка | ||
| # | ||
| # 6. Что делает команда git stash drop? | ||
| # | ||
| # Удаляет указанный стэш из списка. Без аргументов удаляет последний стэш | ||
| # | ||
| # 7. Как полностью очистить все сохранённые стэши? | ||
| # | ||
| # git stash clear | ||
| # | ||
| # 8. В каких случаях удобно использовать git stash? | ||
| # | ||
| # Когда нужно временно отложить текущие изменения для работы с другой веткой | ||
| # | ||
| # При смене контекста работы без коммита незавершённых изменений | ||
| # | ||
| # Перед выполнением операций, требующих чистого рабочего состояния | ||
| # | ||
| # 9. Что произойдёт, если выполнить git stash pop, но в проекте есть конфликтующие изменения? | ||
| # | ||
| # Git попытается применить изменения и создаст конфликт слияния, который нужно разрешить вручную. Стэш останется в списке до успешного применения. | ||
| # | ||
| # 10. Можно ли восстановить удалённый стэш после выполнения git stash drop? | ||
| # | ||
| # Да, если не прошло слишком много времени. Удалённые стэши временно хранятся в reflog: | ||
| # | ||
| # git reflog show refs/stash | ||
| # | ||
| # 11. Что делает команда git stash save "NAME_STASH" | ||
| # | ||
| # Создаёт стэш с указанным именем (удобно для идентификации) | ||
| # | ||
| # 12. Что делает команда git stash apply "NUMBER_STASH" | ||
| # | ||
| # Применяет конкретный стэш по его номеру, не удаляя его из списка | ||
| # | ||
| # 13. Что делает команда git stash pop "NUMBER_STASH" | ||
| # | ||
| # Применяет конкретный стэш по его номеру и удаляет его из списка | ||
| # | ||
| # 14. Сохраните текущие изменения в стэш под названием "SENATOROV ver1", вставьте скриншот из терминала | ||
| # | ||
| #  | ||
| # | ||
| # 15. Внесите любые изменения в ваш репозиторий и сохраните второй стэш под именем "SENATOROV ver2" | ||
| # | ||
| #  | ||
| # | ||
| # 16. Восстановите ваш стэш "SENATOROV ver1", вставьте скриншот из терминала | ||
| # | ||
| #  | ||
| # | ||
| # 17. Удалите все стеши из истории, вставьте скриншот из терминала | ||
| # | ||
| #  | ||
|
|
||
| # |
There was a problem hiding this comment.
Please do a review
Comment on lines
+1
to
+260
| # Общие вопросы | ||
| # | ||
| # 1.Что такое Issues на GitHub и для чего они используются? | ||
| # | ||
| # Issues (проблемы или задачи) — это встроенный в GitHub инструмент для отслеживания работы над проектом. Они используются для: | ||
| # | ||
| # Сообщения о багах (баг-репорты). | ||
| # | ||
| # Предложений новых функций (feature requests). | ||
| # | ||
| # Обсуждения идей и планов развития проекта. | ||
| # | ||
| # Постановки задач для участников команды. | ||
| # | ||
| # Ведения списка дел (to-do list). | ||
| # | ||
| # 2.Чем Issues отличаются от других инструментов управления задачами? | ||
| # | ||
| # Интеграция с кодом: Issues тесно связаны с репозиторием (коммитами, пул-реквестами). Можно закрывать issue через коммиты. | ||
| # | ||
| # Простота и легкость: Менее сложные, чем Jira, но более мощные, чем простые списки задач. | ||
| # | ||
| # Цена: Бесплатно для публичных и приватных репозиториев в рамках GitHub. | ||
| # | ||
| # Экосистема: Являются частью единой платформы (код, задачи, документация, CI/CD в одном месте). | ||
| # | ||
| # 3.Какие основные компоненты (поля) есть у каждого Issue? | ||
| # | ||
| # Title (Заголовок): Краткое описание сути issue. | ||
| # | ||
| # Description (Описание): Подробное описание проблемы или задачи (можно использовать Markdown). | ||
| # | ||
| # Assignee (Исполнитель): Пользователь, ответственный за выполнение задачи. | ||
| # | ||
| # Labels (Метки): Теги для категоризации (например, bug, enhancement, documentation). | ||
| # | ||
| # Projects (Проекты): Связь с проектами GitHub (канбан-доски). | ||
| # | ||
| # Milestone (Веха): Группировка issue для достижения конкретной цели к определенному сроку. | ||
| # | ||
| # Comments (Комментарии): Обсуждение задачи. | ||
| # | ||
| # Status: Открыто (Open) или Закрыто (Closed). | ||
| # | ||
| # Создание Issues | ||
| # | ||
| # 4.Как создать новое Issue в репозитории? | ||
| # | ||
| # Перейдите на вкладку "Issues" в вашем репозитории на GitHub. | ||
| # | ||
| # Нажмите зеленую кнопку "New issue". | ||
| # | ||
| # Если в репозитории настроены шаблоны, выберите подходящий (например, "Bug Report" или "Feature Request"). | ||
| # | ||
| # Заполните заголовок и описание. | ||
| # | ||
| # Назначьте необходимые метки, исполнителей, веху (опционально). | ||
| # | ||
| # Нажмите "Submit new issue". | ||
| # | ||
| # 5.Какие данные рекомендуется указывать в описании Issue для лучшего понимания задачи? | ||
| # | ||
| # Это зависит от типа задачи, но универсальные рекомендации: | ||
| # | ||
| # Для бага (Bug): | ||
| # | ||
| # Четкий заголовок: "Ошибка при нажатии кнопки 'Сохранить' в форме профиля". | ||
| # | ||
| # Шаги воспроизведения: Пошаговая инструкция, как получить ошибку (1. Откройте... 2. Нажмите...). | ||
| # | ||
| # Ожидаемый результат: Что должно было произойти. | ||
| # | ||
| # Фактический результат: Что произошло на самом деле (текст ошибки, скриншоты). | ||
| # | ||
| # Окружение: ОС, браузер, версия приложения и т.д. | ||
| # | ||
| # Для новой функции (Feature Request): | ||
| # | ||
| # Проблема: Какую проблему пользователя решит эта функция. | ||
| # | ||
| # Предложение: Подробное описание желаемого решения. | ||
| # | ||
| # Альтернативы: Рассмотренные альтернативные варианты. | ||
| # | ||
| # 6.Какие теги (labels) можно добавить к Issue? Какие из них стандартные? | ||
| # | ||
| # Можно создать любые метки на усмотрение команды. Стандартные (предустановленные) метки GitHub: | ||
| # | ||
| # bug – указывает на неожиданную проблему или ошибку. | ||
| # | ||
| # documentation – требуется улучшение или добавление документации. | ||
| # | ||
| # duplicate – проблема уже существует. | ||
| # | ||
| # enhancement – предложение новой функции или улучшения. | ||
| # | ||
| # good first issue – подходит для новичков в проекте. | ||
| # | ||
| # help wanted – команда приветствует помощь в решении этой задачи. | ||
| # | ||
| # invalid – проблема неактуальна или некорректна. | ||
| # | ||
| # question – требуется дополнительная информация. | ||
| # | ||
| # wontfix – проблема не будет исправлена. | ||
| # | ||
| # 7.Как прикрепить Assignees (ответственных) к Issue? | ||
| # | ||
| # В правой колонке интерфейса создания/редактирования Issue есть секция "Assignees". Нажмите на нее и выберите из списка участников репозитория. Можно назначить несколько человек. | ||
| # | ||
| # Работа с Issues | ||
| # | ||
| # 8.Как использовать Labels для классификации задач? | ||
| # | ||
| # Метки — это главный инструмент категоризации. Их можно использовать для: | ||
| # | ||
| # Типа задачи: bug, feature, docs, question. | ||
| # | ||
| # Приоритета: high priority, low priority. | ||
| # | ||
| # Статуса: in progress, blocked, needs review. | ||
| # | ||
| # Области/компонента: frontend, backend, database, UI. | ||
| # Комбинируя метки, можно легко фильтровать задачи (например, показать все high priority bugs в frontend). | ||
| # | ||
| # 9.Для чего нужен Milestone, и как связать его с Issue? | ||
| # | ||
| # Milestone (Веха) – это инструмент для группировки Issues и Pull Requests вокруг общей цели (например, "Релиз v2.0") с дедлайном. | ||
| # Как связать: В правой колонке Issue выберите "Milestone" и назначьте существующую веху или создайте новую. | ||
| # | ||
| # 10.Как привязать Issue к пул-реквесту (Pull Request)? | ||
| # | ||
| # Вручную: В описании или комментарии PR укажите #номер_issue (например, Closes #45). GitHub автоматически создаст ссылку. | ||
| # | ||
| # Автоматически: Если PR сливается в ветку по умолчанию, использование в его описании ключевых слов (fixes #45, resolves #21) автоматически закроет привязанную issue. | ||
| # | ||
| # 11.Как добавить комментарий к существующему Issue? | ||
| # | ||
| # Внизу любого открытого Issue есть текстовое поле. Напишите свой комментарий и нажмите "Comment". Можно использовать Markdown, упоминать пользователей (@username) и ссылаться на другие Issues/PR. | ||
| # | ||
| # Закрытие и завершение Issues | ||
| # | ||
| # 12.Как закрыть Issue вручную? | ||
| # | ||
| # Нажмите кнопку "Close issue" внизу страницы Issue или в интерфейсе списка Issues. | ||
| # | ||
| # 13.Можно ли автоматически закрыть Issue с помощью сообщения в коммите или пул-реквесте? Как это сделать? | ||
| # | ||
| # Да, это стандартная практика. Достаточно в описании коммита или Pull Request использовать одно из ключевых слов: | ||
| # | ||
| # close / closes / closed | ||
| # | ||
| # fix / fixes / fixed | ||
| # | ||
| # resolve / resolves / resolved | ||
| # Например: git commit -m "Fix user login validation. Fixes #15". Когда PR будет смержен, Issue #15 автоматически закроется. | ||
| # | ||
| # 14.Как повторно открыть закрытое Issue, если работа ещё не завершена? | ||
| # | ||
| # Перейдите на страницу закрытого Issue. Кнопка "Close issue" сменится на "Reopen issue". Нажмите на нее. | ||
| # | ||
| # Фильтрация и поиск | ||
| # | ||
| # 15.Как найти все открытые или закрытые Issues в репозитории? | ||
| # | ||
| # Перейдите на вкладку "Issues" и используйте фильтры: | ||
| # | ||
| # is:open – показать открытые. | ||
| # | ||
| # is:closed – показать закрытые. | ||
| # | ||
| # 16.Как использовать фильтры для поиска Issues по меткам, исполнителям или другим критериям? | ||
| # | ||
| # Используйте поисковые квалификаторы в строке поиска на вкладке Issues: | ||
| # | ||
| # label:bug – все Issues с меткой "bug". | ||
| # | ||
| # assignee:username – все Issues, назначенные на пользователя username. | ||
| # | ||
| # author:username – все Issues, созданные пользователем username. | ||
| # | ||
| # milestone:"v1.0" – все Issues в вехе "v1.0". | ||
| # Можно комбинировать: is:open label:bug assignee:ivanov. | ||
| # | ||
| # 17.Как сортировать Issues по приоритету, дате создания или другим параметрам? | ||
| # | ||
| # Над списком Issues есть выпадающее меню "Sort". Доступные варианты: Newest, Oldest, Most commented, Least commented, Recently updated, Least recently updated. Приоритет обычно задается метками (priority:high), а не стандартной сортировкой. | ||
| # | ||
| # Интеграции и автоматизация | ||
| # | ||
| # 18.Как настроить автоматические уведомления о новых или изменённых Issues? | ||
| # | ||
| # По умолчанию вы будете получать уведомления (через email или веб-интерфейс) о Issues, которые вы создали, назначены на вас или в которых вы упомянуты (@username). | ||
| # | ||
| # Чтобы следить за всем репозиторием, нажмите кнопку "Watch" вверху страницы репозитория и выберите нужный уровень уведомлений. | ||
| # | ||
| # 19.Что такое Projects в контексте GitHub, и как связать их с Issues? | ||
| # | ||
| # Projects – это адаптивные канбан-доски для управления работой (Issues и PR). Они помогают визуализировать workflow (например, колонки "To Do", "In Progress", "Done"). | ||
| # Как связать: В правой колонке Issue есть секция "Projects". Выберите проект и добавьте Issue в нужную колонку. | ||
| # | ||
| # 20.Какие сторонние инструменты можно использовать для автоматизации работы с Issues (например, боты, Webhooks)? | ||
| # | ||
| # GitHub Actions: Позволяют создавать сложные workflows (например, автоматически назначать метку needs-triage на новое Issue). | ||
| # | ||
| # Вебхуки (Webhooks): Для интеграции со внешними системами (Slack, Jira, Discord) для отправки уведомлений. | ||
| # | ||
| # Боты: Например, @dependabot для обновлений зависимостей, @stale для закрытия неактивных Issues. | ||
| # | ||
| # Коллаборация | ||
| # | ||
| # 21.Как упомянуть другого пользователя в комментарии к Issue? | ||
| # | ||
| # Используйте символ @ и начните вводить username пользователя. GitHub предложит список для автодополнения. Упомянутый пользователь получит уведомление. | ||
| # | ||
| # 22.Как запросить дополнительные данные или уточнения у автора Issue? | ||
| # | ||
| # Напишите комментарий с прямым вопросом, упомянув автора (@author_username). Можно попросить предоставить логи, скриншоты или уточнить шаги воспроизведения. | ||
| # | ||
| # 23.Что делать, если Issue неактуально или его нужно объединить с другим? | ||
| # | ||
| # Неактуально: Закройте Issue и добавьте метку wontfix или invalid. Обязательно напишите комментарий с объяснением причины. | ||
| # | ||
| # Объединение (Duplicate): Закройте Issue, добавьте метку duplicate и в комментарии укажите ссылку на основную Issue, которую оно дублирует (например, Duplicate of #123). GitHub автоматически покажет ссылку. | ||
| # | ||
| # Практические аспекты | ||
| # | ||
| # 24.Как использовать шаблоны для создания Issues? | ||
| # | ||
| # Шаблоны хранятся в корне репозитория в папке .github/ISSUE_TEMPLATE/. Каждый шаблон – это .md файл. При создании нового Issue пользователь сможет выбрать подходящий шаблон, который заполнит описание нужными полями. | ||
| # | ||
| # 25.Что такое Linked Issues, и как создать связь между задачами? | ||
| # | ||
| # Связанные Issues – это задачи, которые имеют логическую связь (блокируют друг друга, являются частью более крупной задачи). Связь создается вручную в правой колонке Issue (секция "Developers" -> "Link issues"). Это более формальная связь, чем просто упоминание #номер. | ||
| # | ||
| # 26.Какие метрики (например, время выполнения) можно отслеживать с помощью Issues? | ||
| # | ||
| # Прямо в GitHub метрики ограничены. Но с помощью вех и доски Projects можно отслеживать: | ||
| # | ||
| # Количество открытых/закрытых Issues в вехе. | ||
| # | ||
| # Общий прогресс. | ||
| # | ||
| # Для более серьезной аналитики (среднее время закрытия, время отклика) используют сторонние сервисы, которые подключаются через API (например, ZenHub, LinearB). | ||
| # | ||
| # 27.Какие best practices рекомендуются при работе с Issues в команде? | ||
| # | ||
| # Ведите дискуссию в комментариях, а не в сторонних чатах. | ||
| # | ||
| # Держите Issues актуальными: обновляйте статус, назначайте исполнителей, закрывайте выполненные задачи. | ||
| # | ||
| # Используйте метки и вехи для организации. | ||
| # | ||
| # Описывайте задачи максимально полно для снижения количества уточняющих вопросов. | ||
| # | ||
| # Закрывайте Issues только тогда, когда работа действительно завершена и проверена. | ||
| # | ||
| # Используйте автоматизацию (ключевые слова в коммитах, Actions) для уменьшения рутины. | ||
|
|
||
| # |
There was a problem hiding this comment.
please do a review
Comment on lines
+1
to
+50
| # 1.Что делает команда python -m venv venv? | ||
| # Создает виртуальное окружение | ||
| # | ||
| # 1.1 Что делает каждая команда в списке ниже? | ||
| # - pip list: выводит список зависимостей | ||
| # - pip freeze > requirements.txt: выгружает зависимости из виртуального окружения в файл# - pip install -r requirements.txt: в виртуальное окружение ставит зависимости из файла | ||
| # | ||
| # 2.Что делает каждая команда в списке ниже? | ||
| # - conda env list: выводит список виртуальных окружений | ||
| # - conda create -n env_name python=3.5: создаем новое виртуальное окружение на версии python 3.5 | ||
| # - conda env update -n env_name -f file.yml: обновляет зависимости в виртуальном окружении | ||
| # - source activate env_name: активация виртуального окружения | ||
| # - source deactivate: деактивация виртуального окружения | ||
| # - conda clean -a: очистить кэш conda | ||
| # | ||
| # | ||
| # | ||
| # 5. Что делают эти команды? | ||
| # - pip freeze > requirements.txt: выгружает зависимости из виртуального окружения в файл | ||
| # - conda env export > environment.yml: выгружает зависимости из виртуального окружения в файл | ||
| # | ||
| # | ||
| # 6. Что делают эти команды? | ||
| # - pip install -r requirements.txt | ||
| # - conda env create -f environment.yml | ||
| # В виртуальное окружение ставят зависимости из файла | ||
| # | ||
| # 7.Что делают эти команды? | ||
| # - pip list показывает список зависимостей | ||
| # - pip show информация о зависимости | ||
| # - conda list показывает список зависимостей | ||
| # | ||
| # 8.Где по умолчанию больше пакетов venv/pip или conda? и почему дата сайнинисты используют conda? | ||
| # При создании чистого окружения conda имеет больше пакетов. Но по ходу разработки проекта на venv/pip можно поставить множество пакетов, когда как conda использует собственный репозиторий пакетов для установки, который по количеству меньше. | ||
| # DS спецы как раз используют conda, потому что есть по дефолту множество нужных пакетов. | ||
| # | ||
| # 9. вставьте скрин где будет видно, Выбор интерпретатора Python (conda) в VS Code/cursor | ||
| # <img src="https://clck.ru/3NQBqJ"><br> | ||
| # | ||
| # 10. добавьте в .gitignore папку SENATOROV | ||
| # | ||
| # Добавил: **/SENATOROV/ | ||
| # | ||
| # 11. Зачем нужно виртуально окружение? | ||
| # В рамках проекта используются определенные пакеты с определенными версиями. Эту информацию можно хранить в файле, благодаря виртуальному окружению. А дальше с помощью файла можно на другом устройстве запустить проект, установив быстро все нужные пакеты, благодаря файлу. | ||
| # | ||
| # 12. С этого момента надо работать в виртуальном окружении conda, ты научился(-ась) выгружать зависимости и работать с окружением? | ||
| # | ||
| # 13. Удалите папку VENV, она больше не нужна, мы же не разрабы, нам нужна только conda | ||
| # удалил |
There was a problem hiding this comment.
Please do a review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes https://github.com/SENATOROVAI/intro-cs/issues/3