Зачем мне нужна сцена перед коммитом в Git?

Question

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

Чего я не понимаю, так это с практической точки зрения. Является ли постановка чем-то, что существует только в названии, или это служит цели? Когда вы делаете коммит, он всё равно всё совершит, верно?

Редактировать: Я думаю, что я путаю терминологию. Является ли «промежуточный» файл тем же, что и «отслеживаемый» файл?

Answer 1

Когда вы делаете коммит, он только фиксирует изменения в индексе («промежуточные» файлы). Для этого есть много применений, но самое очевидное - разбить ваши рабочие изменения на более мелкие, автономные части. Возможно, вы исправили ошибку во время реализации функции. Вы можете git add только этот файл (или git add -p, чтобы добавить только часть файла!) И затем зафиксировать это исправление перед тем, как делать все остальное. Если вы используете git commit -a, то вы просто заставляете add всего прямо перед коммитом. Не используйте -a, если хотите воспользоваться возможностью размещения файлов.

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

Answer 2

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

Answer 3

Одной из практических целей постановки является логическое разделение файловых коммитов.

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

Предположиму вас есть 4 файла fileA.html, fileB.html, fileC.html и fileD.html.Вы вносите изменения во все 4 файла и готовы к фиксации, но изменения в fileA.html и fileB.html логически связаны (например, одинаковая реализация новой функции в обоих файлах), тогда как изменения в fileC.html и fileD.html являются отдельными илогически не имеет отношения к предыдущим файлам.Вы можете сначала подготовить файлы fileA.html и fileB.html и зафиксировать их.

git add fileA.html
git add fileB.html
git commit -m "Implemented new feature XYZ"

Затем на следующем шаге вы создадите и передадите изменения в оставшиеся два файла.

git add fileC.html
git add fileD.html
git commit -m "Implemented another feature EFG"

Answer 4

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

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

Вы можете найти больше примеров здесь: Использование индекса

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

Answer 5

Я вижу смысл в использовании stage, чтобы сделать коммиты меньшими, как упомянуто @Ben Jackson и @Tapashee Tabassum Urmi, и иногда я использую его для этой цели, но в основном я использую его для увеличения своих коммитов! вот моя точка зрения:

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

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

Я вижу другие способы сделать это (упрощение истории git), которые вы можете использовать в зависимости от ваших предпочтений:

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

Answer 6

Проще понять использование команд git add и commit, если представить, что файл журнала поддерживается в вашем репозитории на Github. Типовой файл журнала проекта для меня может выглядеть так:

---------------- Day 1 --------------------
Message: Complete Task A
Index of files changed: File1, File2

Message: Complete Task B
Index of files changed: File2, File3
-------------------------------------------

---------------- Day 2 --------------------
Message: Correct typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on

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

Каждая из этих подзадач (Задача A и Задача B здесь) является отдельными коммитами. Команда git add добавляет файлы в список «Индекс измененных файлов». Этот процесс также называется постановкой. Команда git commit записывает / завершает изменения и соответствующий индексный список вместе с настраиваемым сообщением.

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

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

git pull
# Make changes to these files
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Correct typos'
git push

В двух словах, git add и git commit позволяют разбить изменение основного репозитория на систематические логические подмены. Как уже отмечалось в других ответах и ​​комментариях, у них, конечно, есть много других применений. Тем не менее, это один из самых распространенных способов использования Git, который является многоступенчатой ​​системой контроля версий в отличие от других популярных систем, таких как Svn.