Зачем нужна stage area в Git?

Question

[Alexandr Zhuravlev]

Зачем нужно перед созданием commit помещать файлы в stage area? То есть понятно, что новые файлы нужно добавлять с помощью add, но зачем нужно добавлять файлы, уже находящиеся под контролем? Зачем была принята такая концепция? Ведь по сути получается, что stage area — это репозиторий в репозитории. Вначале мы добавляем файлы в stage, потом комитим их все в локальный репозиторий, потом делаем push в удаленный репозиторий. Зачем этот лишний шаг в виде stage?

Comments

[DevMan]

С английским дружите?

Answer 1

[Danny Chernyavsky]

Думаю, ответ немного банален — чтобы можно было выбирать, какие файлы включать в коммит.

Из практики — чаще всего случается git commit -am "...", уже до автоматизма дошло. Т.е. смотрю статус, если есть новые — добавляю, и затем коммит с флагом -a. Но это у меня. Т.к. в моем случае git по большей мере нужен для коммандной работы — сам контроль версий не особо использую. Если нужно балансировать между версиями — используются бранчи.

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

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

Comments

[mejedi]

Не просто какие файлы включить в коммит — а какие изменения включить в коммит.

Например можно из 100 измененных строк в файле выборочно закомитить 10 и еще и отредактировать их в процессе. Использую очень часто.

git add -i

[Danny Chernyavsky]

Согласен :)

Ни разу не пользовался. Интересно, как именно происходит работа с таким подходом — какая команда, как используются бранчи, по какому принципу происходит деплой (если речь о вебе, конечно же).

[DevMan]

Интересно, как именно происходит работа с таким подходом

С каким таким подходом?

[Danny Chernyavsky]

Скурпулезного составления коммитов.

[DevMan]

Работа происходит как всегда. Отличается только способ комита.

[mejedi]

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

Очень удобно, если перед публикацией мы хотим причесать серию коммитов. Какие-то слить вместе, или перегруппировать по другому.

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

Answer 2

[Meliborn]

Свободное формирование коммита так, как нам этого хочится, а не как диктует vcs?

Comments

[DevMan]

По дефолту комитится все изменения в файле.
Staging area позволяет, например, закомитить определенный фрагмент файла, а остальные изменения не комитить.

[DevMan]

Он делает как раз то, о чем я и написал. Только он работает как раз с данными в staging area.

[Павел Загребелин]

mercurial позволяет коммитить часть файла, оставляя остаток незакомиченным без всякого stage.

[DevMan]

Zagrebelion, и какое это имеет отношение к заданному вопросу?

[DevMan]

Вопрос про git. Каким боком здесь «в HG staging area нет»?