Как уже упоминалось в ответах и комментариях, есть как минимум три варианта.Между ними есть частичное совпадение, и у каждого есть свои плюсы и минусы:
- Создание новой ветви es (множественное число)
- Хранение изменений
- Добавление рабочего дерева (рабочего дерева)
Создание новых веток
Ветви практически ничего не стоят, поэтому самый простой вариант, без реальных изменений в существующем рабочем процессе, - это создавать новые ветви,Если вы сомневаетесь, захотите ли вы чего-нибудь в один прекрасный день, то, как правило, не помешает передать это в «незавершенную» или «экспериментальную» ветку.
В вашем конкретном сценарии ярекомендовал бы создать новую ветку, чтобы сохранить ваши 8 неразмеченных изменений (давайте назовем их экспериментальными), и другую новую ветку вне мастера для другой работы, которую вы хотите сделать (назовем это новой функцией):
git checkout -b experimental/foo
git add --all
git commit -m 'Trying a new structure for Foo'
git checkout master
git checkout -b feature/bar
Я бы порекомендовал этот подход, если вы хотите сохранить свои 8 изменений на некоторое время (или если вы не уверены, как скоро вы к ним вернетесь).Вы даже можете перенести экспериментальную ветку в свой исходящий репозиторий для дополнительной избыточности или для совместной работы над ней.
Примечание 1 Последние две команды можно объединить в одну строку git checkout -b feature/bar master.Это умнее (и, возможно, более явно), но мне нравится быть проще и всегда извлекать ветку перед созданием новой ветки из нее
Примечание 2"Экспериментальные /" и "особенность /«пространства имен являются необязательными, но я считаю их полезными для будущего, чтобы я знал, о чем думал я в прошлом.И напишите хорошее сообщение о коммите , будущее, которое вы будете благодарить за прошлое :)
Stash the Changes
Другой вариант - временно " stash "изменения, а затем повторно применить спрятанные изменения к вашей основной ветви (или даже к какой-либо другой ветви).
В вашей ситуации я бы спрятал изменения (с описательным сообщением), создав новую ветвь функцийа затем, позже, вы можете вернуться и применить спрятанные изменения к мастеру:
git stash --include-untracked save 'Trying a new structure for Foo'
git checkout -b feature/bar
...
<make a few changes in feature/bar and commit or discard them>
...
git checkout master
git stash apply
Копирование немного сложнее, но может быть довольно гибким.Основное отличие от создания ветки заключается в том, что тайники являются только локальными;их нельзя подтолкнуть вверх по течению.Я бы порекомендовал эту опцию, только если вы знаете, что вам нужна дополнительная гибкость, обеспечивающая копирование, или если тайник будет очень недолгим, в основном это быстрый вырез и вставка.
Примечание 1 По умолчаниюсохранение включает только измененные файлы, опция --include-untracked важна, если ваши изменения включают какие-либо новые файлы.Вы также можете использовать --all (как мы использовали с git add выше), но это также сохранит игнорируемые файлы.
Примечание 2 Выше предполагается, что вы не спрятали что-либо еще втем временем.Используйте git stash list, чтобы проверить, что вы не делали другие тайники с тех пор.После того, как вы закончили с этим хранилищем, вы можете использовать git stash drop, чтобы удалить его.git stash pop давайте подадим заявку и добавим одну команду.
Примечание 3 В Atlassian есть довольно полезное руководство по использованию git stash , если вы хотите научитьсяподробнее.
Добавление рабочего дерева (Worktree)
Еще один (немного) более сложный, но гибкий вариант - добавление рабочего дерева (отныне я буду просто использовать "рабочее дерево "для отражения названия команды).Ваше рабочее дерево - это место, где существуют неустановленные изменения, которые перемещаются вместе с вами по мере оформления заказа и перемещения между филиалами.По умолчанию существует только одно «основное» рабочее дерево, но вы можете добавить один или несколько «связанных» рабочих деревьев, чтобы иметь возможность извлекать несколько веток одновременно и иметь разные неповрежденные изменения в каждом рабочем дереве.
ВВ приведенном выше сценарии я бы, вероятно, создал новое рабочее дерево (и ветвь) на основе master, а затем переключился на новый каталог рабочего дерева.Ваши неизмененные изменения останутся в вашем основном рабочем дереве, и вы можете вернуться к работе над ними, просто вернувшись в этот каталог:
git worktree add -b feature/bar ../app-name-bar
cd ../app-name-bar
Поскольку это позволяет вам получать более одной ветки за раз, это обеспечивает некоторые действительно приятные рабочие процессы.Например, вы можете открыть два разных окна / вкладки терминала и / или редактора и смотреть на две ветви рядом.Это решение, которое я выбрал бы для всего, кроме очень краткосрочных потребностей, для которых я бы, вероятно, использовал скрытие.
Примечание 1 Используя эту опцию, вы также создаете новую ветвь.По сути, это особый случай варианта 1.
Примечание 2 Нельзя иметь одну и ту же активную ветвь на двух разных рабочих деревьях.Если вам по какой-то причине вам нужно скопировать ветку или запустить вторую, отделенную с помощью --detach (см. эту статью для получения дополнительной информации)
Примечание 3 Приведенные выше команды создадут новую папку «app-name-bar» на том же уровне, что и ваш текущий репозиторий.Допустим, ваше приложение называется «todos», в вашей файловой системе вы получите еще одну копию «todos», которая называется «todos-bar» (хотя вы можете называть ее как угодно).Чтобы все было организовано, я предпочитаю создать папку для всех папок рабочего дерева.Следующие шаги показывают, как переместить и переименовать ваш текущий репозиторий из todos в todos / main, чтобы вы могли иметь один или несколько дополнительных связанных рабочих деревьев, расположенных рядом с вашим основным рабочим деревом:
# Do these steps just once
mv todos/ main/
mkdir todos
mv main todos/
cd todos/main
# Do these steps every time you want to add a worktree...
cd todos/main
git worktree add -b feature/bar ../bar
cd ../bar
# ...and you'll end up with this directory structure
# └─ todos/
# ├─ main/
# | └─ ...
# └─ bar/
# └─ ...