Добавить в корзинуПозвонить
Найти в Дзене
Y_LAB University

Новый пост Y_LAB Actual | Код под микроскопом

🔍 Продолжаем рубрику, в которой разбираем неочевидные ситуации из мира разработки и ищем подвох там, где его не всегда ожидаешь увидеть. Сегодня под микроскопом Git. И одна из ошибок, которую хотя бы раз совершал почти каждый разработчик 👇 bash git add . git commit -m "Fix bug" git push Вопрос: Что произойдёт, если выполнить эти команды, находясь в ветке main? Многие ответят: > Изменения попадут в удалённый репозиторий. И это действительно так. ❗️ Но есть нюанс: Git совершенно не проверяет, ту ли ветку вы собирались использовать. 🤔 Если вы забыли переключиться на feature-ветку и случайно остались в main, то изменения будут закоммичены и отправлены именно туда. Для Git это абсолютно корректное действие: bash git branch может показать: bash * main а дальше команды спокойно выполнятся без каких-либо предупреждений. ❔ Почему это важно Многие воспринимают Git как инструмент, который не позволит совершить ошибку. На самом деле Git отлично защищает историю проекта, но не мож

Новый пост Y_LAB Actual | Код под микроскопом 🔍

Продолжаем рубрику, в которой разбираем неочевидные ситуации из мира разработки и ищем подвох там, где его не всегда ожидаешь увидеть.

Сегодня под микроскопом Git. И одна из ошибок, которую хотя бы раз совершал почти каждый разработчик 👇

bash git add . git commit -m "Fix bug" git push

Вопрос:

Что произойдёт, если выполнить эти команды, находясь в ветке main?

Многие ответят:

> Изменения попадут в удалённый репозиторий.

И это действительно так.

❗️ Но есть нюанс: Git совершенно не проверяет, ту ли ветку вы собирались использовать.

🤔 Если вы забыли переключиться на feature-ветку и случайно остались в main, то изменения будут закоммичены и отправлены именно туда.

Для Git это абсолютно корректное действие:

bash git branch

может показать:

bash * main

а дальше команды спокойно выполнятся без каких-либо предупреждений.

❔ Почему это важно

Многие воспринимают Git как инструмент, который не позволит совершить ошибку.

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

💬 Что делать, если ошибка уже допущена

🎯 Если коммит уже сделан, но git push ещё не выполнялся

Исправить ситуацию достаточно просто: можно создать новую ветку от текущего состояния и перенести в неё коммит, а ветку main вернуть к предыдущему состоянию.

Так ошибка останется только локальной и не затронет остальных участников команды.

🎯 Если коммит уже отправлен (git push выполнен)

Здесь всё зависит от процесса в команде.

↔️ Если ветка общая и её используют другие разработчики, безопаснее всего сделать новый коммит, который отменит изменения (git revert), а затем перенести нужный код в отдельную рабочую ветку.

↔️ Если же история ещё никем не использовалась, иногда применяют переписывание истории (git reset + push --force), но делать это стоит только после согласования с командой, иначе можно испортить историю репозитория коллегам.

⌨️ Почему этот кейс встречается так часто?

Потому что ошибка выглядит не как ошибка.

Все команды выполняются успешно.

Никаких предупреждений.

Никаких конфликтов.

Именно поэтому многие замечают проблему только после того, как коллеги начинают писать: «А зачем это оказалось в main?»

А вам доводилось случайно коммитить или пушить не в ту ветку? 👀

#Y_LAB_University #Y_LAB_Actual