Зачем мне нужен этап перед тем, как совершить в Git?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Проще понять использование команд 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.

Ответ 6

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

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

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

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

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