Спрятать в git только поэтапные изменения - возможно ли?

Да, это возможно с DOUBLE STASH

1. Подготовьте все свои файлы, которые вам нужно спрятать.
2. Запустите git stash --keep-index. Эта команда создаст тайник с ВСЕМИ вашими изменениями (поэтапными и неустановленными), но оставит поэтапные изменения в вашем рабочем каталоге (все еще в состоянии постановки).
3. Запустите git stash push -m "good stash"
4. Теперь ваш "good stash" содержит ТОЛЬКО промежуточные файлы.

Теперь, если вам нужны неустановленные файлы перед хранением, просто примените первый тайник (созданный с помощью --keep-index), и теперь вы можете удалить файлы, которые вы храните в "good stash".

Наслаждаться

В последней версии git вы можете использовать параметр --patch

git stash push --patch   # since 2.14.6

git stash save --patch   # for older git versions

И git будет запрашивать каждое изменение в ваших файлах, добавлять или нет в тайник.
Вы просто отвечаете y или n

UPD
Псевдоним для DOUBLE STASH:

git config --global alias.stash-staged '!bash -c "git stash --keep-index; git stash push -m "staged" --keep-index; git stash pop stash@{1}"'

Теперь вы можете подготовить свои файлы, а затем запустить git stash-staged.
В результате ваши подготовленные файлы будут сохранены в тайнике.

Если вы не хотите хранить промежуточные файлы и хотите переместить их в тайник. Затем вы можете добавить еще один псевдоним и запустить git move-staged:

git config --global alias.move-staged '!bash -c "git stash-staged;git commit -m "temp"; git stash; git reset --hard HEAD^; git stash pop"'

TL; DR Просто добавьте -- $(git diff --staged --name-only) в качестве параметра git <pathspec>

Вот простой однострочник:

git stash -- $(git diff --staged --name-only)

А чтобы просто добавить сообщение:

git stash push -m "My work in progress" -- $(git diff --staged --name-only)

Проверено на v2.17.1 и v2.21.0.windows.1

Ограничения:

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

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

(Спасибо Бартломею за отправную точку)

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}

Чтобы сделать то же самое ...

1. Подготовьте только те файлы, над которыми хотите работать.
2. git commit -m 'temp'
3. git add .
4. git stash
5. git reset HEAD~1

Бум. Ненужные файлы спрятаны. Все нужные вам файлы готовы для вас.

Спрятать только индекс (поэтапные изменения) в Git сложнее, чем должно быть. Я нашел, что ответ @Jo работает хорошо, и превратил его небольшую вариацию в этот псевдоним:

stash-index = "!f() { \
  ! git diff --cached --exit-code --quiet && \
  git stash push --quiet --keep-index -m \"temp for stash-index\" && \
  git stash push \"$@\" && \
  git stash pop --quiet stash@{1} && \
  git stash show -p | git apply -R; }; f"

It:

1. Проверяет, действительно ли есть поэтапные изменения (git diff --cached --exit-code возвращает ненулевой статус, если они есть). HT: @nandilugio

2. Он помещает как поэтапные, так и неэтапные изменения во временное хранилище, оставляя только поэтапные изменения.

3. Затем он помещает поэтапные изменения в тайник, который мы хотим сохранить. Аргументы, переданные псевдониму, такие как --message "whatever", будут добавлены к этой команде stash.

4. Он открывает временный тайник, чтобы восстановить исходное состояние и удалить временный тайник, а затем

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

По поводу противоположной проблемы, связанной с хранением только неустановленных изменений (псевдоним stash-working), см. этот ответ.

В этом сценарии я предпочитаю создавать новые ветки для каждой проблемы. Я использую префикс temp /, поэтому знаю, что могу удалить эти ветки позже.

git checkout -b temp/bug1

Подготовьте файлы, исправляющие ошибку 1, и зафиксируйте их.

git checkout -b temp/bug2

Затем вы можете выбрать коммиты из соответствующих веток по мере необходимости и отправить запрос на перенос.

Почему бы вам не зафиксировать изменение для определенной ошибки и не создать патч на основе этой фиксации и ее предшественника?

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

Затем, чтобы создать соответствующие патчи, используйте git format-patch:

git format-patch HEAD^^

Это создаст два файла: 0001-fix-bug-123.patch и 0002-fix-bug-321.patch.

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

git stash --keep-index - хорошее решение ... за исключением того, что оно некорректно работало на удаленных путях, что было исправлено в Git 2.23 (3 квартал 2019 г.)

См. commit b932f6a (16 июля 2019 г.) Thomas Gummerer (tgummerer).
^{(Объединено Junio ​​C Hamano - gitster - в фиксации f8aee85 >, 25 июл 2019)}

Обязательно ли работать сразу над несколькими ошибками? И под «сразу» я имею в виду «одновременное редактирование файлов для устранения нескольких ошибок». Потому что, если вам это не нужно, я буду работать только над одной ошибкой за раз в вашей среде. Таким образом, вы можете использовать локальные ветки и перебазирование, что, на мой взгляд, намного проще, чем управлять сложным тайником / этапом.

Допустим, мастер находится в фиксации B. Теперь работаем над ошибкой №1.

git checkout -b bug1

Теперь вы на ветке bug1. Внесите некоторые изменения, зафиксируйте, дождитесь проверки кода. Это локально, поэтому вы никого не трогаете, и сделать патч из git diffs должно быть достаточно просто.

A-B < master
   \
    C < bug1

Теперь вы работаете над ошибкой 2. Вернитесь назад к освоению с git checkout master. Создайте новую ветку git checkout -b bug2. Внесите изменения, зафиксируйте, дождитесь проверки кода.

    D < bug2
   /
A-B < master
   \
    C < bug1

Давайте представим, что кто-то другой совершает E&F на мастере, пока вы ждете проверки.

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

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

git checkout bug1
git rebase master
git checkout master
git merge bug1

Это приведет к следующему:

    D < bug2
   /
A-B-E-F-C' < master, bug1

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

Ответьте на вопрос ctote в комментариях:

Что ж, вы можете вернуться к хранению для каждой ошибки и работать только с одной ошибкой за раз. По крайней мере, это избавит вас от проблемы постановки. Но, попробовав это, я лично нахожу это хлопотным. Тайники немного беспорядочные в графе журнала git. И что еще более важно, если вы что-то напортачите, вы не сможете вернуться. Если у вас грязный рабочий каталог и вы открываете тайник, вы не можете «отменить» это всплывающее окно. Гораздо сложнее испортить уже существующие коммиты.

So git rebase -i.

Когда вы переставляете одну ветку в другую, вы можете делать это в интерактивном режиме (флаг -i). Когда вы это сделаете, у вас есть возможность выбрать, что вы хотите делать с каждой фиксацией. Pro Git - отличная книга, которая также доступна в Интернете в формате HTML, и в ней есть хороший раздел о перебазировании и сжатии:

http://git-scm.com/book/ch6-4.html

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

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

Вот что вы увидите, набрав git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Чтобы сжать все коммиты ветки в одну, оставьте первую фиксацию как «pick» и замените все последующие записи «pick» на «squash» или просто «s». У вас также будет возможность изменить сообщение фиксации.

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

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

Другой подход к этому - создать временную фиксацию с файлами, которые вы не хотите хранить, затем спрятать оставшиеся файлы и аккуратно удалить последнюю фиксацию, сохраняя файлы нетронутыми:

git add *files that you don't want to be stashed*
git commit -m "temp"
git stash --include-untracked
git reset --soft HEAD~1

Таким образом, вы касаетесь только тех файлов, к которым хотите прикоснуться.

Обратите внимание: --include-untracked используется здесь также для хранения новых файлов (что, вероятно, именно то, что вам действительно нужно).

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

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

Преимущество этой процедуры в том, что вы можете использовать обычный рабочий процесс git.

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

git add <stuff to keep> && git stash --keep-index && git stash drop

Другими словами, спрячьте хлам и выбросьте его вместе с тайником.

Проверено в git версии 2.17.1

Я не видел этого решения, которое не требует использования git stash:

Вам даже не нужно использовать git stash. Вы можете решить это с помощью специальной ветки , как описано здесь. (ветки дешевые).

В самом деле, вы можете изолировать по отдельности не- и поэтапные изменения с помощью нескольких последовательных команд, которые можно связать вместе в псевдоним git:

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

В любой момент вы можете git cherry-pick -e одну фиксацию из созданной ветки, чтобы применить ее там, где вы хотите (-e, чтобы изменить ее сообщение фиксации).

Когда он вам больше не нужен, вы можете удалить эту ветку тайника. Возможно, вам придется использовать параметр -D для принудительного удаления (вместо обычного параметра -d), потому что указанная ветвь не объединяется, и git может подумать, что вы рискуете потерять данные, если удалите ее. Это верно, если у вас нет выбранных коммитов, которые были на нем до удаления:

git branch -D separated-stashes

Вы также можете добавить псевдоним к своему ~/.gitconfig, чтобы автоматизировать это поведение:

git config --global alias.bratisla '!git switch -c separated-stashes; git commit -m "staged changes"; git add -u; git commit -m "unstaged changes"; git switch -' # why this name ? : youtu.be/LpE1bJp8-4w

перед хранением
после сохранения

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

Как указано в других ответах, у вас есть несколько способов спрятать только неустановленные или только поэтапные изменения, используя git stash (-k|--keep-index) в сочетании с другими командами.

Я лично считаю, что параметр -k очень сбивает с толку, поскольку он хранит все, но сохраняет поэтапные изменения в поэтапном состоянии (это объясняет, почему --keep-index). В то время как прятание чего-либо обычно перемещает его в тайник. С -k неустановленные изменения хранятся в обычном режиме, а поэтапные просто копируются в ту же запись тайника.

Шаг 0: у вас есть две вещи в вашем статусе git: файл, содержащий поэтапные изменения, и другой файл, содержащий неустановленные изменения.

Шаг 1: спрятать неустановленные + поэтапные изменения, но сохранить поэтапные в индексе:

git stash -k -m "all changes"

Часть -m "..." является необязательной, git stash -k на самом деле является псевдонимом для git stash push -k (который ничего не передает удаленно, кстати, не беспокойтесь), который принимает параметр -m для обозначения ваших записей для ясности (например, сообщение фиксации или тег, но для тайника Вход). Это более новая версия устаревшего git stash save.

Шаг 1bis (необязательно):

git stash

Спрятанные поэтапные изменения (которые все еще находятся в индексе). Этот шаг не является обязательным для следующего, но показывает, что вы можете вносить только поэтапные изменения в запись тайника, если хотите. Если вы используете эту строку, вам нужно git stash (pop|apply) && git add -u, прежде чем продолжить шаг 2.

Шаг 2 :

git commit -m "staged changes"

Делает коммит, содержащий только поэтапные изменения с шага 0, он содержит то же самое, что и запись в тайнике с шага 1bis.

Шаг 3 :

git stash (pop|apply)

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

nb: restore здесь НЕ означает git restore, это другая команда.

Шаг 4:

git add -u

Добавляет содержимое всплывающего тайника в индекс

Шаг 5:

git commit -m "unstaged changes"

Неустановленный здесь, как указано в комментариях к шагам 2 и 3, относится к шагу 0. Фактически вы проводите и фиксируете поэтапные изменения с шага 0.

Сделанный ! Теперь у вас есть две отдельные фиксации, содержащие (не) поэтапные изменения с шага 0. Возможно, вы захотите исправить / перебазировать их либо для дополнительных изменений, либо переименовать / отбросить / раздавить их. В зависимости от того, что вы сделали со стеком своего тайника (pop или apply), вы также можете git stash (drop|clear) это сделать. Вы можете видеть свои записи в тайнике с git stash (list|show)

TL; DR; git stash-staged

После создания псевдонима:

git config --global alias.stash-staged '!bash -c "git stash -- \$(git diff --staged --name-only)"'

Здесь git diff возвращает список --staged файлов --name-only
И затем мы передаем этот список как pathspec в git stash запятую.

От man git stash:

git stash [--] [<pathspec>...]

<pathspec>...
   The new stash entry records the modified states only for the files
   that match the pathspec. The index entries and working tree
   files are then rolled back to the state in HEAD only for these
   files, too, leaving files that do not match the pathspec intact.