git add -p не читает файл патчей. Вместо этого он берет файл, который уже находится под контролем исходного кода Git, и сравнивает индексную версию этого файла с версией рабочего файла этого файла. Что бы ни отличалось, это , что git add -p позволяет интерактивно вносить исправления в индекс.
Следовательно, вместо того, что вы делали, вам пришлось бы сохранять где-нибудь каждый измененный файл, переключать коммиты, восстанавливать все измененные файлы в ваше рабочее дерево, и затем запустить git add -p ( без аргументов вообще). Но, как правило, это совершенно неправильный путь - он теряет всех иначе изменений.
Вместо этой последовательности вот что я бы порекомендовал и почему:
git pull (до [начала работы])
Разделите это на git fetch; git merge, чтобы вы точно знали, что git pull делает с вами. (Можно сказать, для вас , но в случае git pull, это имеет тенденцию делать это до вас вместо для вас. Мой опыт с плохие старые времена Git 1.5 могут показываться здесь. :-) git pull в некоторых угловых случаях плохо ломал репозитории.)
Я на самом деле использую git merge --ff-only здесь только для того, чтобы вдвойне быть уверенным, что ничего странного не произошло. (У меня есть псевдоним git mff, для краткости git merge --ff-only. Иногда я использую несколько других трюков, но пока этого достаточно.)
- изменил код
Оставь эту часть. : -)
git diff > ~/my_diff
Не беспокойся об этом. Вместо этого запустите git add и git commit. Если вы сделали много изменений на шаге 2, вы можете сначала создать новое имя ветви:
git checkout -b mostly-ready # or some more suitable name
git add -u # or `.` or `-a` if you prefer
git status # check for unexpected new files, or untracked files
# make any adjustments you like here
git commit
git checkout - # go back to previous branch
git stash
Это больше не требуется. Все, что git stash делает, это делает коммиты, которые находятся на no branch; и, выполнив вышеприведенное или более простое git commit, вы сделали коммит в более подходящей ветке.
git pull
Разделите это на git fetch; git merge или, если вы сделали коммит на самой ветви, а не на боковой ветви, git fetch; git rebase. (Вы можете запустить git pull --rebase, чтобы выполнить последовательность выборки и перебазирования, но, опять же, я думаю, что лучше разделить два шага.)
git stash pop
Так как у вас нет тайника, здесь вам нечего будет искать. Если вы сделали коммит на месте и использовали git rebase, у rebase будут конфликты слияния, если таковые были, от передачи вашего коммита вперед. В противном случае ваш коммит находится на вашей боковой ветке mostly-ready, или как вы там его называли, и теперь вы можете запустить:
git cherry-pick -n mostly-ready
-n говорит Git , а не , чтобы зафиксировать результат. Это дает вам возможность просмотреть его и использовать git add -p, если хотите. Если возникают конфликты слияния, -n является избыточным, так как Git не сможет зафиксировать результат в любом случае. Обратите внимание, что есть важное предупреждение: некоторые ваших изменений могут быть уже подготовлены.
Что означает , точно
Важно помнить, что здесь, в Git, три копии каждого файла. Например, возьмем файл с именем README.txt. Три копии:
HEAD:README.txt (попробуйте git show HEAD:README.txt). Это зафиксированная версия файла, в частности, версия текущего коммита (он же HEAD он же @).
Эта копия заморожена в коммите. Находясь в коммите, он является постоянным (пока он существует) и на 100% доступен только для чтения. Он хранится внутри в сжатом формате только для Git, иногда очень сжатым. Лишь немногие другие программы могут с этим справиться; в основном это формат Git-only, поэтому вам нужно использовать git show или git checkout, чтобы получить его.
README.txt. Это верстак версия.
Это просто обычный файл. Вы можете делать с ней все что угодно. Git не особо заботится об этой копии; Git просто поместите его в свое рабочее дерево, чтобы вы могли получить к нему доступ и работать с ним / с ним.
:0:README.txt. Это index версия.
Индекс, который также называется промежуточной областью или иногда кеш , содержит версию, о которой Git заботится , но которая находится в специальный сжатый формат Git-only. Этот файл готов к переходу на следующий коммит, который вы сделаете, но в отличие от замороженной, коммитной версии только для чтения, вы можете перезаписать копию индекса .
Вот что делает git add: git add README.txt перезаписывает индексную версию :0:README.txt версией рабочего дерева README.txt. Это когда Git сообщает вам, что для коммита поставлено изменений. Дело не в том, что README.txt внезапно появился в области подготовки: он был там все время. Просто теперь, когда вы скопировали измененный README.txt поверх старого :0:README.txt, теперь версия в рабочей области отличается от версии, зафиксированной в коммите HEAD.
Итак, здесь нужно помнить, что вам нужно работать с файлами work-tree : вы можете редактировать их и все, что захотите. Но как только вы это сделаете, вам придется скопировать версию рабочего дерева поверх индексной версии. Некоторые команды Git, такие как git checkout, начинаются с того, что фиксированная зафиксированная версия и индексная версия совпадают. Некоторые, такие как git cherry-pick, могут изменять версию индекса (обычно при изменении версии рабочего дерева). Использование git add полностью перезаписывает индексную версию. Используя git reset, вы можете перезаписать поэтапную версию замороженной HEAD версией:
git reset README.txt
означает копия HEAD:README.txt поверх :0:README.txt, не касаясь рабочего дерева README.txt вообще.
Когда вы в конечном итоге запускаете git commit, то, что это делает, действительно довольно просто: оно замораживает все версии индекса в новый коммит. Они уже в нужной форме, сидят там в области указателя / постановки. Файлы в рабочем дереве не важны; имеют значение только файлы в индексе!
Две очень полезные git diff формы
Продолжительность:
git diff --cached
сравнивает для каждого файла версию HEAD (замороженную) с индексной версией и показывает разницу. Это что отличается в коммите, который вы собираетесь сделать.
Продолжительность:
git diff
сравнивает индексную (готовую к фиксации) версию каждого файла с версией рабочего дерева и показывает разницу. Это что отличается в коммите, который вы могли бы сделать, от того, что вы могли git add.
Продолжительность:
git status
запускает для вас оба эти различия , а затем показывает имена файлов (только), которые отличаются. Файлы, отличающиеся между HEAD и индексом, подготовлены для фиксации , а файлы, отличающиеся между индексом и рабочим деревом, не подготовлены для фиксации .