Отмена временных изменений с помощью Git

Question

Скажем, я нахожусь на 'хозяине' и у меня есть блоб:

DEBUG = FALSE
CACHE_SIZE = 100
code
code
code

Теперь я начинаю отладку в новой ветке ...

DEBUG = TRUE # Don't forget to turn off!
CACHE_SIZE = 0 # Don't forget to set back to 100!

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

Как я могу автоматизировать процесс возврата некоторых строк к исходному значению? Или, по крайней мере, сократить его до одной команды.

Может быть, какой-нибудь временный коммит, или тайник, или какая-то другая техника?

Answer 1

У Кэмерона есть несколько хороших идей для более коротких изменений отладки. Я хотел добавить общий, который работает даже для больших или более постоянных наборов локальных изменений отладки, например, если вы обычно вносите одни и те же изменения «не забывайте» каждый раз, когда добавляете функцию. Я слышал, это называется ткацкий станок, одеяло, сложенные ветви и трубопровод. Вы можете найти плагины с этими именами, чтобы помочь поддерживать этот вид рабочего процесса, но между ними есть тонкие различия, которые я никогда не осознавал, и метод не слишком сложен для применения вручную.

Основная идея состоит в том, что вы добавляете еще одну ветку между master и feature , назовем это debug . Вы вносите все свои изменения «не забывайте» в этой ветви, затем снова переходите от debug к созданию функции , которая содержит все ваши изменения, которые будут введены в производство в обычном режиме. Затем, чтобы удалить все ваши изменения «не забудьте» в компоненте , выполните:

git rebase --onto master debug feature

Это выглядит так, как будто вы разветвились прямо от master и никогда не добавляли изменения в ветку debug . Затем вы сливаетесь с master как обычно. В следующий раз, когда вы захотите добавить функцию, вы просто объедините master с debug , и ваши изменения "не забудьте" автоматически будут применены к последнему исходному коду. Затем просто создайте новую ветвь функции из debug и цикл начнется снова.

Очевидно, что вы все равно должны помнить о необходимости выполнить ребазинг, прежде чем сливаться с master . Идея зацепки Кэмерона может быть использована для предотвращения слияний, если вы забудете.

Answer 2

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

1. Убедитесь, что вы всегда проверяете различия перед фиксацией.git diff /path/to/file покажет вам изменения, и вы можете посмотреть "Не забудьте ...".
2. Вы можете немного автоматизировать это с помощью grep: git diff | grep "Don't forget"
3. Youможет даже иметь хук, который проверяет регулярное выражение (например, «не забывай») и запрещает коммиты, которые совпадают.Это может быть в вашем локальном репозитории или в репозитории, к которому вы отправляете.

Вариант 2, вероятно, самый простой.Это все еще требует некоторой дисциплины - вам нужно убедиться, что вы всегда ставите «Не забывать» (или «TODO», или «FIXME» или что-то еще) в комментарии, и вам нужно запустить git diff | grep, но это не такмного накладных расходов.

Вариант 3 поможет в долгосрочной перспективе предотвратить эту проблему, особенно если вы являетесь частью команды.Конечно, любой может изменить комментарий на «Не забывать» (или просто удалить комментарий) и обойти проверку, но это лучше, чем ничего.

Answer 3

Некоторые пользователи избегают индекса Git (например, всегда используя git commit -a и только используя git add для представления новых файлов), но я считаю, что индекс весьма полезен для подобных случаев.

Идея в том, чтобы никогда не фиксировать ваши «отладочные» изменения.

1. Я запускаю git diff, чтобы просмотреть изменения, которые я могу внести (т. Е. Различия между индексом и рабочим деревом).

   1. Для файлов, которые не имеют каких-либо «отладочных» изменений, я использую

      git add <pathspec> …
      

      для внесения изменений в эти файлы.

   2. Если в некоторых файлах есть как «отладочные», так и предполагаемые изменения, тогда я использую

      git add -p <pathspec> …
      

      в этих файлах пропустить все фрагменты «отладки».

      Если блок имеет как «отладочные», так и предполагаемые изменения, тогда я использую команды разделения и / или редактирования в git add -p только для того, чтобы подготовить предполагаемые изменения.

2. Перед фиксацией я использую git diff --cached, чтобы тщательно просмотреть поэтапные изменения (то есть разницу между HEAD и индексом).

   • Если «отладочное» изменение внесено в окончательный индекс, тогда я использую

     git reset -p <pathspec> …
     

     (возможно, с использованием его команд split или edit) для отмены «отладочных» изменений из индекса.

---

Примечание. Если вы проводите тестирование непосредственно из рабочего дерева «отладки», вы должны знать, что вы всегда тестируете с изменениями «отладки». В некоторых основах кода наличие определенных «отладочных» изменений может существенно изменить поведение тестируемой системы. Если для вашей команды важно, чтобы ни один из опубликованных коммитов никогда не проходил тестирование, вам следует потратить время на то, чтобы протестировать именно то, что вы зафиксировали (без изменений отладки).

Вы можете использовать git stash после каждого коммита, чтобы сохранить ваши «отладочные» изменения, пересобрать и протестировать именно то, что вы зафиксировали. После завершения тестирования вы можете git stash pop восстановить ваши «отладочные» изменения в вашем рабочем дереве.

---

git reset -p впервые был доступен в Git 1.6.5 (также git checkout -p и git stash -p). git add -p впервые был доступен в Git 1.5.4.