Контроль версий — это волшебство.

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

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

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

git перебазировать

Git rabasing сводится к перемещению или объединению последовательности коммитов в новый базовый коммит. По сути, это выглядит так, как будто вы создали свою ветку из другой базы коммитов — чрезвычайно полезно, если вы некоторое время работали над веткой, вы какое-то время отклонялись от основной ветки и сталкиваетесь с конфликтами, когда вы попробуй обратно слиться.

Это работает примерно так:

git checkout main # change to main branch
git pull origin main 
git checkout - # go back to last branch (feature branch)
git rebase main
# fix conflicts
git add .
git rebase --continue # until all changes are in

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

Некоторые из вас могут подумать, что можно просто git pull origin main в своей ветке разрешить конфликты слияния еще проще. Хотя они оба похожи, есть одна огромная разница, которую вы должны иметь в виду:

  • git pull создаст новый коммит, объединяющий две ветки вместе
  • git rebase будет перемещать коммиты одной ветки поверх другой

Вы также можете использовать git pull --rebase для извлечения с помощью rebase, что может быть здорово и сэкономить вам много времени. Однако

git rebase по существу сохранит вашу историю git в чистоте.

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

Это означает, что вы можете безопасно и эффективно использовать нашу следующую магическую силу: git bisect.

git пополам

git bisect использует бинарный поиск, чтобы найти фиксацию, в которой появилась новая нежелательная функциональность (читай: ошибка).

Это работает примерно так:

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

Мы можем использовать git bisect, чтобы сузить коммиты и помочь нам определить виновника следующим образом:

git bisect start 
git bisect bad 
git bisect good 0cd429f02

Примечание. Вы можете использовать git bisect reset, чтобы выйти из этого.

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

Теперь, когда вы находитесь в проверенном коммите, вы должны запустить свои тесты и предположить, что он работает, вы можете сообщить об этом bisect, набрав git bisect good, или сообщить bisect, что эта конкретная версия дает сбой с помощью git bisect bad.

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

git тайник

Скрытие используется для того, чтобы забрать ваши незафиксированные изменения (в том числе поэтапные) и временно «спрятать» их на потом.

Чрезвычайно полезно, когда вы не совсем готовы зафиксировать изменение, но по какой-то причине вам нужно перейти в другую ветку — может быть, есть ошибка, которую нужно исследовать.

Вы можете спрятать свой контент следующим образом:

git status
Changes not staged for commit: modified: 
README.md modified: 
mix.exs modified: 
test/inspyre_web/live/story_live_test.exs 
no changes added to commit (use "git add" and/or "git commit -a" ) 
git stash 
git status 
On branch main Your branch is up to date with 'origin/main' .

Как по волшебству, ваши изменения, казалось бы, исчезли ... или они?

Если вы запустите git stash list, вы увидите журнал ранее сохраненных событий рядом с веткой, в которой вы работали, и последней фиксацией в этом журнале.

Запуск git stash apply возьмет последний спрятанный набор изменений и применит их к вашей текущей ветке, но не удалит их из вашего списка спрятанных файлов. Если вы знаете, что в этот раз они вам не понадобятся, вы можете использовать git stash pop, чтобы применить изменения и вытащить их из списка.

git reset — мягкий HEAD^N

Вы когда-нибудь случайно думали, что изменили ветку, но на самом деле вы все еще были в последней функции, над которой работали?

Вы совершили несколько раз?

Ой. Это круто — мы можем это исправить.

Используйте git reset --soft HEAD^N, где N — количество коммитов, которые вы хотите отменить, чтобы вернуть их вам. Отсюда вы можете спрятать или перейти в другую ветку и зафиксировать их там.

Будьте осторожны, чтобы не ввести --hard. Это навсегда сотрет несохраненные изменения.

git рефлог

Секретное оружие Gits / капсула времени.

git reflog даст вам список всего, что вы сделали в git в каждой отдельной ветке.

Если вы случайно оказались в состоянии, в котором не ожидали оказаться, удалили что-то, случайно объединили что-то или не можете понять, что произошло, доберитесь до git reflog (по крайней мере, прежде чем вы все испортите и повторно клонируете репозиторий ).

Это просто, но эффективно — и я знаю, что несколько разработчиков прибегают к удалению и воссозданию ветки для решения! 🤯

Переименование ветки!

Просто введите git branch -M <new_branch_name>, чтобы установить новое имя ветки для ветки, в которой вы сейчас находитесь.

Это все люди.

Надеюсь, это было полезно для некоторых — подпишитесь на мой Substack для получения аналогичного контента и подпишитесь на меня в Twitter, чтобы получить дополнительные советы по git (и общему программированию).

Первоначально опубликовано на https://www.chriis.dev.