Почему в git существует процесс промежуточного этапа?

Ответ 1

Истина такова: индекс является промежуточной областью. Каждый SCM имеет его, но git показывает его вам и эффективно использует.

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

Например, вы работаете над двумя разными способами, и теперь ваш код выглядит как

//random code

//bug fix

//new feature

Вы можете выполнить только строку //bug fix и зафиксировать это, а затем выполнить этап //new feature и зафиксировать это.

Теперь у вас есть две разные фиксации. Позже в тестировании вы поймете, что команда new feature совершила что-то сломала, вы можете удалить фиксацию new feature, но не нужно повторять ошибку bugfix

Как отметил в своем ответе Диксон Рид, вы также получаете производительность, поскольку git commit теперь нужно только добавить то, что находится в индексе к фиксации. Чтобы найти все изменения, вам не нужно искать через свое дерево.

Ответ 2

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

Ответ 3

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

Ответ 4

Это чистая ПИТА (по моему скромному мнению). Очевидно, что большинство инструментов пользовательского интерфейса (на самом деле все, что я знаю, включая Eclipse EGit, Mac XCode и клиент GitHub) не раскрывают эту функцию.

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

В настоящее время вы можете пройти 4 этапа:

1. Your file system
2. The staging
3. your local repository
4. the remote upstream

Интерфейсы UI до git не выставляют этап. Они показывают вам все изменения, которые у вас есть. Вы проверяете те, которые вы хотите совершить, и вы совершаете за одну операцию.

Возможно, это подробная информация о взломе, которая была поднята в концепцию пользовательского интерфейса. Вместо:

commit( X, Y, Z)

у вас есть:

add(X), add(Y), add(Z), commit()

Ответ 5

Я только начал изучать чудесный мир DVCS, и хотя я уже продал свою душу демонам git, но у меня все еще есть объективный взгляд. Существует некоторая избыточность в представлении промежуточной области, однако вы можете пренебречь областью постановки целиком (что я делал, когда я использовал клиент github). С другой стороны, это дает большую гибкость, поэтому я бы сказал, что это ненавязчивая избыточность, которая иногда может помочь вам немного.

Что мне подсказывало, так это то, что существует слишком много терминов, называющих его: кеш, промежуточная область, индекс. Очевидно, что это дизайнерское решение возникло как совокупность аналогичных концепций, и в нем есть некоторая история. Моя первая ставка оказалась правдоподобной - я отправился на сайт Bitkeeper и нашел там "постановку" (они используют его для разветвления по требованию)

Теперь я предполагаю, что в то время, когда Bitkeeper управлял источниками Linux, эта функция была использована неправильно, и вместо создания ветки по требованию для нескольких разработчиков она использовалась только одним разработчиком. И позже, потому что этот пример использования оказался полезным git включенной облегченной версией "промежуточной области", которая удобно реализована путем предоставления пользовательского интерфейса "индексу" или "кешу".