Мерзавец: я должен проигнорировать Индекс или являюсь там приложением-убийцей для него?

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

Индекс также поддерживает функция git add -p , которая, на мой взгляд, является одной из смертоносных функций Git. См. The Thing About Git Райана Томайко, в котором описывается, как Git решает «проблему запутанной рабочей копии». Вы можете обработать только части измененных файлов без необходимости возиться с временными копиями или трюками с Undo в вашем редакторе.

Индекс на самом деле не участвует в вашем взаимодействии с другими разработчиками. Однако это может оказать существенное влияние на то, как вы взаимодействуете с Git.

Я считаю, что индекс действительно полезен, и очень редко фиксирует -a.

Поскольку вы не всегда отправляете в удаленный репозиторий при фиксации, пользователи git обычно делают меньше и чаще фиксируется и отправляется в общий репозиторий, когда «группа» изменений завершена. Это дает гибкость, позволяющую впоследствии откатить или выбрать отдельные коммиты. Скажем, я вношу 3 изменения и, используя subversion, фиксирую их все сразу, а затем хочу отменить одно из этих изменений ... или применить только одно из этих изменений к другой ветке ... это очень утомительный процесс. С помощью git вы можете добавить каждый файл, который вы изменили, в промежуточную область, а затем зафиксировать его отдельно. Очевидно, вам нужно убедиться, что фиксация внутренне непротиворечива и каждый набор изменений является «атомарным».

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

I find staging changes extremely useful for three reasons.

1. I don't accidentally commit changes as much, since there is that extra step to stage the file.
2. After making changes to a bunch of files at once via code generation or pattern substituation I like to step through the diff of each file before committing. Being able to stage files one by one is a nice way of bookmarking my progress.
3. I might be working through a feature and find an outdated comment or bad formatting along the way in some unrelated section. I can easily stage and commit a tiny change like that, keeping my feature commit pure and focused.

Несколько человек уже упоминали git add -p, но если вы никогда не использовали его, вы можете не оценить его полезность. Предположим, у вас есть следующая строка исходного кода, которая содержит 3 ошибки:

  distance= rate * deltaT;  /* compute tax rate */

(Три ошибки: неверно названная переменная deltaT, ошибка пробелов перед '=' и недопустимый комментарий.)

Вы уже редактировали файл, но вы хотите сделать 3 отдельных коммита с соответствующим сообщением журнала для каждого. С git это довольно тривиально, поскольку add --patch фактически позволяет вам перейти в редактор и отредактировать патч напрямую.

Помимо интерактивного размещения, другое важное использование индекса - во время конфликта слияния: Git обрабатывает три версии файла, чтобы знать, что файл не готов, поэтому есть версия под рукой, которая не усеяна маркерами конфликта. Сторонние инструменты могут использовать индекс здесь, чтобы обеспечить удобный интерфейс слияния.

Это не значит, что эта функция принципиально требует индекса - я уверен, что Mercurial обрабатывает конфликт слияния без индекса - но подход git к этому кажется хорошо ко мне.

Я предпочитаю по возможности игнорировать индекс.

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

Когда вы используете индекс (нетривиальным способом, когда вы проверяете некоторые изменения, но не другие) вы проверяете состояние кода, которое, вероятно, у вас нет ' t построил или запустил набор тестов на .

Конечно, для некоторых вещей (например, изменения в какой-то документации) это, вероятно, не имеет значения, и использовать индекс совершенно безопасно. Но хорошо отказаться от привычки делать это подверженным ошибкам способом и выработать привычку делать это правильно:

• Используйте git stash , чтобы спрятать все, что вы не делаете » t хотят зафиксировать.
• Создайте то, что осталось.
• Запустите набор тестов, чтобы проверить, что осталось.
• Зафиксируйте (все), что осталось.
• Распакуйте другие изменения, повторите при необходимости.

(1): Не все заботятся о том, чтобы каждый коммит был готовым для сборки рабочим состоянием кода.

Некоторые люди так думают, потому что это означает, что любая проверенная версия будет по крайней мере построена и запущена.