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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

(Три ошибки: misnamed variable deltaT, ошибка пробела перед "=" и недопустимый комментарий.)

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

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

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