Инструменты профессионала и решение проблем

До сих пор мы рассматривали идеальный сценарий: вы пишете код, делаете коммиты, создаете Pull Request. Но в реальной жизни часто что-то идет не так: вы можете допустить ошибку в коде, сделать коммит с неверным сообщением или просто понять, что пошли не в том направлении. В этой лекции мы разберем, как решать самые распространенные проблемы.

1. Rollback — отмена изменений до коммита

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

Используйте функцию Rollback:

1. Откройте вкладку Commit.
2. Найдите в списке измененный файл, который вы хотите "откатить".
3. Щелкните по нему правой кнопкой мыши и выберите Rollback.

IDE предупредит вас, что изменения будут утеряны. Согласитесь, и файл мгновенно вернется к своей последней сохраненной в Git версии. Это самый простой и безопасный способ отменить локальные изменения.

2. Reset — удаление локальных коммитов

Сценарий: вы сделали один или несколько коммитов, но еще не делали push. Вы поняли, что эти коммиты ошибочны, и хотите их полностью удалить, как будто их и не было.

Используйте функцию Reset:

1. Откройте вкладку Git -> Log, чтобы увидеть историю коммитов.
2. Найдите последний "хороший" коммит, на котором вы хотите оказаться (тот, что был до ошибочных).
3. Щелкните по нему правой кнопкой мыши и выберите Reset Current Branch to Here....

В открывшемся окне вам предложат выбрать режим сброса. Самый радикальный — Hard.

Внимание! Режим Hard безвозвратно удаляет все коммиты после выбранного, а также все изменения в коде, которые были в этих коммитах. Используйте его с большой осторожностью и только для тех коммитов, которые еще никто не видел (те, которые не были отправлены на GitHub).

3. Что делать после Push?

Сценарий: вы сделали push, и только потом заметили в нем ошибку.

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

Правильное и безопасное решение:

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

4. Заглянуть в прошлое: продвинутая работа с логом

Мы уже знакомы с вкладкой Git -> Log, но это не просто список коммитов, а мощный инструмент для расследований.

• Хеш коммита (Commit Hash): вы наверняка заметили в логе строку из букв и цифр, например a1b2c3d. Этот хеш — уникальный, он позволяет точно ссылаться на любую точку в истории проекта. Вам редко придется использовать его вручную, но важно знать, что это и есть уникальный идентификатор каждого "снимка" вашего кода.
• Вы можете фильтровать историю по ветке, автору, дате или даже по слову в сообщении коммита. Это помогает быстро найти, кто и когда работал над определенной частью функционала.
• Хотите найти коммит, в котором была добавлена или удалена конкретная строка кода? В окне Log есть поле для поиска, которое ищет не только по сообщениям, но и по содержимому самих изменений.
• Щелкните правой кнопкой мыши на полях редактора кода и выберите Annotate with Git Blame. IDE покажет напротив каждой строки, кто и в каком коммите ее последний раз менял. Это невероятно полезно для понимания, почему код написан именно так.

5. Опасная зона: Force Push

Итак, мы установили, что изменять отправленные коммиты — плохая идея. Но что, если вы все-таки изменили свою локальную историю (например, с помощью Reset) и теперь она расходится с историей на сервере? При попытке сделать обычный push Git выдаст ошибку, защищая общую историю от перезаписи.

Для таких случаев существует опция — force push (принудительная отправка). Эта команда говорит серверу: "Забудь все, что у тебя было. Моя локальная версия истории — единственно верная. Замени свою историю моей".

ВНИМАНИЕ! В 99% случаев использование force push в командных проектах — это катастрофа. Это может безвозвратно удалить коммиты, которые ваши коллеги уже скачали и на основе которых они работают. Это равносильно тому, чтобы вырвать страницы из общей библиотечной книги и вклеить свои.

Когда категорически НЕЛЬЗЯ использовать force push:

• На любые общие ветки: main, develop, master. Никогда.
• На любую ветку, с которой работает кто-то еще кроме вас.

Единственный допустимый сценарий:

Вы работаете в своей личной feature-ветке, которую еще никто не видел и не использовал. Вы сделали несколько "грязных" коммитов, отправили их на сервер, а потом решили их "причесать" с помощью Reset. В этом случае вы можете сделать force push, чтобы обновить свою ветку на сервере перед созданием Pull Request.

В IDE эта опция обычно спрятана за кнопкой Push. Разработчики IDE сделали это намеренно, чтобы вы не нажали ее случайно.

Если вы не уверены на 100%, что делаете, — никогда не используйте force push. Безопаснее создать новый коммит с исправлениями.

6. Обновление проекта

Всегда нажимайте Update Project на ветке main перед началом работы над новой задачей. Это убережет вас от множества будущих конфликтов слияния и гарантирует, что вы начинаете работу с самой актуальной версией кода.

1

Опрос

Знакомство с Git, 26 уровень, 4 лекция

Недоступен

Знакомство с Git

Контроль версий: работа с Git и GitHub

Открыть