Недавно мы опубликовали несколько учебных пособий, чтобы познакомить вас с основами Git и использованием Git в командной среде . Обсуждаемых нами команд было достаточно, чтобы помочь разработчику выжить в мире Git. В этом посте мы попытаемся изучить, как эффективно управлять своим временем и в полной мере использовать функции, предоставляемые Git.
Примечание. Некоторые команды в этой статье содержат часть команды в квадратных скобках (например, git add -p [file_name] ). В этих примерах вы должны вставить нужный номер, идентификатор и т. Д. Без квадратных скобок.
1. Git Автозаполнение
Если вы запускаете команды Git через командную строку, вводить команды вручную каждый раз утомительно. Чтобы помочь с этим, вы можете включить автоматическое завершение команд Git в течение нескольких минут.
Чтобы получить скрипт, запустите следующее в системе Unix:
cd ~ curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
Затем добавьте следующие строки в ваш файл ~/.bash_profile :
if [ -f ~/.git-completion.bash ]; then . ~/.git-completion.bash fi
Хотя я упоминал об этом ранее, я не могу не подчеркнуть это: если вы хотите полностью использовать возможности Git, вам определенно следует перейти к интерфейсу командной строки!
2. Игнорирование файлов в Git
Вы устали от скомпилированных файлов (таких как .pyc ), появляющихся в вашем Git-репозитории? Или ты настолько сыт по горло, что добавил их в Git? Не смотрите дальше, есть способ, с помощью которого вы можете сказать Git полностью игнорировать определенные файлы и каталоги. Просто создайте файл с именем .gitignore и перечислите файлы и каталоги, которые вы не хотите отслеживать в Git. Вы можете делать исключения, используя восклицательный знак (!).
*.pyc *.exe my_db_config/ !main.pyc
3. Кто перепутал мой код?
Это естественный инстинкт человека обвинять других, когда что-то идет не так. Если ваш рабочий сервер сломан, найти виновника очень легко — просто сделайте git blame . Эта команда показывает вам автора каждой строки в файле, коммита, который видел последнее изменение в этой строке, и метку времени коммита.
git blame [file_name]
И на скриншоте ниже вы можете увидеть, как эта команда будет выглядеть в большем хранилище:
4. Просмотрите историю репозитория
Мы рассмотрели использование git log в предыдущем уроке, однако есть три варианта, о которых вы должны знать.
-
--oneline—--onelineинформацию, отображаемую рядом с каждым коммитом, в уменьшенный хэш коммита и сообщение о--oneline, все они отображаются в одной строке. -
--graph— эта опция рисует текстовое графическое представление истории в левой части вывода. Это бесполезно, если вы просматриваете историю для одной ветви. -
--all— Показывает историю всех ветвей.
Вот как выглядит комбинация опций:
5. Никогда не теряйте след коммита
Допустим, вы совершили что-то, чего не хотели, и в итоге сделали полный сброс, чтобы вернуться в свое предыдущее состояние. Позже вы понимаете, что потеряли какую-то другую информацию в процессе и хотите вернуть ее или хотя бы просмотреть. Вот где может помочь git reflog .
Простой git log показывает вам последний коммит, его родителя, родителя его родителя и так далее. Однако git reflog — это список git reflog , на которые была указана голова. Помните, что это локально для вашей системы; это не часть вашего хранилища и не включается в слияния или слияния.
Если я запускаю git log , я получаю коммиты, которые являются частью моего репозитория:
Однако, git reflog показывает коммит ( b1b0ee9 — HEAD@{4} ), который был потерян, когда я сделал b1b0ee9 сброс:
6. Подготовка частей измененного файла для фиксации
Как правило, рекомендуется делать коммиты на основе функций, то есть каждый коммит должен представлять функцию или исправление ошибки. Подумайте, что произойдет, если вы исправите две ошибки или добавите несколько функций без внесения изменений. В такой ситуации вы можете поместить изменения в один коммит. Но есть и лучший способ: размещать файлы по отдельности и фиксировать их отдельно.
Допустим, вы внесли несколько изменений в один файл и хотите, чтобы они появлялись в отдельных коммитах. В этом случае мы добавляем файлы, добавляя префикс -p к нашим командам добавления.
git add -p [file_name]
Попробуем продемонстрировать то же самое. Я добавил три новые строки в file_name и хочу, чтобы в моем коммите появлялись только первая и третья строки. Давайте посмотрим, что нам показывает git diff .
И давайте посмотрим, что радует, когда мы добавляем префикс -p к нашей команде add .
Похоже, что Git предположил, что все изменения были частью одной и той же идеи, тем самым сгруппировав ее в один кусок. У вас есть следующие варианты:
- Введите y, чтобы поставить этот ломоть
- Введите не ставить этот кусок
- Введите e, чтобы вручную редактировать блок
- Введите d для выхода или перейдите к следующему файлу.
- Введите s, чтобы разделить кусок.
В нашем случае мы определенно хотим разделить его на более мелкие части, чтобы выборочно добавить некоторые из них и игнорировать остальные.
Как видите, мы добавили первую и третью строки и проигнорировали вторую. Затем вы можете просмотреть состояние хранилища и сделать коммит.
7. Сквош несколько коммитов
Когда вы отправляете свой код на проверку и создаете запрос на извлечение (что часто происходит в проектах с открытым исходным кодом), вас могут попросить внести изменения в код, прежде чем он будет принят. Вы вносите изменения только для того, чтобы вас попросили изменить их еще раз в следующем обзоре. Прежде чем вы это знаете, у вас есть несколько дополнительных коммитов. В идеале вы могли бы раздавить их в один, используя команду rebase .
git rebase -i HEAD~[number_of_commits]
Если вы хотите раздавить два последних коммита, вы выполните следующую команду.
git rebase -i HEAD~2
Запустив эту команду, вы попадете в интерактивный интерфейс со списком коммитов и спросите вас, какие из них нужно раздавить. В идеале вы pick последний коммит и squash старые.
Затем вас попросят предоставить сообщение о коммите для нового коммита. Этот процесс по существу переписывает вашу историю коммитов.
8. Копить незафиксированные изменения
Допустим, вы работаете над определенной ошибкой или функцией, и вас внезапно попросили продемонстрировать вашу работу. Ваша текущая работа недостаточно завершена, чтобы быть зафиксированной, и вы не можете провести демонстрацию на этом этапе (не отменяя изменения). В такой ситуации на помощь приходит git stash . Stash по сути берет все ваши изменения и сохраняет их для дальнейшего использования. Чтобы сохранить ваши изменения, вы просто запустите
git stash
Чтобы проверить список тайников, вы можете запустить следующее:
git stash list
Если вы хотите отменить сохранение и восстановить незафиксированные изменения, примените тайник:
git stash apply
На последнем скриншоте вы можете видеть, что у каждого тайника есть идентификатор, уникальный номер (хотя у нас есть только один тайник в этом случае). Если вы хотите применить только выборочные тайники, добавьте конкретный идентификатор в команду apply :
git stash apply stash@{2}
9. Проверьте потерянные коммиты
Хотя reflog является одним из способов проверки потерянных reflog в больших репозиториях это невозможно. Именно тогда в игру вступает команда fsck (проверка файловой системы).
git fsck --lost-found
Здесь вы можете увидеть потерянный коммит. Вы можете проверить изменения в git show [commit_hash] запустив git show [commit_hash] или восстановить его, запустив git merge [commit_hash] .
git fsck имеет преимущество перед reflog . Допустим, вы удалили удаленную ветку и затем клонировали репозиторий. С помощью fsck вы можете искать и восстанавливать удаленную удаленную ветку.
10. Cherry Pick
Я сохранил самую элегантную команду Git для последнего. Команда cherry-pick — безусловно, моя любимая команда Git из-за ее буквального значения и полезности!
Проще говоря, cherry-pick один коммит из другой ветви и объединяет его с вашим текущим. Если вы работаете параллельно в двух или более ветвях, вы можете заметить ошибку, которая присутствует во всех ветвях. Если вы решите это в одной, вы можете выбрать коммит в другие ветви, не связываясь с другими файлами или коммитами.
Давайте рассмотрим сценарий, в котором мы можем применить это. У меня есть две ветки, и я хочу cherry-pick коммит b20fd14: Cleaned junk в другую.
Я переключаюсь на ветку, в которую я хочу cherry-pick коммит, и запускаю следующее:
git cherry-pick [commit_hash]
Несмотря на то, что на этот раз у нас была чистая cherry-pick , вы должны знать, что эта команда часто может привести к конфликтам, поэтому используйте ее с осторожностью.
Вывод
На этом мы заканчиваем наш список советов, которые, я думаю, могут помочь вам поднять свои навыки в Git на новый уровень. Git — лучший из всех, и он может выполнить все, что вы можете себе представить. Поэтому всегда пытайтесь бросить вызов себе с помощью Git. Скорее всего, вы в конечном итоге узнаете что-то новое!