Git: Должен ли я игнорировать индекс или есть приложение-убийца для него?

Question

Как пользователь subversion, индекс git является наиболее сложной новой концепцией, с которой я сталкиваюсь, поскольку я рассматриваю ее использование для новых проектов. Я читал комментарии многих людей, в которых говорилось, что они не используют индекс (всегда фиксируют -a), но я думаю, что может быть более веская причина, почему я хотел бы использовать его. (Я делюсь кодом примерно с 5 другими разработчиками, работая в зрелой среде разработки, где мы объединяем код для тестирования и стабильных ветвей и используем ветвления для экспериментальных или значимых новых функций.)

Answer 1

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

Для действительно убийственной демонстрации; попробуйте использовать интерактивное добавление или добавление патча (используя git add -i или git add -p). Это выполнит все ваши изменения и позволит вам выборочно добавить их в индекс. Это позволяет вам вносить целый ряд изменений в ваши файлы и при этом разделять коммиты. Полезно для тех «ага» исправлений, которые мы все время от времени делаем.

Посмотрите эту скринкаст , чтобы увидеть, как это делается. Пока вы не попробуете сами, вы увидите, насколько это полезно.

Answer 2

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

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

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

Answer 3

Я считаю сценические изменения чрезвычайно полезными по трем причинам.

1. Я не так часто фиксирую изменения, поскольку есть дополнительный шаг для создания файла.
2. После внесения изменений в кучу файлов одновременно с помощью генерации кода или замены шаблона, мне нравится проходить через diff каждого файла перед фиксацией. Возможность размещать файлы один за другим - хороший способ отметить мой прогресс.
3. Возможно, я прорабатываю функцию и нахожу устаревший комментарий или неправильное форматирование в каком-то не связанном разделе. Я легко могу поставить и зафиксировать крошечное изменение, сохраняя при этом свою функцию чистой и сфокусированной.

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

---

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

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

Если вам не важно, чтобы каждый коммит был целым, рабочим состоянием кода, то это не имеет значения.