Обработка временных изменений (не нужно фиксировать) в Git - PullRequest
20 голосов
/ 22 августа 2011

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

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

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

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

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

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


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

Ответы [ 10 ]

13 голосов
/ 22 августа 2011

Я обычно имею дело с этим с помощью:

git add -p

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


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

git rebase -i master

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

git checkout master
git merge local-changes^
git checkout local-changes
6 голосов
/ 22 августа 2011

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

РЕДАКТИРОВАТЬ: Это не позволяет вам иметь дело с одним файлом с временными и постоянными изменениями.

4 голосов
/ 22 августа 2011

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

Настройка:

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

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

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 [чтобы удалить временные изменения перед нажатием]

3 голосов
/ 22 августа 2011

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

git stash

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

git stash pop

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

1 голос
/ 16 ноября 2017

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

#warning - DEBUG ONLY - DO NOT MERGE

print(debugInfo)

#warning - DEBUG ONLY - DO NOT MERGE

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

Тогда у вас будут разные способы удаления отладочных коммитов:

  1. revert определенные отладочные коммиты. Это сохранит их историю в отрасли.

  2. cherry-pick совершается хорошо . Это полностью удалит отладочные коммиты.

  3. Что-то более сложное, например rebase -interactive, для удаления коммитов на месте.

1 голос
/ 12 октября 2015

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

1 голос
/ 22 августа 2011

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

1 голос
/ 22 августа 2011

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

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

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

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

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

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

Репо теперь выглядит так:

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

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

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

  • checkout branch-temp
  • commit - изменить там временные изменения - это неправильно, так как это приводит к расхождению "branch-temp"

Для объединения изменений из ветки вmaster :

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

  • запустить обычное слияние из "ветки" в "master"
    (теперь у нас есть слияние, но с некоторыми ненужными временными изменениями - давайте удалим их)
  • git revert --no-commit branch-temp
  • git commit --amend
    (эти два шага должны изменить коммит слияния, чтобы он больше несодержит изменения от Branch-Temp)
0 голосов
/ 22 августа 2011

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

0 голосов
/ 22 августа 2011

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

...