То, что вы описываете - это в основном поведение git по умолчанию, за исключением нескольких ошибок. Некоторые предыстории, а затем некоторые возможные решения:
Фон
Под «главным образом поведением по умолчанию» я имею в виду: точка ветвления - это (частично), что вы можете переключаться между версиями файла, переключаясь между ветвями.
Но это работает только для изменений, связанных с веткой; и эта ассоциация возникает только тогда, когда вы commit изменения. Когда вы просто редактируете, сохраняете и, возможно, ставите файл в файл, но не фиксируете его - тогда ваши изменения существуют в рабочем дереве и, возможно, в индексе, но git еще не связывает их с веткой.
Поэтому, когда вы запускаете git checkout для переключения ветвей, git, вероятно, должен выдать предупреждение и отказать в извлечении - и в некоторых случаях, когда в противном случае данные могут быть потеряны, это произойдет. Но в случае, если файл одинаков при последних фиксациях в обеих ветвях, он будет сохранять изменения в рабочем дереве и / или индексе при переключении ветвей. (В командной строке он, по крайней мере, дает небольшую обратную связь, чтобы сообщить вам, что это произошло.
$ git checkout master
M file1
Switched to branch 'master'
говорит, что незафиксированные изменения были перенесены в file1.)
* Решения 1022 *
Commit
Первое решение, которое вы могли увидеть в комментариях, это зафиксировать ваши изменения. Если изменения готовы к фиксации, это хорошее решение. Даже если они не готовы стать частью постоянного коммита, если вы не push коммит, вы всегда можете отредактировать его из истории позже - например, выполнив следующий коммит с опцией --amend.
Stash
Но, возможно, у вас есть некоторые поэтапные изменения и дополнительные не поэтапные изменения, и вы пока не хотите смешивать их в один коммит. Или, может быть, по какой-то другой причине вы просто не чувствуете, что совершать изменения - это то, что нужно делать.
Еще одна вещь, которую вы можете сделать, это stash изменений. Это действительно по-прежнему создает временные коммиты, но пытается разделить поэтапные и нематериальные изменения и обеспечивает поддержку для восстановления ваших изменений в их предыдущем состоянии. См. git stash документацию.
git checkout branch
# edit some stuff
git add .
# edit more stuff
git stash
# NOTE: at this point it will look like your changes have simply been
# reverted; but they haven't.
git checkout master
# now you have the `master` versions of all files
# ... do stuff ...
git checkout branch
git stash pop
# branch version of file is back
Несколько рабочих деревьев
stash неплохо, но не всегда идеально.
Может быть, вы хотите, чтобы незафиксированные изменения в нескольких ветвях одновременно. Это может быть сделано с помощью тайников, но тогда вы должны держать вещи прямыми - например, какой тайник принадлежит какой ветке. (git может немного помочь в этом, но все еще легко испортить.) Итак, еще одно решение, которое стоит рассмотреть:
В вашем репо может быть несколько рабочих деревьев, каждое из которых соответствует своей ветви.
git worktree add /path/for/additional/worktree branch
См. git worktree документы.
Теперь у вас есть обе версии файла, одновременно доступные по разным путям в вашей файловой системе, так что любой инструмент может «видеть» и работать с любым из них или с обоими.
Возможно, это наиболее гибкая интерпретация того, о чем вы просили, но может оказаться излишним, если другие решения "достаточно хороши" для вашего варианта использования.