Контроль версий — это волшебство.
Я твердо верю, что каждый должен научиться его использовать, а не только разработчики. Сколько раз вы выполняли домашнее задание еще в школе и создавали массивы имен файлов, чтобы обозначить, насколько окончательным был этот кусок работы?
Сегодня в современной веб-разработке 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.