Работа с временными изменениями (не обязательными) в Git

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

Об этих "временных" изменениях:

Я хочу их в своей рабочей копии моей ветки, потому что они помогают мне работать над фактическим изменением,
Я не хочу, чтобы они были привязаны к ветке, потому что ветка будет объединена в мастер некоторое время, и они не являются производственным кодом.

В настоящее время я просто сохраняю их как нестационарные, и я пропущу их вручную, когда выполняем каждую фиксацию. Однако я не могу оставаться с этим решением, потому что:

Все время я должен помнить, какие файлы мне нужно пропустить,
Когда-нибудь у меня будет 2 изменения в одном файле, один из которых временный, один из которых будет совершен, и это будет действительно хлопотно.

Как мне с этим бороться?

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

Ответ 1

Обычно я общаюсь с этим:

git add -p

... для смены скоростей. Затем вам нужно только нажать n для своих отладочных изменений.

Если у меня больше задействованы изменения этого типа, я создам ветвь, называемую чем-то вроде local-changes с фиксацией на ее кончике, которая вводит код отладки. Создав еще несколько коммитов, я бы использовал:

git rebase -i master

..., чтобы переупорядочить их так, чтобы фиксация с локальными изменениями снова вернулась. Затем, чтобы обновить мастер и вернуться в локальную ветвь изменений, вы можете сделать:

git checkout master
git merge local-changes^
git checkout local-changes

Ответ 2

Попробуйте git update-index --assume-unchanged <file>. Таким образом, git не будет добавлять файл в индекс при использовании git add или git commit -a.

EDIT: Это не позволяет вам иметь дело с случаем наличия одного файла с временными и постоянными изменениями.

Ответ 3

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

Настройка:

git branch tempChanges  [branch for temporary changes]
  [create your temporary changes]
git add -A
git commit

Обратите внимание на sha для этого фиксации. Затем переключитесь на свою рабочую ветку и:

git cherry-pick shaOfTempChangesCommit

Теперь у вас есть изменения в вашей рабочей ветке. Выполняйте свою работу и совершайте коммиты. Затем, прежде чем нажимать:

git rebase -i

Вы увидите что-то вроде этого:

pick bfd4d2e This first commit is your temporary changes.
pick 186a99d Some stuff done on the working branch.
pick ec871c6 More stuff done on the working branch.
(etc.)

Удалите строку с вашими временными изменениями. Затем сохраните и выйдите. Ваша история будет переписана, чтобы исключить временные изменения. (Изменения все равно будут существовать в ветке tempChanges.) После этого выполните любое тестирование, которое вам нужно, а затем git push.

Когда вы будете готовы снова работать, вы можете вернуть временные изменения в текущую рабочую ветку (или новую рабочую ветку):

git cherry-pick shaOfTempChangesCommit

Итак, в сумме, все, что вам нужно запомнить в этом методе, это

после создания рабочей ветки

git cherry-pick shaOfTempChangesCommit
после того, как вы закончите работу и готовы нажать

git rebase -i [для удаления временных изменений перед нажатием]

Ответ 4

Вы можете использовать

git stash

чтобы сохранить его во временном пространстве. После выполнения слияния вы можете использовать

git stash pop

чтобы вернуть ваши временные изменения в рабочий каталог.

Ответ 5

~~Я нашел чистое решение этой проблемы: (pardon my ascii-art). Для этого требуется дополнительная ветка для ветки темы.~~ (это имеет недостатки и оспаривается/исправляется, см. комментарии)

Работа сначала выглядит так:

master
     \
      \
     commit1  ---- commit2 ---- "branch"

Работа выполняется на "ветке".

Чтобы ввести некоторые временные изменения:

создать ветку "ветвь-temp" из "master"
зафиксировать временные изменения там
rebase "branch" от "master" на "branch-temp"

Теперь репо выглядит следующим образом:

master
     \
      \
     "branch-temp" ----- commit1 ---- commit2 ---- "branch"

Работа теперь с радостью продолжается в ветке , а временные изменения не отображаются в статусе.

Чтобы изменить или расширить временные изменения:

checkout branch-temp
~~commit -amend временные изменения там~~ - это неправильно, так как это приводит к тому, что распад "ветка-темп"

Чтобы слить изменения из ветки в мастер:

Это немного сложнее. Мы хотим объединить все изменения, кроме изменений, внесенных в "ветвь-темп". Моя идея:

запустить нормальное слияние из "ветки" на "мастер"
(теперь мы имеем слияние, но с некоторыми ненужными временными изменениями - удалим их)
git revert --no-commit branch-temp
git commit --amend
(эти два шага должны изменить фиксацию слияния, так что он больше не содержит изменений от temp ветвей)

Ответ 6

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

Ответ 7

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

например.

git apply-my-debug
...
do coding
...
git remove-my-debug
git add .
git commit -m "Don't worry about debug changes"

Ответ 8

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

#warning - DEBUG ONLY - DO NOT MERGE

print(debugInfo)

#warning - DEBUG ONLY - DO NOT MERGE

Когда вы будете готовы объединить ветвь, если вы забыли о них, эти изменения будут обнаружены вами или кем-то еще в обзоре кода вашего запроса на перенос.

После этого у вас будут разные способы удаления фиксации отладки:

revert фиксируется конкретная ошибка отладки. Это сохранит свою историю в отрасли.
cherry-pick хорошая фиксация. Это полностью устранит фиксацию отладки.
Что-то более сложное, например rebase -interactive для удаления коммитов на месте.

Ответ 9

GIT Функциональность закладок обеспечивает именно то, о чем вы просите. По крайней мере, для "хранения". Сделать хороший/плохой выбор при совершении невозможно избежать.

Ответ 10

Я, как правило, не допускаю подобных изменений. Я просто использую git add -i или git add -p для смены изменений (если только я не уверен, что хочу все изменения, которые имеет дерево). Таким образом, я просматриваю все изменения, которые я хочу совершить, и легко пропускаю временные. Это также помогает сгенерировать изменения, которые, как вы знаете, вам нужно выполнить раньше, и держать их в поэтапном или даже комментировать, а также добавлять дополнительные изменения с помощью git commit --amend.