Обязательно ли нужно работать над несколькими ошибками одновременно? И под «сразу» я подразумеваю «иметь файлы, отредактированные для нескольких ошибок одновременно». Потому что, если вам это абсолютно не нужно, я буду работать только с одной ошибкой за раз в вашей среде. Таким образом, вы можете использовать локальные ветки и ребаз, что, на мой взгляд, гораздо проще, чем управлять сложным хранилищем / сценой.
Допустим, мастер находится на коммите B. Теперь поработайте над ошибкой # 1.
git checkout -b bug1
Теперь вы на ветке bug1. Внесите некоторые изменения, зафиксируйте, дождитесь проверки кода. Это локально, так что вы ни на кого не влияете, и это должно быть достаточно просто сделать патч из git diffs.
A-B < master
\
C < bug1
Теперь вы работаете над bug2. Вернуться назад к мастеру с git checkout master. Создать новую ветку git checkout -b bug2. Внесите изменения, зафиксируйте, дождитесь проверки кода.
D < bug2
/
A-B < master
\
C < bug1
Давайте представим, что кто-то еще отправляет E & F на master, пока вы ожидаете проверки.
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 log. И что более важно, если вы что-то напортачили, вы не сможете вернуться. Если у вас грязный рабочий каталог и вы открываете тайник, вы не можете «отменить» этот треск. Гораздо сложнее испортить уже существующие коммиты.
Так 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
Так что да, раздавить - это немного больно, но я все равно рекомендовал бы это, если вы используете тяжелые тайники.