Реализуется ли этот разбросанный рабочий процесс в Git?

Question

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

1. Я ненадолго взломал мою новую функцию
2. Я заметил опечатку в комментарии
   • Я меняю это
   • Поскольку опечатка совершенно не связана ни с чем другим, я внес это изменение в кучу исправлений комментариев
3. Я продолжаю работать над кодом
4. Я понимаю, что мне нужно конкретизировать несколько полезных функций
   • Я так и делаю
   • Я положил это изменение в собственную кучу
5. Шаги 2, 3 и 4 повторяются в течение дня
6. Я заканчиваю новую функцию и помещаю изменения для этой функции в стопку
7. Я добавляю хорошие патчи вверх по течению: один с новой функцией, несколько для других твиков и один с кучей исправлений комментариев, если накопилось достаточно

Поскольку я и ленивый, и перфекционист, я хочу иметь возможность делать некоторые вещи не по порядку: я могу исправить опечатку, но забыть положить ее в стопку исправлений комментариев; когда я готовлю вышестоящие патчи (я использую git-svn, так что я должен быть довольно осторожен с ними), я в этот момент вытащу исправления комментариев. Я мог бы забыть отделить вещи полностью до самого конца. Но я мог / также / совершил некоторые кучи по пути (извините, метафора разрушается ...).

Это все равно, что просто использовать наборы изменений Eclipse с SVN, только у меня могут быть разные изменения в одном и том же файле в разных кучах (необходимость разделить изменения на разные коммиты - это то, что побудило меня перейти на git-svn, на самом деле ... ), а с Git я могу получить полную историю изменений, экспериментальные ветки и все остальное, но все же сделать хороший, аккуратный патч.

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

Я могу придумать несколько способов приблизить то, что я хочу (может быть, творческое использование stash? Запутанные танцы stash-checkout-merge?), Но мое понимание Git недостаточно твердое, чтобы быть уверенным в том, как лучше поставить все части вместе. Говорят, что Git - это скорее инструментарий, чем VCS, поэтому я думаю, что вопрос сводится к следующему: как мне построить эту штуку с помощью этих инструментов?

Answer 1

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

Функция rebase - одна из действительно мощных функций Git, и она, похоже, хорошо подходит для вашего режима работы.

Поскольку вы можете изменять сообщения коммитов с помощью rebase, вы можете добавить «тег», например «КОММЕНТАРИЙ» или «UTILS», к каждому связанному коммиту, чтобы вы могли легко их идентифицировать позже, когда вы перемешиваете вещи с помощью git rebase -i .

Одно из ограничений git svn dcommit может быть неудобным - вы можете только отправить «полный» (с точки зрения Git) набор исправлений в Subversion. То есть dcommit фиксирует только с момента, когда вы начали вносить изменения, в ГОЛОВУ. Если у вас есть коммиты (например, опечатки), которые вы хотите сохранить для последующих пакетных коммитов, вы можете сделать временную ветку для них, используя git rebase, чтобы поддерживать ее в актуальном состоянии.

В моем «списке вещей, которые нужно сделать когда-нибудь» я попытаюсь сделать патч для git svn dcommit, который позволит вам выбрать, какие патчи отправлять в Subversion.