Как концепция индекса Git улучшает или меняет ваш рабочий процесс?

Question

Я уже почти месяц пытаюсь использовать Git в своих личных проектах.

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

Однако одной из концепций, которую я до сих пор не думаю, что я «получил», является реальная цель Индекса. У меня такое чувство, что я не пользуюсь какой-то пользой, которую она намеревается даровать.

Какова цель создания площадки? Исходя из земли SVN, я так привык воспринимать мою рабочую копию как свою область подготовки и снимки моих коммитов, взятых из этого.

Итак, мой вопрос:

Что дает вам этот дополнительный уровень косвенности? Как индекс улучшил или изменил ваш обычный рабочий процесс? Можете ли вы представить какие-либо сценарии, в которых наличие индекса позволило бы вам сделать что-то, что было бы проблематичным без него?

Answer 1

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

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

Answer 2

Говоря лично, я сейчас испытываю огромный конфликт слияний, и мне приходится исправлять элементы по одному. В этом случае я могу выполнить «git add» для файлов, которые я слил, и при этом сохранить отдельный список тех, которые мне нужно исправить.

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

Answer 3

Иногда я делаю 'git cherry-pick -n' или 'git merge --squash', чтобы получить кучу изменений из внешней ветки, затем я отменяю все эти изменения и использую git interactive add ( git add -i) ставить только те части, которые я хочу. Вы даже можете выбрать «куски» различий и оставить все остальное в измененном состоянии (отлично подходит для разворачивания вещей, которые должны были быть отдельными коммитами).

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

Мне также нравится, как область размещения работает со слияниями, чтобы показать вам, что не было организовано автоматически. Конечно, область индекса не является строго необходимой для этого, но я считаю, что поведение diff по умолчанию, показывающее вам diff только неиндексных элементов, будет полезным, так что вы не будете беспокоиться о том, чтобы увидеть сцену, если вы не используете diff - -cached.