Содержание
- 01. Исправить недавнюю историю
- $ git add article.md $ git commit -m ’первый черновик раздела поправок '[master 8dbf5d5] первый черновик раздела поправок 1 файл изменен, 47 вставок (+) режим создания 100644 article.md
- 02. Отменить недавнюю историю
- 03. Поддерживайте аккуратную историю
- 04. Очистите недавнюю историю
- 05. Перепишите всю историю
- 06. Мощность и гибкость
- Понравилось это? Прочтите это!
В то время как ученые разрушили мечту о путешествии во времени, Git предлагает контроль над четвертым измерением, когда нужно исправить ошибки прошлого. Распределенная система контроля версий позволяет изменять, отбрасывать, переупорядочивать и изменять коммиты, чтобы очистить историю репозитория.
Но прислушайтесь к предупреждениям опытного путешественника во времени. Git подчиняется закону причинности; каждая фиксация в репозитории Git неразрывно связана с предыдущей фиксацией. Изменение одного коммита изменяет все последующие коммиты, создавая альтернативную реальность. Изменение прошлого может быть опасным и - за исключением редких случаев - должно производиться только в том случае, если изменяемые события не наблюдались кем-либо еще. Ветви, которые уже были отправлены на удаленный компьютер, не следует изменять.
Присоединяйтесь ко мне, когда мы исследуем способы переписать историю с помощью Git.
01. Исправить недавнюю историю
По какой-то причине человеческий мозг, кажется, запрограммирован на запоминание чего-то важного сразу после нажатия кнопки «Отправить» в электронном письме, а правильные слова всегда приходят на ум после завершения разговора. Точно так же я часто понимаю, что совершил ошибку сразу после фиксации в Git. Самая безопасная и распространенная форма переписывания истории Git - это изменение последней фиксации.
Эта статья написана в репозитории Git. Первая фиксация заключалась в создании README, объясняющего назначение репозитория.
$ git add.
$ git commit -am ’Добавить README’
[master (root-commit) 6261ead] Добавить README
2 файла изменено, 12 прошивок (+)
режим создания 100644 README.md
режим создания 100644 article.md
Ой, после совершения я понял, что совершил article.md, который был всего лишь некоторыми примечаниями и несколькими первыми предложениями введения. Я пока не собирался фиксировать этот файл, поэтому давайте удалим его из истории.
$ git rm --cached article.md
rm ’article.md’
В --cached аргумент git rm сообщает Git, что нужно выполнить удаление файла, но не удалять его из файловой системы. Если вы также хотите удалить файл, просто оставьте этот аргумент.
Мы также можем внести другие изменения, как если бы мы собирались создать еще одну фиксацию, например, внесение изменений в README.md и постановка их с git добавить. Измените предыдущую фиксацию, передав --исправлять флаг git commit:
$ git commit --amend
[master 667f8c9] Добавить README
1 файл изменен, 7 прошивок (+)
режим создания 100644 README.md
Git откроет редактор, позволяющий редактировать предыдущее сообщение фиксации. Журнал Git теперь показывает, что есть только одна фиксация, и эта фиксация имеет только README.md.
$ git log --oneline --stat
667f8c9 Добавить README
README.md | 7 +++++++
1 файл изменен, 7 прошивок (+)
Давайте зафиксируем эту статью сейчас, когда был достигнут прогресс.
$ git add article.md $ git commit -m ’первый черновик раздела поправок '[master 8dbf5d5] первый черновик раздела поправок 1 файл изменен, 47 вставок (+) режим создания 100644 article.md
02. Отменить недавнюю историю
Иногда в коммите так много ошибок, что его легче просто отменить. Возможно, он был привязан не к той ветке, или случайно был добавлен каталог с ненужными файлами.
$ git сбросить HEAD ^
Это говорит Git о том, что нужно удалить предыдущую фиксацию, но сохранить изменения, внесенные этой фиксацией, локально. git сбросить является мощным и может быть разрушительным при неправильном использовании. Об этом стоит прочитать на git-scm.com.
Журнал теперь показывает, что последняя фиксация исчезла, но article.md все еще доработан.
$ git log --oneline
667f8c9 Добавить README
$ git status -s
M article.md
Отсюда изменения могут быть зафиксированы в другой ветке, сохранены, отменены или изменены и повторно приняты.
03. Поддерживайте аккуратную историю
Если вы использовали Git с командой, то нет сомнений, что вы видели отклонение push-запроса.
$ git push origin master
Кому [email protected]: bkeepers / git-history.git
! [отклонено] мастер -> мастер (без перемотки вперед)
ошибка: не удалось отправить некоторые ссылки на ’[email protected]: bkeepers / git-history.git’
Подсказка: обновления были отклонены, потому что верхушка вашей текущей ветки отстает
подсказка: его удаленный аналог. Объедините удаленные изменения (например, ’git pull’)
подсказка: прежде чем снова нажать.
Подсказка: подробности см. в «Примечании о быстрой перемотке вперед» в ’git push --help’.
Хотя это сообщение выглядит большим и пугающим, на самом деле оно весьма полезно. Подсказки говорят нам, что с тех пор, как мы начали нашу работу, один из членов нашей команды внес изменения, и нам нужно получить их, обычно путем запуска мерзавец тянуть. Подсказка также рекомендует проверить примечание о «быстрой перемотке вперед» в документации Git. Я поддерживаю эту рекомендацию.
Бег мерзавец тянуть получит удаленные изменения и создаст новую фиксацию, которая объединит их с нашими локальными изменениями. Хотя в фиксации слияния нет ничего плохого, она добавляет ненужной сложности в историю изменений.
$ git log --decorate --graph --oneline
* aaf6c0c (HEAD, master) Слияние ветки 'master' происхождения
|
| * 9f7e4de Обновить README
* | 00165a8 первый проект поправки к разделу
|/
* 667f8c9 (origin / reset) Добавить README
То, что сделало бы нашу историю более ясной и читаемой, - это способ принять наши изменения и применить их поверх удаленных изменений, например:
$ git pull --rebase origin master
Во-первых, перематываем голову, чтобы воспроизвести вашу работу поверх нее ...
Применение: обновить README
Это заставляет историю изменений выглядеть так, как если бы изменение было внесено после того, как член команды совершил фиксацию.
$ git log --decorate --graph --oneline
* 8dbf5d5 первый вариант раздела поправок
* c408281 обновить README
* 667f8c9 Добавить README
Как видите, наша история Git стала намного чище и ее легче сканировать.
Если репозиторий не передается на несколько пультов дистанционного управления, перебазирование при извлечении почти всегда является хорошей идеей. У меня Git настроен на автоматическую переустановку.
$ git config --global branch.autosetuprebase всегда
Хранение истории изменений в порядке может показаться поверхностным, но оно очень помогает при управлении большим проектом.
04. Очистите недавнюю историю
Иногда после нескольких неверных шагов не становится ясно, что есть лучший путь. Гибкость Git позволяет легко создавать контрольные точки в процессе, предлагая точку, к которой можно вернуться, если что-то пойдет не так.
В своем повседневном развитии я делаю это как можно чаще. Каждый раз, когда я думаю про себя: «Хорошо, что сделано, что теперь?», Я совершаю это. Хотя это приводит к истории изменений, которая точно отражает порядок событий, шум множества крошечных коммитов может фактически препятствовать ремонтопригодности больших проектов. Итак, как только я готов поделиться своими изменениями со своей командой, я просматриваю свои неопубликованные коммиты и убираю их.
Интерактивная перебазировка позволяет редактировать, объединять или полностью удалять коммиты из недавней истории ветки.
Просматривая свой прогресс в работе над этой статьей, я обнаружил несколько досадных опечаток. Поскольку репозиторий еще никому не был предоставлен, я заместил свои следы, исправив опечатки в исходном коммите. Я сохранил свою исходную ошибку, так что вы можете следить за ней, проверив ветку опечаток в репозитории.
Сначала я создал два новых коммита, чтобы исправить опечатки.
$ git log --oneline
7445019 Исправить неправильное написание поправки
b0377f9 Исправить опечатку в заголовке
b1cdd72 первый набросок pull --rebase
2fbe35b первый черновик сброса
7bb9109 первый проект поправки к разделу
667f8c9 Добавить README
Обратите внимание на фиксацию, которую необходимо исправить. Обе опечатки были из-за фиксации 7bb9109, первый проект поправки. Запустите перебазирование с ревизии до:
$ git rebase -i 7bb9109 ^
Git откроет редактор со списком коммитов и очень полезным сообщением.
выберите 7bb9109 первый вариант раздела поправок
выберите 2fbe35b первый черновик сброса
выберите b1cdd72 первый набросок pull --rebase
pick b0377f9 Исправить опечатку в заголовке
выбрать 7445019 Исправить орфографическую ошибку в поправке
# Rebase 667f8c9..7445019 на 667f8c9
#
# Команды:
# p, pick = использовать фиксацию
# r, reword = использовать фиксацию, но отредактировать сообщение фиксации
# e, edit = использовать фиксацию, но не вносить поправки
# s, squash = использовать фиксацию, но сливается с предыдущей фиксацией
# f, fixup = как "squash", но удалить сообщение журнала этой фиксации
# x, exec = run команда (остальная часть строки) с использованием оболочки
#
# Эти строки можно переупорядочить; они выполняются сверху вниз.
#
# Если вы удалите здесь строчку, ЧТО COMMIT БУДЕТ УТЕРЯНЫ.
#
# Однако, если вы удалите все, перебазирование будет прервано.
#
# Обратите внимание, что пустые коммиты закомментированы
Как поясняется в примечании, коммиты можно переупорядочить, чтобы изменить их порядок, или выбирать можно изменить на одну из других команд.
выберите 7bb9109 первый вариант раздела поправок
fixup b0377f9 Исправить опечатку в заголовке
fixup 7445019 Исправить неправильное написание поправки
выберите 2fbe35b первый черновик сброса
выберите b1cdd72 первый набросок pull --rebase
Я переместил два исправления опечатки сразу после фиксации, где они были введены, и изменил выбор на исправить чтобы объединить их с исходной фиксацией. После сохранения и закрытия редактора Git применит изменения:
[отдельная ГОЛОВА 00165a8] первый проект поправки к разделу
1 файл изменен, 47 прошивок (+)
режим создания 100644 article.md
Успешно перебазирован и обновлен refs / Heads / master.
Журнал показывает, что исправления опечаток больше нет. Исправления были применены к исходным коммитам, и нет никаких свидетельств моего плохого написания (в этой ветке).
$ git log --oneline
4787614 первый набросок pull --rebase
ee719e9 первый проект сброса
00165a8 первый проект поправки к разделу
667f8c9 Добавить README
Эта перебазировка работала без какого-либо другого взаимодействия, но иногда для перебазирования требуется ручное исправление конфликтов слияния. Если это произойдет, не волнуйтесь. Просто прочтите сообщения. Git обычно помогает вывести вас из затруднительного положения.
05. Перепишите всю историю
Все команды Git, которые мы рассмотрели до сих пор, полезны для изменения недавних коммитов, но иногда необходимы более крайние меры, будь то удаление конфиденциальных или очень больших файлов или просто упрощение управления проектом.
git filter-branch поддерживает набор настраиваемых фильтров, которые могут переписать историю изменений для ряда коммитов.
Мое первое законное использование git filter-branch был в большом проекте, где сервер и клиент находились в одном репозитории. По мере того, как к команде добавлялось больше людей и возрастала напряженность между хипстерами и бородами, стало очевидно, что два хранилища будут более подходящими.
Простым решением было бы дважды клонировать репозиторий, удалить ненужные файлы и переместить оставшиеся файлы. Но это оставляет два репозитория с повторяющимися историями, которые занимают ненужное место. Вместо этого мы дважды клонировали репозиторий и использовали --subdirectory-filter для создания двух новых репозиториев, содержащих изменения только для соответствующих частей приложения.
$ git rebase -i 7bb9109 ^
Многие люди используют разные адреса электронной почты для личных и рабочих проектов, что может легко привести к фиксации в репозитории с использованием неправильного адреса электронной почты. -env-фильтр может изменять базовые метаданные о фиксации, такие как информация об авторе или дата фиксации.
$ git filter-branch --env-filter ’
если [$ GIT_AUTHOR_EMAIL = [email protected]];
затем [email protected];
fi; экспорт GIT_AUTHOR_EMAIL ’
Перепишите f853027b7979756bab7146d3bb34d8829b81a884 (8/8)
Ref ’refs / Heads / master’ был переписан
Предположим, что на раннем этапе проекта кто-то зафиксировал очень большие ресурсы, и теперь каждый, кто клонирует репозиторий, должен дождаться загрузки этих ресурсов. Или, может быть, вы открываете исходный код проекта, в котором хранятся конфиденциальные данные.
$ git filter-branch --index-filter ’git rm -r --cached --ignore-unmatch docs / designs’
--prune-empty --tag-name-filter cat - --all
Все следующие изменения перезапишут полную историю репозитория, по сути сделав его новым репозиторием. Направление на тот же пульт, который использовался изначально, будет отклонен.
$ git push
! [отклонено] главный -> главный (без перемотки вперед)
Можно заставить Git передавать все изменения на существующий пульт, но помните, что это может иметь неблагоприятные последствия для всех, кто работает над проектом.
$ git push --force --all --tags
06. Мощность и гибкость
Мощные функции Git, чрезвычайная гибкость и часто не интуитивно понятная командная строка могут показаться ошеломляющими, но потратить время на изучение и эксперименты - это стоящее вложение. Если есть сомнения, пройдите --помощь любой команде Git, чтобы узнать больше. Понимание того, как и когда переписывать историю изменений, даст вам полный контроль над вашими проектами и упростит управление ими.
Изображение любезно предоставлено JohnGoode в соответствии с лицензией Creative Commons.
Брэндон Киперс - создатель и первооткрыватель вещей в GitHub, работающий в основном над Speaker Deck. Когда его лицо не тускло освещено экраном компьютера, вы можете увидеть, как он с книгой в руках играет в ракетбол или баскетбол, бегает со своей собакой или наслаждается хорошей едой и напитками со своей женой.
Понравилось это? Прочтите это!
- Как создать приложение: попробуйте эти замечательные уроки
- Бесплатная программа для графического дизайна доступна вам прямо сейчас!
- Блестящий выбор учебников по Wordpress
