Мощный инструмент, если уметь с ним обращаться: используйте Git как сеньор

Оленка Пилипчак

Разработчик Якоб Беннет в своем блоге на Medium пишет, что Git — это мощный инструмент, которым приятно пользоваться, если вы понимаете, как именно это делать. 

Он годами использовал Git в разных командах и проектах. Хотя в отношении некоторых рабочих процессов у Якоба неопределенное мнение (например, относительно squash), он все равно считает этот инструмент очень мощным и гибким. Передаем ему слово. 

Просмотрим Git-логи

Git-логи не очень удобны для работы «из коробки».

Git log — база

Использование git log дает вам определенную информацию. Но это чрезвычайно высокое разрешение и обычно не то, что все ищут.

git log

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

Есть способ получше.

Git-лог с большей видимостью

Используя --graph и --format, мы можем быстро получить итоговый просмотр git-коммитов в нашем проекте:

git log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%an%C(reset)%C(bold yellow)%d%C(reset) %C(dim white)- %s%C(reset)' --all

А вот эти логи уже смотрятся красиво! Здесь есть даже что-то вроде дерева с ветками. 

Они показывают, кто над чем работал, когда были внесены изменения и как ваши изменения вписываются в общую картину:

  • --graph добавляет древовидный график слева. Это не самый стильный график, но он помогает визуализировать изменения в ветвях проекта (пример).
  • --format позволяет настроить формат ваших логов. Вы можете выбрать из уже готовых форматов или написать свой, как в этом примере.
  • --all содержит все ссылки, теги и ветки в логах (включая удаленные ветки). Возможно, вам это не нужно, поэтому можно настроить, как удобнее (пример).

Здесь можно посмотреть информацию о том, как вы можете улучшать свои git-логи.

Понимание конкретного коммита

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

Просмотр итогов коммита

git show <commit> --stat

Используя флажок --stat, вы увидите результат коммита вместе с измененными файлами и подробной информацией о том, как они изменились.

Просмотр определенных изменений файлов для коммита

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

git show <commit> -- <filepath>

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

Просмотрите документацию git-show, чтобы узнать, как лучше понимать git commit.

Внесение изменений

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

Если вы используете такой сервис, как GitHub, вам будет сообщено, не возник ли конфликт слияния:

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

Чтобы решить проблему, вы обычно выбираете один из двух путей: merge или rebase.

git слияние или git rebase

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

merge берет изменения из одной ветви и объединяет их с другой в одном коммите слияния.

git merge origin/main your-branch

rebase корректирует точку, в которой ветка фактически ответвляется (т.е. перемещает ветку в новую начальную точку от базовой ветви).

git rebase origin/main your-branch

Как правило, rebase используют, когда есть изменения в верхней ветке (например, main), которые хотят добавить в свою ветку. А merge когда изменения в ветке, которую хотят вернуть в main.

Использовать squash или нет

Раньше я был поклонником этого приема. Но после того, как прочитал статью Дерека Остина, изменил свое мнение. Рекомендую и вам с ней ознакомиться.  

Автор: Якоб Беннет

Читайте также: Шпаргалка из 25 полезных git-команд на каждый день

Текст адаптировала Евгения Козловская

Останні статті

Что такое прокси-сервер: пояснение простыми словами, зачем нужны прокси

Прокси (proxy), или прокси-сервер — это программа-посредник, которая обеспечивает соединение между пользователем и интернет-ресурсом. Принцип…

21.11.2024

Что такое PWA приложение? Зачем необходимо прогрессивное веб-приложение

Согласитесь, было бы неплохо соединить в одно сайт и приложение для смартфона. Если вы еще…

19.11.2024

Как создать игру на телефоне: программирование с помощью конструктора

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

17.11.2024

Google Bard: эффективный аналог ChatGPT

В перечне популярных чат-ботов с искусственным интеллектом Google Bard (Gemini) еще не пользуется такой популярностью…

14.11.2024

Скрипт и программирование: что это такое простыми словами

Скрипт (англ. — сценарий), — это небольшая программа, как правило, для веб-интерфейса, выполняющая определенную задачу.…

12.11.2024

Дедлайн в разработке: что это такое простыми словами

Дедлайн (от англ. deadline — «крайний срок») — это конечная дата стачи проекта или задачи…

11.11.2024